-
Notifications
You must be signed in to change notification settings - Fork 84
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
Deploy Quay Operator TNG with no default storage class set #358
Comments
Hi @jfroment, thanks for raising this issue! Is there a reason why this cluster doesn't have a default storage class? |
We have different types of storage backends (nfs, block...) and by design, we want to ensure that developers specify (in their templates) the correct storage class according to the environment and type of storage they need for their apps. With Quay operator v3.3.2 it was not a problem as we could specify the storage class for each component. I guess I could still label one of the storageclass as "default" in our Quay deployment CI, and then unset it. But that seems to be more of a workaround than a proper configuration. Will it have an impact on Quay storage as well? |
Thanks for giving more context. I think this is worth investigating. One of the main guiding principles of this Operator is to be as opinionated as possible as to how Quay is deployed/managed on Kubernetes. This makes it easier to develop, support, and run a cloud native application as complex as Quay. Basically, the less things you can configure, the less things can be misconfigured. Since our team is also responsible for running Quay.io (which runs on Kubernetes), we can take a lot of our learnings of running Quay at a massive scale to craft the ideal deployment configurations for Kubernetes. But feedback like this is important for us to consider as the Quay Operator matures. When developing features for the Quay Operator, we will try to avoid implementing things that Kubernetes (or other tools) already do well. I noticed this issue for setting the default storage class for a namespace; unfortunately, it doesn't seem to have received much attention. However, it's possible that we could adopt our own solution of annotating the We'll keep this issue open and triage it as part of improvements for our future work. Let us know if you have any ideas that would fit your workflow! |
To answer your second question: yes, the Quay |
Thanks for this great explanation! |
I second the opinion, that we should not be forced to use the default storageclass.. |
Is there a workaround for forcing a specific storageclass, or do I have to modify the operator? |
Is there a supported way to specify the storageclass? |
what would be the best to define the StorageClass for Quay managed pvc? as we dont want to use default StorageClass |
+1 on this: in a cluster with several storage classes, it's IMHO very important a way to specify which storage class(es) the quay components should use. Thanks |
+1 on this |
Hello,
I'm trying to deploy Quay Operator (TNG version) on a OCP 4.5.15.
I'm following the guidelines provided in the README (Getting Started section), but it seems that databases PVC are not bound.
On this cluster, there is no default storage class, so that developers are forced to specify one in each of their templates.
But I'm feeling TNG operator does not support this, because:
and so
I set up RHOCP operator, alongside NooBaa datastore object (which is ready). There is no ObjectBucketClaim created, but I can see that there is a new StorageClass provided by NooBaa:
Is there a way to force TNG operator to set this storageclass as the one used to provision PVC? Or can I use my own storage classes for the databases PVC, and only use NooBaa as PV for Quay pod? If so, am I forced to set the databases as "unmanaged"?
Thanks in advance!
The text was updated successfully, but these errors were encountered: