Solum/ApiModel
Broadly, we will have two sub-systems: - Builder subsystem - Deployment subsystem
The builder system will be driven by the deployment subsystem.
The entry point of Solum would be the deployment subsystem with a 'workflow' as the input. This workflow would contain build, test, and deploy actions for different environments. The actions can be based on different kind of policies (time-based, user-driven, and so on). These policies and actions would essentially be sub-workflows within the main workflow.
Example of the deployment workflow:
lifecycle: environment: Develop policy: True actions: run_tests: git_url: github.com/helloworkld.git cmd: tox build: git_url: github.com/helloworkld.git cmd: build_app
environment: Staging policy: depends-on-success-of-Develop actions: deploy: # we need to be able to pass the image from the dev env # so we can use it here.
environment: Production policy: Manual actions: deploy: heat create prod -u <somewhere> -P "image=<bla>"
DSL for describing deployment workflow can be Jenkins to begin with. That way, we can use Jenkins also to perform the builds (in the builder subsystem/service). For DSL, we can also look at Mistral, Taskflow, Murano. It will be great if more than one folks participate in the DSL discussions being proposed by Mistral +guys (ref. Email on Openstack-dev list).
Builder subsystem/service:
- Investigate Jenkins
- Investigate Mistral
Additional Issues:
- Long running workflows would need Solum to use trusts (and renew tokens periodically).