Jump to: navigation, search



An Environment is a logical grouping of resources. App actions (deploy, view stats, etc) can be targeted per environment. Certain constraints (permissions, resource quotas, etc) can also be applied per environment. An environment may carry its own credentials for one or more cloud accounts. Such credentials will be persisted securely in Barbican.


  "id": "a7033084-5efef-4812-90a4-e4d24ffb6e31",
  "name": "staging",
  "type": "environment",
  "acl": "fcd84e29-c169-47b1-aaf0-f5dcbded1b39",
  "credentials": "3f95316c-acce-476c-a96b-8b75039a37d5",
  "keystone_endpoint": "",
  "change_policy": "c299c08c-213f-4b88-8da4-e5bb90640db3"

The above example shown a staging environment containing two assemblies (running applications), a reference to an ACL policy, and a reference to a credentials set (a secret in Barbican) to use to authenticate with the configured keystone and heat endpoint. Note that additional keys may be added, and each service consuming the Environment resource may implement functionality based on the presence of the keys in the Environment. The referenced change_policy (implemented with Congress) will be used to determine if the assembly_list can be altered by adding an assembly or removing one.

Following are some use cases and the related personas:


Solum User

A user of the Solum software and an OpenStack Cloud to facilitate ease-of-use and automated integration with software development for applications that run on OpenStack. A Solum User is a software developer (canonically: Application Developer).

Release Manager

An individual member of a software development team responsible for coordinating software releases, and initiating deployments of tested/approved software.

Use Cases

1. As a Solum User deploying my app with Solum, I want to specify the environment where my app gets deployed i.e. Dev, Test, Staging, Prod, as long as I have "deploy" privileges on the Environment [see 2 below].

2. As a Release Manager for a team deploying apps on Solum, I want to specify which user can perform what actions on each environment. For example, a developer may have more access to a dev environment [deploy app, start/stop app, delete app, view app status+statistics], and less access to a production environment [view access only]

3. As a Release Managerdefining the app release lifecycle for our apps, I want to define my "custom" environments in addition to selecting from predefined ones such as Dev/Test/Staging/Prod. An example of a custom environment could be "Performance Test Environment".

4. As a Release Manager for a team deploying apps via Solum, I should be able to specify resource quota's (amount of compute/storage) per environment. Once the resource quota is hit, I should be able to specify a soft threshold (email notification), or a hard threshold (i.e. prevent further resource use on the environment).

5. As a Release Manager, I want to specify conditional "entry gates" for app deployment by environment. For example

  • Unit tests must pass for dev environment
  • Functional tests must pass for test environment
  • Performance tests must pass for staging environment

6. Promotion of apps from one environment to the next: as a Release Manager, I want to "promote" an app from one environment to the next. For example, once test sign-off is received from the QA team, I should be able to promote the app from the Test environment to the Staging environment. When an app is promoted, the application binary/WAR file is not rebuilt from code, rather the same binary from the Test environment is used to compose the DU to be deployed to the Staging environment.

See Also

Proposed API for: Pipelines