Compatibility matrix workspace-api v1<-> workspace components v2

[achtsnits]

v1 workspace provisioning triggers "static python codified workflow" creating

• one k8s namespace
• one bucket via k8s crd
• one harbor user via harbor api
• various jinja templated helmreleases as listed in provided configmap (will be automatically deployed on k8s via gitops - assuming fluxcd is running)

during workspace provisioning also endpoints are registered at eoepca uam

the following capabilities are exposed via api

• credentials to access the bucket
• credentials to access harbor
• product registration/deregistration endpoints <-- BREAKING CHANGE, not part of workspace anymore
• create new harbor registry including access grant

v2 goals

• configurable declarative flow for workspace provisioning
• no scripting magic to create a workspace, dedicated k8s crd applied to k8s api (via regular http call resp. kubectl/gitops )
• no magic and hard to test helmrelease templating
• fluxcd is purely optional
• no pre-installed out-of-the-box components (operator can adapt declarative flow for workspace provisioning)

components

• workspace pipeline (incl. "golden path" workspace pipeline definitions, amongst others an "eoepca demo" pipeline mimicking most of v1 capabilities), executed in response to a k8s claim demanding a workspace for a team
• workspace-api exposing credentials for bucket(s) and harbor access (in same format as before) and allowing to create harbor new registry

[achtsnits]

questions/considerations still TBD

• eoecpa uam integration for v2, concept unclear

• exposing credentials for bucket and harbor access through custom api (even if restricted to internal cluster use) is - lets say -controversial, mitigations could be that other BB directly go to the bucket resp. harbor-user k8s secrets via k8s api allowing the IAM BB or the operator to apply k8s native concepts to restrict access (note: this would change endpoints and response payload structure e.g. for Processing BB so breaking change), other/additional option could be to not use long lived credentials but short lived credentials (e.g. AWS Session Tokens and similar), can keep current state but needs alignment if changes are desired

• the ML BB has similar requirements as the Processing BB to put generated output on the workspace (e.g. with the Workspace BB acting as DVC remote), the Processing BB gets the workspace name passed during invocation (so it can subsequently retrieve the corresponding credentials - see above), needs concept for ML BB if desired