Difference between revisions of "Solum/ApiModel"
| Line 1: | Line 1: | ||
| + | === Overview === | ||
The point of this design is to try and model the use cases to the API better. | The point of this design is to try and model the use cases to the API better. | ||
| Line 8: | Line 9: | ||
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. | 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: | + | The main user entities that the user needs to deal with is: |
* their application source code | * their application source code | ||
| Line 15: | Line 16: | ||
* the deployment environment (how and where the application is run “dev”, “staging” & “production”) | * the deployment environment (how and where the application is run “dev”, “staging” & “production”) | ||
| − | + | === A usecase === | |
| − | |||
* Given a git repo, whenever there is a commit pushed to the repo: | * Given a git repo, whenever there is a commit pushed to the repo: | ||
| Line 24: | Line 24: | ||
* deploy to the production environment | * deploy to the production environment | ||
| − | + | === Definitions === | |
| − | + | I see 3 main entities: | |
| − | + | * application | |
| − | + | : git url | |
| − | + | : required runtime services | |
| − | + | : extra config: | |
| − | + | * environments (still under discussion) | |
| + | : how and where to deploy resources | ||
| + | : e.g. credentils, endpoints, location (region & AZ), compute type (VM, container) and scaling info. | ||
| + | * lifecycle | ||
| + | : the jobs to get the application from a git commit to a deployed heat stack | ||
| − | + | === Example === | |
| − | |||
| − | |||
applications: | applications: | ||
| Line 70: | Line 72: | ||
environment: production | environment: production | ||
template: {get_output: gen_template} | template: {get_output: gen_template} | ||
| + | |||
| + | === Old stuff === | ||
For DSL, we can also look at Mistral, Taskflow, Murano. | For DSL, we can also look at Mistral, Taskflow, Murano. | ||
Revision as of 08:56, 28 April 2014
Overview
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 user 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”)
A usecase
- 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
Definitions
I see 3 main entities:
- application
- git url
- required runtime services
- extra config:
- environments (still under discussion)
- how and where to deploy resources
- e.g. credentils, endpoints, location (region & AZ), compute type (VM, container) and scaling info.
- lifecycle
- the jobs to get the application from a git commit to a deployed heat stack
Example
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}
Old stuff
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.
