Configurable extension #459
Conversation
This will be used to customize some YAML files in the generated bundle. Signed-off-by: Greg Kurz <[email protected]>
People who want to build a custom operator for OCP usually modify
the extension name in `config/manager/manager.yaml`. This dirties
the repo which is a bit painful.
Add some `yq` magic to patch the generated CSV in the bundle
instead. People working with OCP can now do :
$ export SANDBOXED_CONTAINERS_EXTENSION=sandboxed-containers
$ make bundle
Signed-off-by: Greg Kurz <[email protected]>
| operator-sdk generate kustomize manifests -q | ||
| cd config/manager && $(KUSTOMIZE) edit set image controller=$(IMG) | ||
| $(KUSTOMIZE) build config/manifests | operator-sdk generate bundle $(BUNDLE_GEN_FLAGS) | ||
| $(YQ) eval '(.spec.install.spec.deployments[].spec.template.spec.containers[].env.[] | select(.name == "SANDBOXED_CONTAINERS_EXTENSION") | .value) |= "$(SANDBOXED_CONTAINERS_EXTENSION)"' \ | ||
| -i bundle/manifests/sandboxed-containers-operator.clusterserviceversion.yaml |
There was a problem hiding this comment.
I'd actually prefer doing the replacement in config/manager/manager.yaml before kustomizing instead of in the generated file after kustomizing since the difference between the template and the resulting generated file will end up konfusing someone I'm afraid. But this works too.
There was a problem hiding this comment.
If the replacement is done in config/manager/manager.yaml then it will be dirty... which basically negates the benefit of this commit or I am missing something ?
There was a problem hiding this comment.
There would still be benefit in setting this in Makefile and not having to know or find out where exactly you as a (new) developer need to make this change. As I said, I'm fine with this way, too.
There was a problem hiding this comment.
On the confusion side : people still need to explicitly set SANDBOXED_CONTAINERS_EXTENSION to something != from the default value (kata-containers) to change the default behavior. They shouldn't be that much surprised.
|
While technically this patch is fine, my worry is the more we deviate from a standard operator-sdk based Makefile, the harder it will be during sdk upgrades. This is from my personal experience when upgrading sdk. An alternate is to set the extension name dynamically based on the environment by patching the CSV during start of the controller manager. |
|
@gkurz: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
This simplifies custom builds for OCP with respect to the CoreOS extension name.