Add a way of defining default service versions automatically #477
Conversation
A new ConfigMap is created with the default image and ETR versions defined in it. This file is really easy to modify in a github workflow which is why it is created. The ConfigMap will be deployed together with the ETOS controller which I like because it will be easy to verify the defaults from within Kubernetes. The values in the ConfigMap are then used to replace the default tags in the Cluster CRD so that they are used when the values are not set in spec. Added a new github action which reads the latest docker images from our service repositories as well as the latest release from the ETR repository. The action then adds these versions into the ConfigMap, updating the defaults.
There was a problem hiding this comment.
Not perfect.
This kustomization is not executed when doing make install, which is quite common in local development environments.
There was a problem hiding this comment.
make install is the only command that is affected by this and from an ETOS controller perspective it is quite weird to use make install only, since it will only apply the CRDs and no controller, giving you the resources in the cluster but no controller to manage them.
Our default way of installing the controller is by using the installer created by make build-installer & make split-installer which both generate the correct manifests.
Also make deploy can be used locally to both deploy a controller and install CRDs correctly.
Let's discuss this, but my vote is on removing the make install command entirely from the Makefile.
Added create true so that we can remove the odd defaults in cluster_types. Removed the, now, unecessary images from cluster sample
Defaults work from top to bottom and if the top has not been defined in the spec yaml then the defaults from the bottom cannot be set. This change adds a default all the way up, so that the defaults properly propagate downwards.
andmat900
left a comment
andmat900
left a comment
There was a problem hiding this comment.
Is it a valid concern that the defaults are injected into the API schema instead of runtime configuration?
- Updating to new service versions requires changing the API definition, not configuration
- Different Kubernetes clusters running the same operator version could have different API schema versions (if they applied Kustomize at different times)
| - name: Get version | ||
| id: getVersion | ||
| run: | | ||
| VERSION=$(skopeo list-tags docker://${{ env.REGISTRY }}/${{ env.API_REPOSITORY }} | jq -r ".Tags | last") |
There was a problem hiding this comment.
This assumes the tags are chronologically ordered?
|
|
||
| // We do not build the GraphQL API automatically nor publish it remotely. | ||
| // This will need to be provided to work. | ||
| // +kubebuilder:default={"image": "registry.nordix.org/eiffel/eiffel-graphql-storage:latest"} |
There was a problem hiding this comment.
As alternative, would it be reasonable to let update-default-versions.yml modify these defaults here and commit the changes? This would keep the Go types as the single source of truth for defaults.
If the structure of the CRD changes, the replacements from the ConfigMap may break.
There was a problem hiding this comment.
It sounds extremely volatile to edit a source file like that.
It might be possible to do as a custom generator to controller-gen, but I have not explored that at all.
Regular "go generate" generators would not work well here since they cannot be added to the line that we are interested in and would have to edit the source file (i.e. volatile)
I don't see this problem, since it is the schema that is being deployed in Kubernetes, not the *_types.go files. The *_types.go files are used to generate the schema.
We supply the install manifest where these are defined. If someone does not install using the manifest, then they are on their own. |
2 participants
Applicable Issues
fixes: #473
fixes: #472
Description of the Change
A new ConfigMap is created with the default image and ETR versions defined in it. This file is really easy to modify in a github workflow which is why it is created.
The ConfigMap will be deployed together with the ETOS controller which I like because it will be easy to verify the defaults from within Kubernetes.
The values in the ConfigMap are then used to replace the default tags in the Cluster CRD so that they are used when the values are not set in spec.
Added a new github action which reads the latest docker images from our service repositories as well as the latest release from the ETR repository. The action then adds these versions into the ConfigMap, updating the defaults.
Alternate Designs
Possible Drawbacks
Sign-off
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Signed-off-by: Tobias Persson [email protected]