Goal

Adi Admin is able to create a shared multi-cluster environment that an application workspace can deploy apps onto. See slides 5 & 6 of the Adi Admin 2022 story.

Shared 2/14/22:  Current App Studio Private Preview Prototype - https://marvelapp.com/prototype/aefcc71/screen/85158462

Why is this important?

Environments are a key abstraction that hide complex infrastructure details (clusters, location, networking, etc.) from Abigail and her development team building their applications in a Workspace. Creating shared multi-cluster environments that meet certain company requirements and enabling self-service access to them is an important part of Adi’s role in enabling application teams to innovate and provide business value without feeling continuously blocked by IT.

Use cases

As an administrator, I need to:

• Define a shared environment using existing clusters from my inventory, new clusters created via a template (or Hive ClusterPool/ClusterSet), or by pulling in a definition from a Git source
• Provide a description and SLO (service level objective) that could be surfaced to developers to make an informed choice, e.g. “this environment has a 90% uptime guarantee with email-based support, best for internal dev applications, please don’t mine bitcoin”
• Apply policies or PolicySets from a separately-managed policy inventory
• Configure inter-cluster networking (see existing ACM Submariner integration)
• Configure an Alertmanager destination either manually or via a policy (see OCP Web Console’s configuration form)
• Define autoscaling limits (up to how many clusters can be created per ClusterPool)

• See an estimate of how much this environment is likely to cost before it’s created
• Make that environment available to the entire organization or certain workspaces
• Enable self-service access to personal environments (e.g. “sandboxes”) for developers
• Create environment templates that are used by developers to self-service new ones

Architecture Overview

• Locations will require a homogenous set of compute to start (all the same size, all GPUs, etc)
• Adding compute requires a choice of adding it to an existing Location or creating a new Location
• Existing means this new compute will likely start picking up work immediately
• New will require labels to function correctly

• Ideally we suggest default labels like cloud=foo and region=bar and user should add more
• Locations will be under the Org hierarchy but can be independent of Workspace
• Locations can be associated to multiple Workspaces
• Default inputs
• Name
• Cluster Picker -> either by name(Static), or label(Dynamic) 
• Workspace

Acceptance criteria

• A flow that includes the necessary steps to create a shared environment that’s available to a workspace
• Sync with ACM on the relationship of Environments to ACM/Hive ClusterPools and ClusterSets
• Sync with kcp stakeholders (Clayton) to ensure this aligns with kcp plans
• Sync with Cost Management on the viability of estimated cost

Out of scope

• Providers beyond ROSA won’t be available by Summit 2022, but should still be considered as part of the design
• Environments backed by RHEL/Edge devices won’t be supported by Summit 2022, but is a discussion worth having with stakeholders
• For now we can skip an embedded OperatorHub/Catalog browsing step to add operators & services; this can be done via the policy mechanism instead

Dependencies

• KCP architectural acknowledgement
• ACM/Multi-cluster Engine operator considerations, a plan for this to be enabled on-prem too