-
Notifications
You must be signed in to change notification settings - Fork 20
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
feat(api): combine Cryostat and ClusterCryostat CRDs #721
Conversation
This should be ready for review now. Apologies for the large PR, there's a lot of interconnected pieces when bumping the API version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few thoughts that came up. These are all things to address later.
dst.ServiceOptions = convertServiceOptionsTo(src.ServiceOptions) | ||
dst.NetworkOptions = convertNetworkOptionsTo(src.NetworkOptions) | ||
dst.ReportOptions = convertReportOptionsTo(src.ReportOptions) | ||
dst.MaxWsConnections = src.MaxWsConnections |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have an equivalent MaxWsConnections
config in 3.0 and I'm not sure if we should bother reimplementing this. I think this is an old holdover from when the UI didn't work too well with concurrent users in the 1.0 days.
dst.Minimal = src.Minimal | ||
dst.EnableCertManager = src.EnableCertManager | ||
dst.TrustedCertSecrets = convertCertSecretsTo(src.TrustedCertSecrets) | ||
dst.EventTemplates = convertEventTemplatesTo(src.EventTemplates) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3.0 hasn't yet reimplemented custom event templates, but when it does I'm expecting that to be done by using S3 storage rather than direct PVC access. That'll make it more complicated to support the feature from the CR level. Maybe we should drop this like we dropped the FlightRecording CRD?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would there still be a way to do this declaratively? I haven't really used this feature much, but I could see this being useful for GitOps-managed clusters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess there are a few apparent routes:
- the Operator uses an HTTP client and creates the custom event templates on the Cryostat application instances through the API like any other client. This way they still end up in S3 along with any others the user may create, but without relying on the filesystem internal details
- when we do reimplement custom event templates in 3.0, we do it by direct filesystem access (PVC) like we had before rather than S3
- use S3 as a read-write store in addition to a read-only direct filesystem PVC source where additional templates can be mounted. The PVC-backed storage could also be read-write but then we need to figure out how to make the distinction apparent to users through the UI and give them a choice which one they write into etc. which is probably excessive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are other cases of things that could be useful for things like GitOps clusters, like Automated Rules as a CRD. In 3.0 those are defined in a Postgres table so IMO the most sensible way would be for the Operator to talk to Cryostat via the HTTP API there, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems reasonable. These sorts of features would likely never be possible for the Helm Chart, but that could be an advantage of using the operator instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then again, we do have other things that seem to make the most sense as files directly injected into the PVC still, like TLS certs...
} | ||
|
||
func convertSpecFrom(src *operatorv1beta2.CryostatSpec, dst *CryostatSpec) { | ||
dst.Minimal = src.Minimal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm in favour of removing the minimal
config option: cryostatio/cryostat-helm#122
/build_test |
So the equivalent to the old ClusterCryostat InstallNamespace is now just that the Operator will deploy Cryostat into the Namespace in which the Cryostat CR is created, right? When I try to create a new Cryostat CR through the OpenShift UI: The TargetNamespaces list is just a text list, no dropdown selector of namespaces to choose from. Is that expected now? |
That's right.
Thanks for noticing this. We had a Kustomize patch for the ClusterCryostat CRD to add the descriptors. It didn't seem to be possible to define the x-descriptor using markers for the array elements, as opposed to the array itself. I updated the patch and also the initialization resource (the UI prompt to create a Cryostat) from v1beta1 to v1beta2. |
Signed-off-by: Elliott Baron <[email protected]>
* feat(api): combine Cryostat and ClusterCryostat CRDs * Make webhook internal, add tests * Add v1beta2 apiVersion with conversion webhook * Add conversion webhook tests * Run multi-namespace tests for Cryostat CRD * Formatting, generate bundle * Enable conversion webhooks * add conversion webhook to bundle, fixes * Remove log message * Update spec descriptors patch and initialization resource --------- Signed-off-by: Elliott Baron <[email protected]>
* feat(api): combine Cryostat and ClusterCryostat CRDs * Make webhook internal, add tests * Add v1beta2 apiVersion with conversion webhook * Add conversion webhook tests * Run multi-namespace tests for Cryostat CRD * Formatting, generate bundle * Enable conversion webhooks * add conversion webhook to bundle, fixes * Remove log message * Update spec descriptors patch and initialization resource --------- Signed-off-by: Elliott Baron <[email protected]>
Welcome to Cryostat! 👋
Before contributing, make sure you have:
main
branch[chore, ci, docs, feat, fix, test]
git commit -S -m "YOUR_COMMIT_MESSAGE"
Fixes: #583
Description of the change:
create
permissions on the Cryostat CRD in those namespaces for the check to pass. This ensures that a user can only create a multi-namespace Cryostat if they would have the permissions to create single namespace Cryostats in each of those namespaces.Motivation for the change:
How to manually test:
kubectl
and you should see it's a v1beta2 with thetargetNamespaces
set to the CR's namespace.spec.targetNamespaces
. Query it withkubectl
, and you should see thetargetNamespaces
set to the CR's namespace.Cryostat
permission for. This should fail.