|
|
| (12 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | === Overview ===
| + | #REDIRECT [[Solum/Pipeline]] |
| − | 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}
| |
| − | | |
| − | === REST API ===
| |
| − | | |
| − | All the above applications/environments/lifecycle templates could be stored in glance
| |
| − | | |
| − | then we just need (can't think of a better name than "project")
| |
| − | project/
| |
| − | project/<uuid>
| |
| − | project/<uuid>/stacks/
| |
| − | project/<uuid>/stacks/<stack_id>
| |
| − | project/<uuid>/job_history/
| |
| − | project/<uuid>/job_history/<uuid>
| |
| − | | |
| − | POST project/
| |
| − | { lifecycle: <glance_id>,
| |
| − | application: <glance_id>,
| |
| − | need_git_trigger: true }
| |
| − | | |
| − | response:
| |
| − | {project_uuid: bla-abl,
| |
| − | git_trigger_url: http://}
| |
| − | | |
| − | === 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
| |
| − | | |
| − | [[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]]
| |
