search

scylladb / scylla-operator

The Kubernetes Operator for ScyllaDB
https://operator.docs.scylladb.com/
Apache License 2.0
324 stars 159 forks source link

Allow setting custom namespaces for charts #1579

Open deefdragon opened 7 months ago

deefdragon commented 7 months ago

What should the feature do?

The operator and manager (at minimum) are currently unable to be changed the namespace that they are deployed in. This breaks my naming convention that I am using to manage how my operators are deployed.

Users should be able to apply a namespace value, or the included helm flag should be used for the namespace.

What is the use case behind this feature?

This is best used for keeping a consistent naming convention for namespaces that operators are deployed to (including putting them all in the same namespace). Outside of cleaner namespaces, this also makes it easier to apply policies on the resources.

Anything else we need to know?

This is a surprising overload given most helm charts take in and honor the built-in --namespace flag automatically.

tnozicka commented 7 months ago

dupe of #987

deefdragon commented 7 months ago

As has been articulated in #667 and #1305, and is reflected in the fact that this, #758, #987 and #1305 exists, this is a poor decision and goes against the adopted standard.

I am not going to dictate to scylla how to run this project, but I am going to say that breaking with the standards that every other operator follows, even after receiving reasonable pushback, does not reflect well for scylla.

I installed the scylla operator to mess around with scylla, its tooling, and the environment around it. I wished to learn about and examine it for potential use cases for my work. Given the situation here, I will no longer be doing so at this time.

tnozicka commented 7 months ago

Definitely your choice, but beyond just pointing to "I want to configure everything" and given this is opensource you don't pay for, it might be worth to change it into how I can help to solve this differently. At this point making the namespaces configurable breaks other features like:

So, the price to do all of this is high compared to, "I just want to have this configurable" and the value it brings is orders of magnitude lower. Operators are platform level extensions and I do not agree all of them make this configurable, probably the simple ones do because they don't face these challenges. There are fixed namespaces like default, kube-system and others. To pick an enterprise example about a few dozens of operators in OCP, all of them start with openshift- prefix that you can't change.

I am not saying this can't be done, and you are welcome to address it as it's opensource, but I'd rather invest my time into something that helps with actual issues then just naming when I decide how I spend my time.

Possibly when we have an operator to deploy the operator things may be more configurable but there are certainly more pressing issues to address first.

deefdragon commented 7 months ago

Scylla, in my opinion, is most akin to Elastics, Minio, Redis, Postgres etc. Databases that can be hosted completely platform agnostic.I have operators for all 4. These operators are not all simple, and of those 4 all provide adjustable namespaces. Some even do this to allow multiple operators to exist with different scopes of control. Operators may be platform level extensions, but it should still be up to the user to dictate how to organize those extensions. (Also, while I do not have an OCP cluster to mess around with and confirm, I suspect from what I have read that some of the operators it is installing to openshift-foo are just operators otherwise listed on operatorhub.io, and that ocp is setting the namespace for when installing them with OLM)

I fully understand the fact that changing to allow configurable namespaces is incredibly complex, and I also understand that there are other, more pressing issues that should take priority. I even agree that this is likely quite low on the totem pole when it comes to prioritization. There is a difference however, between a low priority ticket, and a closed ticket.

If you are truly "not saying this can't be done", then (IMO) this or one of the other tickets should be left open. Just throw the priority/awaiting-more-evidence label on it.

Even outside the option of someone coming along and doing it themselves all at once, having a ticket open in the background means that future changes are more likely to avoid making the issue worse. Some changes may even make minor tweaks that making it better. Over time, it may reach the point where there is a reasonable amount of work left, and one person finishes it off all at once.

tnozicka commented 7 months ago

not a fan of lingering issues but I don't mind it that much /reopen /priority awaiting-more-evidence

Scylla, in my opinion, is most akin to Elastics, Minio, Redis, Postgres etc. Databases that can be hosted completely platform agnostic.I have operators for all 4. These operators are not all simple, and of those 4 all provide adjustable namespaces.

Being a database operator and creating new namespaces dynamically with managed software for node tuning or doing stuff like must-gather is a far away from eachother. Also ScyllaDB has global Scylla manager which doesn't relate either. Obviously if you don't go into the areas you won't feel the pain and you can change whatever you want but at some point I tend prefer software that's tested and works.

(Also, while I do not have an OCP cluster to mess around with and confirm, I suspect from what I have read that some of the operators it is installing to openshift-foo are just operators otherwise listed on operatorhub.io, and that ocp is setting the namespace for when installing them with OLM)

just to pick a few https://github.com/openshift/cluster-etcd-operator/blob/a060517/manifests/0000_20_etcd-operator_00_namespace.yaml#L12 https://github.com/openshift/cluster-monitoring-operator/blob/b0ee4d6/manifests/0000_50_cluster-monitoring-operator_01-namespace.yaml#L13

scylla-operator-bot[bot] commented 7 months ago

@tnozicka: Reopened this issue.

In response to [this](https://github.com/scylladb/scylla-operator/issues/1579#issuecomment-1820400467): >not a fan of lingering issues but I don't mind it that much >/reopen >/priority awaiting-more-evidence > >> Scylla, in my opinion, is most akin to Elastics, Minio, Redis, Postgres etc. Databases that can be hosted completely platform agnostic.I have operators for all 4. These operators are not all simple, and of those 4 all provide adjustable namespaces. > >Being *a* database operator and creating new namespaces dynamically with managed software for node tuning or doing stuff like must-gather is a far away from eachother. Also ScyllaDB has global Scylla manager which doesn't relate either. Obviously if you don't go into the areas you won't feel the pain and you can change whatever you want but at some point I tend prefer software that's tested and works. > >> (Also, while I do not have an OCP cluster to mess around with and confirm, I suspect from what I have read that some of the operators it is installing to openshift-foo are just operators otherwise listed on operatorhub.io, and that ocp is setting the namespace for when installing them with OLM) > >just to pick a few >https://github.com/openshift/cluster-etcd-operator/blob/a060517/manifests/0000_20_etcd-operator_00_namespace.yaml#L2 Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
scylla-operator-bot[bot] commented 5 days ago

The Scylla Operator project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

/lifecycle stale