-
Notifications
You must be signed in to change notification settings - Fork 380
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
002 design document grafana crd v1beta1 #684
Conversation
Still have some TODO and need to verify how it works in OCP. Need to implement test to see how it would actually work.
I'm leaning towards alternative1 but it's easier to talk about smaller changes in the document. At the same time I will have to rewrite the document to actually reflect the proposal
Easier to just do in a sperate PR towards the tmp v5 repo
## Proposal | ||
|
||
In short the proposal is about moving the grafana container specific config from the main GrafanaSpec to GrafanaContainer. | ||
GrafanaContainer should contain [V1.Container](https://pkg.go.dev/k8s.io/api@v0.20.2/core/v1?utm_source=gopls#Container) but with removal of a number of required values like name that will be hard coded to `grafana`. |
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 like that idea. But how can we remove fields from the ContainerSpec that we don't want to expose?
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.
This was unclear, we need to use something like the operator-tools for the deploymentOverrides but for ContainerSpec.
I don't think it exist in the current package. For starters we can add it to our code and where we only supply the fields that we think should be made available. From the top of my head, the only one we should remove is name
since it always should be grafana.
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.
We can replicate the function logic for deploymentOverride to implement some really simple blocklists, and just reject a CR definition if it tries to override a disallowed field
@NissesSenap I think we can merge this? Unless, youd still liike to extend it a bit? |
It works for me. Let's merge it and if someone have a opinion they can create a PR and we can discuss it |
@NissesSenap just a question, are you planning a conversion webhook ? |
Probably not, 5.0 will be a complete rewrite of the operator and we don't want to merge legacy code. How important do you think it is @AdheipSingh ? |
Description
A design document how the new v1beta1 grafana crd should look like.
The more feedback that we can get from the community on this the better.
Relevant issues/tickets
#667 roadmap 5.0
Type of change
Checklist
Verification steps