Jump to: navigation, search

Difference between revisions of "Solum/ApiModel"

(Redirected page to Solum/Pipeline)
 
(26 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Broadly, we will have two sub-systems:
+
#REDIRECT [[Solum/Pipeline]]
- 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).
 

Latest revision as of 20:55, 17 May 2014

Redirect to: