Open oarribas opened 11 months ago
The CRD are available in an operator's bundle image [1] so perhaps we can figure out a way to extract it from there instead of duplicating those here and having to keep it in sync over time.
e.g.:
$ podman image save registry.redhat.io/rhosdt/jaeger-operator-bundle@sha256:<sha> |tar -xvf - <layer_id>.tar -O |tar -xvf - manifests/jaegertracing.io_jaegers.yaml -O|head -4
<layer_id>.tar
manifests/jaegertracing.io_jaegers.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
[1] https://olm.operatorframework.io/docs/tasks/creating-operator-bundle/#operator-bundle
As discussed in #121, create a command to download a set of CRDs from this repo (maybe
omc pull crd
?). That way, theomc
could have an up-to-date list of common CRDs in case they are not included in the must-gather.To not conflict with custom CRDs in
~/.omc/customresourcedefinitions/
, maybe having 2 different directories there could help:~/.omc/customresourcedefinitions/omc_base
: where the above command will download the CRDs from this repo).~/.omc/customresourcedefinitions/custom
: for custom CRDs added by users. If this approach is used, when upgrading, the CRDs in~/.omc/customresourcedefinitions/
should be moved to~/.omc/customresourcedefinitions/custom
.If the two above directories are created, I think the
omc_base
should be checked before thecustom
one, or allow to configure the order with an option.