-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a unique label to the Medusa bucket secret #1253
Comments
Looking at this, it actually appears that all of the ListOptions stuff is string based, so maybe that isn't the best choice. We're gonna have to go with just some NamespacedName type struct I think. |
This is actually a fair bit more work than I'd realised.
I'll spend the rest of the day on this, if I can't get close to finishing I might drop it, because there's a lot going on here and I guess we could always revert back to simply doing a direct copy, as we do now, it just isn't elegant. |
Why? We still read it as part of the Medusa reconciliation process, so we can add correct annotations to it. Even if user changes it. |
For three reasons:
Open to solutions on this (and I can see some workarounds, but I'm not sure they're good), can you explain what exactly you're proposing as an alternative @burmanm? |
@burmanm is fine with approving the prefix PR. In terms of this ticket, we think:
^ Miles to message Alex to see if we can remove the ability to reference MedusaConfigs from non-local namespaces entirely, because this is a pain in the bum. |
That would be quite a restriction as it's the cornerstone of MedusaConfigurations to be reference-able from multiple namespaces. |
This is marked as ready for review but I don't see any linked PR. Do we have a PR for this @Miles-Garnsey ? |
ok I see, you've used "Solves" instead of "Fixes" as magic word in the PR description. |
Oh? I didn't realise that we needed "Fixes", I think a PR still shows up in an issue if it is linked in any way..? I guess there is more automation here than I'd realised and our custom stuff must be more restrictive in what it is looking for. |
It won't. Here's the doc for this GitHub feature. |
TIL... |
What is missing?
The Medusa bucket secret (whether user supplied or operator-generated) should be labelled with a unique label so that it can be picked up by the ReplicatedSecrets controller for replication into individual K8ssandraCluster namespaces.
Why do we need it?
Currently, a ReplicatedSecret takes a LabelSelector, which is fine when we are marking it out as belonging to a particular cluster/DC.
However, the Medusa bucket secret is a 1:many replication into many potential clusters/DCs, not into a single cluster, namespace or DC.
As such, the design calls for the creation of a new label which will be unique per secret, so that the existing label selectors can be used to pick up the single secret for replication into the K8ssandraCluster's namespace.
Note: This ticket has been edited from an original which called for the creation of a name-based selector. This design should not be widely used as we have not evaluated the impacts of the increased label value cardinality on etcd's indexing mechanisms.
Environment
K8ssandra Operator version:
Insert image tag or Git SHA here
Anything else we need to know?:
The text was updated successfully, but these errors were encountered: