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
1.1. Cluster (Cluster Service)
apiURL
appDNS
capacityExhausted
consoleURL
loggingURL
metricsURL
name
devtools-sre token1.2. User
[ ] Space (id) - WIT
[ ] Cluster (apiURL) - Cluster Service
...1.3. Space
User - WIT
[ ] environment
[ ] pipeline-environment-map
...1.4. App (codebase?) - Build Service
pipeline-environment-map1.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
template1.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.