adr(031): Resource Labels and Namespacing

[Techassi]

No description provided.

[netlify]

❌ Deploy Preview for stackable-docs failed.

Name	Link
🔨 Latest commit	c5368cb
🔍 Latest deploy log	https://app.netlify.com/sites/stackable-docs/deploys/651eaf247d4505000867556c

[razvan]

Very nice. I think this fine for the problem that it is supposed to solve, but IMO it also a good opportunity to also clean up existing labels and better define their purpose and what their contents should be. For example, what is the purpose of the "component" label ?

In addition, maybe we should offer a simple way for users to add their own labels. It's possible with pod overrides today but it's verbose when you just want to add the same labels to all objects of a cluster/stacklet.

And code-wise, the existing label management code needs to die :)

[fhennig]

I like your idea, I've put it on the arch agenda. If you think it shouldn't be there, feel free to remove it again.

[Techassi]

Very nice. I think this fine for the problem that it is supposed to solve, but IMO it also a good opportunity to also clean up existing labels and better define their purpose and what their contents should be. For example, what is the purpose of the "component" label ?

I very much agree!

In addition, maybe we should offer a simple way for users to add their own labels. It's possible with pod overrides today but it's verbose when you just want to add the same labels to all objects of a cluster/stacklet.

This would indeed be nice. Do you have any suggestion how we can achieve that?

And code-wise, the existing label management code needs to die :)

Yes. Let's improve that!

[Techassi]

I added a section about custom user-provided labels. Have a look @razvan!

[razvan]

I added a section about custom user-provided labels. Have a look @razvan!

Thanks. Very nice. I definitely think we want cluster wide labels (IMO the most widespread use-case). And then I think we should offer down to group level labels just because we can :)

[razvan]

For cluster wide labels how about just using the labels of the cluster CR like this:

--- apiVersion: example.stackable.tech/v1alpha1 kind: ExampleCluster metadata: name: example labels: foo: bar baz: foo spec: ... 

[Techassi]

You are right. Do we want to list this as a separate option, or do we adjust option 2?

[razvan]

I would update option 2

[fhennig]

Looks good, change the status to "accepted" and add a number, and then we can merge it I think

[Techassi]

Now marked as accepted @fhennig

[sbernauer]

For me the discussion regarding the suffix in stack and demo namespaces is not resolved yet

the random -suffix. I would use tackable-<demo|stack>-<demo-name|stack-name>, as this causes constant names and makes getting started and demo documentation much easier and better understandable. In case the name clashes the user is prompted to choose a different namespace. A valid compromise would be to add a suffix in case the namespace is already taken.
ALSO: Think of this random bitnami errors, which happen quite often, and stop the installation process. We need a way that users can re-run the same "demo install" command and continue where it left off (as the current stacakblectl does). (e.g. promt the user if he wants to continue installing into a namespace that already exists)

I'm totally happy to make the decision once we implement it

[Techassi]

I added some more context to the decision. For example, the result for "Labeling Resources deployed within a Demo or Stack" states:

Yes, use `stackable-<demo|stack>-<demo-name|stack-name>(-suffix)` with `suffix` being optional and the implementation not yet decided on. 

This, in my opinion, clearly indicates that the suffix is optional and that the content of said suffix is, if added, not yet decided. This would need further discussion.

Let me know, if the ADR should further clarify this.

[sbernauer]

Sorry, missed that