Difference between revisions of "Solum/ApiModel"

Revision as of 07:24, 28 April 2014

The point of this design is to try and model the use cases to the API better.

From https://wiki.openstack.org/wiki/Solum: “An OpenStack Related Stackforge project designed to make cloud services easier to consume and integrate into your application development process. “

Our current API models a Plan to Deployment but does not cope well with intermediary steps that a development process requires (such as tests, image building and environments).

So we need to enable someone to use their source tree (git repo) as a tool for building images, running tests and deploying into a variety of environments.

The main entities that the user needs to deal with is: their application source code the application requirements (both build and runtime) the desired development steps (eg. build, test, deploy) the deployment environment (how and where the application is run “dev”, “staging” & “production”)

An example: Given a git repo, whenever there is a commit pushed to the repo: run local unit tests build an image from the app (with any requirements pre-built) deploy to a “staging” environment (where manual testing is done) deploy to the production environment

Qu: How does the image have the correct software installed? Ans: we natively support heroku style applications and allow custom images via the language pack definition.

Qu: What is an environment? Ans: (still under discussion, but…) credentials, endpoints, location (region & AZ), compute type (VM, container) and scaling info.

Qu: How does the deployment have the correct runtime services? Ans: we need somewhere to define the application’s service requirements (plan or similar)

applications:
 thingy:
   git_url: git://x.me/a.git 
   services: 
     - trove
       remote_logging
   config:
     custom_env: foo
environments:
 default:
   compute: docker
   trust_token: bla-bla
   region: SYD
   flavor: m1.small
 production:
   trust_token: foo-fee
   region: US1
   flavor: m1.large
lifecycle:
 check:
   type: repo_job
   cmd: tox
 gen_template:
   type: generate_template
   depends_on: check
   application: thingy
 build:
   type: repo_job
   depends_on: check
   cmd: “solum-build-app .”
 deploy:
   type: deploy_stack
   environment: production
   template: {get_output: gen_template}

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

Build jobs need to be run on disposable VM's to be secure.

@@ Line 1: / Line 1: @@
-The point of this design is to try and model the use cases to the api better. Solum's primary
+The point of this design is to try and model the use cases to the API better.
-value is basically and easy to use ci/cd for OpenStack.
-So enabling someone to use their source tree (git repo) as a tool for building images, running tests and deploying
+From https://wiki.openstack.org/wiki/Solum:
-into a variety of environments.
+“An OpenStack Related Stackforge project designed to make cloud services easier to consume and integrate into your application development process. “
-The entry point of Solum would be the deployment subsystem with a 'lifecycle' definition as the input.
+Our current API models a Plan to Deployment but does not cope well with intermediary steps that a development process requires (such as tests, image building and environments).
-This 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).
-[[File:Solum-model.png|non-framed]]
+So we need to enable someone to use their source tree (git repo) as a tool for building images, running tests and deploying into a variety of environments.
-Example of the application lifecycle definition:
+The main entities that the user needs to deal with is:
+their application source code
+the application requirements (both build and runtime)
+the desired development steps (eg. build, test, deploy)
+the deployment environment (how and where the application is run “dev”, “staging” & “production”)
-  lifecycle:
+An example:
-   environment: Develop
+Given a git repo, whenever there is a commit pushed to the repo:
-     policy: True
+run local unit tests
-     actions:
+build an image from the app (with any requirements pre-built)
-       run_tests:
+deploy to a “staging” environment (where manual testing is done)
-         git_url: github.com/helloworld.git
+deploy to the production environment
-         cmd: tox
-       build:
-        git_url: github.com/helloworld.git
-        cmd: build_app
-   environment: Staging
+Qu: How does the image have the correct software installed?
-     policy: develop.build.success
+Ans: we natively support heroku style applications and allow custom images via the language pack definition.
-     actions:
-       deploy:
-         # we need to be able to pass the image from the dev env
-         # so we can use it here.
-   environment: Production
+Qu: What is an environment?
-     policy: Manual
+Ans: (still under discussion, but…) credentials, endpoints, location (region & AZ), compute type (VM, container) and scaling info.
-     actions:
-       deploy:
+Qu: How does the deployment have the correct runtime services?
-          heat create prod -u <somewhere> -P "image=<bla>"
+Ans: we need somewhere to define the application’s service requirements (plan or similar)
+ applications:
+  thingy:
+    git_url: git://x.me/a.git
+    services:
+      - trove
+        remote_logging
+    config:
+      custom_env: foo
+ environments:
+  default:
+    compute: docker
+    trust_token: bla-bla
+    region: SYD
+    flavor: m1.small
+  production:
+    trust_token: foo-fee
+    region: US1
+    flavor: m1.large
+ lifecycle:
+  check:
+    type: repo_job
+    cmd: tox
+  gen_template:
+    type: generate_template
+    depends_on: check
+    application: thingy
+  build:
+    type: repo_job
+    depends_on: check
+    cmd: “solum-build-app .”
+  deploy:
+    type: deploy_stack
+    environment: production
+    template: {get_output: gen_template}
-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