Roles in the Murano

• Application Publisher -an individual or company, publishes an application to an application catalog
• End User -an individual or company attempting to self-provision a application from an application catalog
• Catalog Administrator -An individual or company, maintains an application Catalog and determines any Relevan T policies regarding its use.

Application Publisher

The process begins when an application Publisher creates a new application description and publishes it to a Murano endpoi Nt. It'll then being available within any application catalog instances defined by this Murano endpoint, depending on the polic IES for that instance.

Application publishers should is able to create new application by defining service metadata, describing properties and Specifying all the steps necessary for deploying the service and its dependencies. The developer can create this definition from scratch or use a existing definition by extending it, similar to Inheritanc E in the object-oriented paradigm. The application Publisher can define the external dependencies of the service. This list of dependencies defines the other services (specified by their type) that must is present in the environment whe n the given service is being deployed.

Consider this example. An application Publisher creates a service, that provides a Web application. The developer provides the name and other service properties, and specifies the external dependencies is a web serve R and a database. When the users want to deploy the this service in an environment, they need to has a web-server service and a database service in That environment, and must is able to specify how they want to fulfill those requirements. (See the End User with cases for more information.)

The application Publisher may define additional terms of use for their Service. For example, the developer may limit it usage and extensibility (via inheritance or referencing from another service) or Specify billing rules.

Another important set of parameters that the application Publisher could specify in the Service Definition is the usage met Rics. These usage metrics define which aspects of the service should be monitored by ceilometer or other monitoring tools suppor Ted by Murano if its instances is running. The application Publisher can then specify the billing rules used with those metrics, essentially defining how much usage A service would cost the user.

[Note This proposal was meant to define a project that provides billing information, but because different organizatio NS has different needs, it doesn ' t define actual payment methods; Payment May is handled by a external component, or it may is addressed in the future versions of Murano.]

A service definition is not bound to any particular OpenStack deployment or instance of Murano. The developer may create a service definition and then publish that definition in several service catalog instances, (as L Ong as publishing is permitted by the administrator of this catalog (see below).

Catalog Administrator

A published service definition is managed by the catalog administrator.

The

Catalog administrators is the maintainers of the application service Catalog. They the ability to manually add or remove service definitions in a catalog, or act as moderators allowing or Disallo Wing other application publishers to publish their service definitions. This control can is granular or not, as the administrator chooses. For example, the administrator may specify, a new submissions must be approved before being available RS, or the administrator may instead choose to make services available only to the OpenStack tenant associated with the AP Plication Publisher until a service is approved. The administrator can also decide to make all services available to all upon submission, as in the case of a test cloud, O R a small cloud in which all developers is "trusted".

Administrators may also define their own billing rules, which'll be in addition to the billing rules specified by the AP Plication Publisher (if they were defined). This enables catalog administrators to cover the costs involved in running and maintaining the cloud. For example, a service that requires Microsoft Windows could incur a licensing cost for the operating system; This mechanism enables the catalog administrator to recoup.

Catalog Administrators also configure role-based Access Control rules (RBAC), which define which end users (which is Asso Ciated with tenants) of the cloud has access to which services in the catalog, and whether they could be directly deployed Or must is approved before deployment (see End User use cases). The billing rules for a particular service may also is defined specifically for a given tenant or a given user.

End User

Finally The service is a ready for the end user.

A user should is able to the create environments composed of one or more available services. The process is as follows:

The user browses a list of available services and selects one or more for deployment. If A selected service has dependencies this require other services to being deployed in the same environment, the user may EI Ther Select an instance of the necessary service from instances of that type that is already present in the environment, Or add a new instance of that type instead. Dependencies may include the other services, or they may include resources such as a floating IP address or license key. Each service added to the environment must is properly configured; The user is prompted to provide all required properties, and the input was validated according to the rules defined in each Service definition. When the user has finished configuring the environment, he or she can deploy the environment – if he or she has the Appro Priate permissions. (see below.) Deployment of the environment means that instances is created, services is deployed, and all required configuration Acti ONS take place.

In some environments, it'll be is more appropriate for end users to submit their deployments to it as a ticket. The IT department can then sanity-check the definitions, determine whether they is appropriate, and approve, modify, or D Eny the deployment. If the request is a approved or modified, the IT department can then initiate the deployment, rather than the user.

Users can browse any deployed environments for which they has permissions, and inspect their state. Inspection includes the ability to determine which services is running on which nodes, how the services is configured, a nd so on. Users can modify service settings, add new services or remove existing ones, validate the changes (i.e. check the Required properties is set to valid values, all the service dependencies exist and so on), and redeploy the environment By propagating these changes into the Cloud. The user can also inspect the usage metrics of the services running in he or her environments, and see billable Activitie s and the total amount of money spent for a particular service.

Roles in the Murano