-
Feature Request
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
None
-
Product / Portfolio Work
-
None
-
False
-
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
None
- Proposed title of this feature request
Allow multiple Containerfile snippets for on-cluster Image Mode.
- What is the nature and description of the request?
Currently, the MachineOSConfig only allows one Containerfile to be specified. A factor in making OpenShift "layering native" I think will be to make this more flexible so that e.g. other OpenShift components can feed into the layering process with additional things without interfering with any user-provided bits. For example, a GPU operator may want to inject GPU drivers.
This is not very different from MachineConfigs today and how other operators may themselves create MachineConfigs. It's helpful to users as well because they can better segregate independent layering operations into separate snippets (again, not unlike MCs).
One way to do this of course is to:
- Add a new CRD (or abuse ConfigMaps) to define Containerfile "snippets".
- Enhance the MachineOSConfig spec to support either an inlined Containerfile (as today), or a list of the above CRD.
- When building, the build controller merges the snippets in a well-defined order before passing off to Buildah. This would probably require some Containerfile parsing to do this safely.
Adding a new CRD of course is not to be taken lightly. There is also the question of how this interacts with the OpenShift Pipelines work. Ideally, this could somehow be offloaded to that flow (for example, operators could define new stages that would run as part of the pipeline), but at the same time, (1) having a single API through which any operator/user can interact with the layering mechanism is needed, and (2) having it work OOTB without additional requirements makes it much easier to depend on. OTOH, maybe it's fine to say e.g. "if you want to use operator X, you also need to install OpenShift Pipelines and switch to that build strategy".
- Why does the customer need this? (List the business requirements here)
Allowing other operators to extend layering will allow us to provide a better user experience when changes to the host are required.
- List any affected packages or components.
Mainly the MCO and APIs.