-
Notifications
You must be signed in to change notification settings - Fork 21
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
Set default Authorino image via env var #174
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
apiVersion: v1 | ||
data: | ||
DEFAULT_AUTHORINO_IMAGE: quay.io/kuadrant/authorino:latest | ||
kind: ConfigMap | ||
metadata: | ||
name: authorino-operator-env |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -314,6 +314,12 @@ spec: | |
- --leader-elect | ||
command: | ||
- /manager | ||
env: | ||
- name: DEFAULT_AUTHORINO_IMAGE | ||
valueFrom: | ||
configMapKeyRef: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what is the rationale to get the image url from the config map? why not a plain env var? The CSV will be the source of truth. new authorino image -> requires new operator bundle -> new CSV. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is so we can rely on kustomize tooling to set the variable value dynamically when we run Alternative approaches we employ for other customisations are:
Happy to change if you prefer any of these other options. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The config map is yet another resource of the bundle. When there is a new image, even though the CSV does not change (not entirely true, check my next comment), a new bundle is needed anyway because the config map changes. Your call. Just keep in mind that the image of authorino URL is also referenced in the CSV in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't like adding the ConfigMap either. I'll refactor this. |
||
key: DEFAULT_AUTHORINO_IMAGE | ||
name: authorino-operator-env | ||
image: quay.io/kuadrant/authorino-operator:latest | ||
livenessProbe: | ||
httpGet: | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
env-vars.env |
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.
RELATED_IMAGE_AUTHORINO
In the operator bundle building pipeline, there is some logic to catch
RELATED_IMAGE_*
env vars to get dependency images and build dependency tree used for some verification steps. I can try to find the docs out there.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 it is about automatic rebuild of the bundle when there is a rebuild of one of the dependencies to catch the latest builds.
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.
In the specific case of Authorino, I worry that
RELATED_IMAGE_
could be bit misleading, because of the override in theAuthorino
CR.Not that changing would be a big deal for me. I just didn't want to convey that it means the same thing as it does in Limitador.
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.
Sorry, I do not follow. The usual order of preference is:
RELATED_IMAGE_AUTHORINO
of the container (also useful for dev/testing)latest
)But, your call!
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.
Exactly how you described, but notice that Limitador is not the same, right? (Or maybe it is and I missed that in the Limitador CR.)
Last time I checked, in Authorino Operator, the related Authorino image is a default value that can be overridden in the Authorino CR. Whereas in Limitador Operator, the related Limitador image is NOT a default value that can be overridden anywhere; rather, if set, the value of the env var is final.
IOW, Limitador Operator has a "related operand image"; Authorino Operator has a "default related operand image", if that makes sense.
Another difference between Limitador and Authorino operators here.
Notice that, for Authorino Operator, we did NOT hard code a default image value for the case where the env var is missing. I'd argue that breaking the deployments if the env var is missing is better than hiding a silent potential problem that could happen by bumping all operands to latest.
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.
In the limitador operator the order of preference is as I described.
3.- Default image hardcoded in some const default variable (usually latest)
Not a bad idea. But in practice, the CSV will always have a related image (many pipeline verification steps ensure that).
Having a default hardcoded image in case it is not set in the CR nor env var is handy for dev/testing. Anyway, I also like your idea to force some env var but not a big deal and never had issues with that.
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.
There is one caveat in the limitador CR that I was not approved to implement: from the CR you can only especify the docker tag and the registry is hardcoded. I need to write RFC to fix that and blah blah blah... and in the end, the image set in the limitador CR is not a supported thing, just useful for dev/testing and a way out in case the user wants to use their own image.
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.
TIL: one can override the env var in the Limitador CR. Well, at least the image tag part. Thanks, @eguzki!