feature: defaultAPIBindings are only created as initialization

[blut]

Feature Description

I'd like the workspace type as a template for different consumers creating a default binding configuration that is kept up to date with the bindings defined in the workspace type.

Proposed Solution

Ideally, newly added defaultAPIBindings should be propagated to any existing workspace of the type (and extensions?)

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

No response

[sttts]

xref Slack thread https://kubernetes.slack.com/archives/C021U8WSAFK/p1736763305689459

[blut]

So at the moment, defaultAPIBindings are initialized just once, and before enabling any Day-2 operations, here are some considerations to be discussed:

• Who owns the APIBindings? Similarly, who owns a Workspace?
  • Especially, if WorkspaceTypes are set up hierarchical, how is ownership managed?
  • Do we need to protect APIBindings from unauthorized modifications?

In my mind, a workspace may be managed by a platform team, but any contents are owned by the users of the workspace.
This includes APIBindings within the workspace, irrespective if they are created through the WorkspaceType or by the user directly.

• How to handle API Binding removal if defaultAPIBindings change in any own the included WorkspaceTypes?
  • Here, I'd suggest if an API Binding is unused, we can remove it.
  • Any used API Binding should be orphaned and remain in a workspace for the workspace owner to manage.

On a solution:

• If we add lifecycle modes (InitializeOnly vs Reconcile) I'd prefer for the workspace to maintain the mode instead of the WorkspaceType. That way, the creator of the workspace can define the behaviour & operations mode.