Is this Feature/Enhancement related to an Existing Problem? If so, please describe:
In order to better break apart products manifests with optional images sets it would be more helpful to be able to break those up into hauler manifests that get recursively called for better reuse.
Describe Proposed Solution(s):
An example of this would be the rke2-manifest.yaml which currently corresponds with an rke2 release https://github.com/rancher/rke2/releases/tag/v1.34.2%2Brke2r1 asset of rke2-images-all.linux-amd64.txt. If instead we a recursive structure could be used a manifest could look like:
apiVersion: content.hauler.cattle.io/v1
kind: hauler-meta-manifest
metadata:
name: carbide-rke2-images
spec:
manifests:
- name: rke2-images-core.yaml
- name: rke2-images-canal.yaml
... etc ...
That way the manifest could easily be modified to remove unused sets of images with clear use demarcation points the same way the release image lists currently break it out.
Describe Possible Alternatives:
Another option besides adding a new kind could be extending the existing kinds to support it, which would declutter some potential manifests but add additional complexity of dealing with now potentially multi file type manifests to another type (i.e. how does an added manifest that adds files get treated in an image kind manifest?).
Additional Context:
Is this Feature/Enhancement related to an Existing Problem? If so, please describe:
In order to better break apart products manifests with optional images sets it would be more helpful to be able to break those up into hauler manifests that get recursively called for better reuse.
Describe Proposed Solution(s):
An example of this would be the rke2-manifest.yaml which currently corresponds with an rke2 release https://github.com/rancher/rke2/releases/tag/v1.34.2%2Brke2r1 asset of
rke2-images-all.linux-amd64.txt. If instead we a recursive structure could be used a manifest could look like:That way the manifest could easily be modified to remove unused sets of images with clear use demarcation points the same way the release image lists currently break it out.
Describe Possible Alternatives:
Another option besides adding a new kind could be extending the existing kinds to support it, which would declutter some potential manifests but add additional complexity of dealing with now potentially multi file type manifests to another type (i.e. how does an added manifest that adds files get treated in an image kind manifest?).
Additional Context: