Bug 1732100 - [RFE] MachineConfig should support inheritance
Summary: [RFE] MachineConfig should support inheritance
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Machine Config Operator
Version: 4.1.z
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Antonio Murdaca
QA Contact: Micah Abbott
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-22 17:18 UTC by Yolanda Robla
Modified: 2019-07-24 08:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-24 08:54:51 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github openshift machine-config-operator issues 269 None None None 2019-07-22 17:18:26 UTC

Description Yolanda Robla 2019-07-22 17:18:26 UTC
Description of problem:

When working with heterogeneous worker nodes in OpenShift, we need to create some specific roles to apply MachineConfig definitions to it.
As a sample, we could have RealTime nodes, SRIOV, DPDK, etc... and we need to apply specific config bits for each of them independently.
But we need to share the same MachineConfig that applies to worker nodes, as they are all workers.
Right now we need to duplicate all definitions of MachineConfig from worker into each worker-<role> entries, causing inconsistencies and being hard to maintain.
So having the ability to create a MachineConfig that inherits from another in an upper layer will solve this issue.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Antonio Murdaca 2019-07-22 18:07:28 UTC
This is already possible today https://github.com/openshift/machine-config-operator/issues/429#issuecomment-499458138

I think we can close this BZ

Comment 2 Yolanda Robla 2019-07-23 08:26:42 UTC
Thanks for the quick answer, i'll take a look. Closing it.

Comment 3 Yolanda Robla 2019-07-23 15:05:18 UTC
I am reopening it, as this approach didn't work with worker MachineConfigPool. The reason is that this is generated dynamically, and any updates done to that are being overwritten. See my comments on https://github.com/openshift/machine-config-operator/issues/429.
I also was thinking we could define different type of computes in install-config.yaml , and then configure all of that as workers. See what i tried on: https://github.com/yrobla/blueprint-pae/blob/master/profiles/production.baremetal/00_install-config/install-config.yaml#L9 . But the installer complains about "worker" being the only valid value there.

Comment 4 Antonio Murdaca 2019-07-24 07:21:06 UTC
(In reply to Yolanda Robla from comment #3)
> I am reopening it, as this approach didn't work with worker
> MachineConfigPool. The reason is that this is generated dynamically, and any
> updates done to that are being overwritten. See my comments on
> https://github.com/openshift/machine-config-operator/issues/429.
> I also was thinking we could define different type of computes in
> install-config.yaml , and then configure all of that as workers. See what i
> tried on:
> https://github.com/yrobla/blueprint-pae/blob/master/profiles/production.
> baremetal/00_install-config/install-config.yaml#L9 . But the installer
> complains about "worker" being the only valid value there.

I've replied in MCO#429 - you're editing the worker MCP but you should create a new one inheriting from that so that the base worker MCs are there.

Comment 5 Yolanda Robla 2019-07-24 08:54:51 UTC
Ok i tried that approach of superclassing worker instead of subclassing it, and it works.


Note You need to log in before you can comment on or make changes to this bug.