|
|
(16 intermediate revisions by 3 users not shown) |
Line 1: |
Line 1: |
− | The point of this design is to try and model the use cases to the API better.
| + | #REDIRECT [[Solum/Pipeline]] |
− | | |
− | 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
| |
− | | |
− | [[File:Solum-internal.png|non-framed]] | |
− | | |
− | 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.
| |
− | | |
− | [[File:Solum-nodepool.png|non-framed]]
| |