Design doc for Multi Enviroment.
This doc is to cover:
The current flows (v1) and OSIO service interactions with tenant clusters.
What needed to be done (flows v2) to support OSD clusters in OSIO. Supporting OSD clusters will also require supporting multiple clusters/environments per user.
It doesn’t cover all our plans to improve the existing Getting Started, Build and ather services. It includes only bare minimum changes relevant to multi env support.
- 1. Models
- 2. Flows
1.1. Cluster (Cluster Service)
apiURL appDNS capacityExhausted consoleURL loggingURL metricsURL name devtools-sre token
[ ] Space (id) - WIT [ ] Cluster (apiURL) - Cluster Service ...
User - WIT [ ] environment [ ] pipeline-environment-map ...
1.4. App (codebase?) - Build Service
1.5. PipelineEnvironmentMap - Build Service
ID name [stage_name] environment (where stage_name = “test|stage|run|...”. Stage names are used in Jenkins file in the app)
1.6. EnvironmentType - Environment Service
Name version template
1.7. Environment - Environment Service
name Environment-type namespaceName Cluster (apiURL) Profile (that will be used for the account of the space owner) ProfileContributor (that will be used for the contributor accounts)
Environment-type: Possible values: build(jenkins), dev(che), test, stage, run(prod?), custom. Only one build and dev env allowed per space. Multiple deployment (test,stg,prod,custom) envs allowed per space.
namespaceName: Optional. If not specified then auto-created by Tenant Service. Namespace can be set for build and deploy (test,stage,run,custom) environments. It’s not set for dev (it’s always auto-generated because it’s user specific. Each user will have his own ns in dev env cluster for che ws)
ProfileContributor: if not set, then contributor is not allowed to create an instance of the namespace within the space/cluster. In this case the contributor will get access to the only namespace instance of that environment that is set for the space.