Jump to: navigation, search

Difference between revisions of "Solum/ApiModel"

Line 1: Line 1:
 
Broadly, we will have two sub-systems:
 
Broadly, we will have two sub-systems:
- Builder subsystem
+
- Builder subsystem
- Deployment subsystem
+
- Deployment subsystem
  
 
The builder system will be driven by the deployment subsystem.
 
The builder system will be driven by the deployment subsystem.
Line 41: Line 41:
 
That way, we can use Jenkins also to perform the builds (in the builder subsystem/service).
 
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.
 
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
+
It will be great if more than one folks participate in the DSL discussions being proposed by Mistral guys
+guys
 
 
(ref. Email on Openstack-dev list).
 
(ref. Email on Openstack-dev list).
 
  
 
Builder subsystem/service:
 
Builder subsystem/service:
- Investigate Jenkins
+
- Investigate Jenkins
- Investigate Mistral
+
- Investigate Mistral
  
  
 
Additional Issues:
 
Additional Issues:
- Long running workflows would need Solum to use trusts (and renew tokens periodically).
+
- Long running workflows would need Solum to use trusts (and renew tokens periodically).

Revision as of 19:01, 31 March 2014

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.

non-framed

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).