Difference between revisions of "Solum/ApiModel"

Revision as of 03:48, 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.

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