|
|
| (17 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]]
| |
