-
Notifications
You must be signed in to change notification settings - Fork 1.5k
WIP: Configure Metal3 from the installer #2449
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: imain The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
To test with dev-scripts: openshift-metal3/dev-scripts#818 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RHCOS image URL shouldn't be provided via the installConfig, it's generated from the data/data/rhcos.json - e.g see ac89074
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To add more detail, I think you'll need to use a similar approach to https://github.com/openshift/installer/blob/master/pkg/asset/cluster/tfvars.go#L77 where "github.com/openshift/installer/pkg/asset/rhcos" gets imported, then you add new(rhcos.Image), to the Dependencies of this asset, and to the parents.Get in the Generate function
pkg/types/baremetal/platform.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as above I don't think we should add the rhcos url here, instead we'll reference the platform.Image
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this approach is acceptable we'll need to add actual validation for all of these similar to what I did in #2320
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes just a POC. The tricky part is that a lot of these values don't work with the validations.. eg the provisioning IP is in the form of a CIDR, the interface doesn't exist so it errors out etc.
hardys
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think adding the install-config values is OK except for the RHCOS image, and perhaps we can default some of the *IP values based on the provisioningCIDR (but that can be a follow-up).
What I'd really like to see is how we then wire these values into the CRD or configmap for the MAO?
|
/label platform/baremetal |
|
Ok so overall this looks good, we'll need feedback from the core installer team about the approach using the infrastructure manifest to provide this data to the MAO but it seems reasonable to me. As a next step I'd suggest we fix the RHCOS image issue mentioned, defer adding the install-config validation, and create a corresponding MAO PR which demonstrates how this data will be used, then we can ask for more detailed feedback from the core reviewers. |
|
Also we need defaults for all the new install-config variables in |
|
Build SUCCESS, see build http://10.8.144.11:8080/job/dev-tools/1192/ |
|
Build SUCCESS, see build http://10.8.144.11:8080/job/dev-tools/1193/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the format of this? Something like "172.22.0.1-172.22.0.10"? For validation, it might be easier if it's two separate fields with a start, and end.
|
In general, the approach looks fine to me, but I think the fields need validation. The installer team is definitely going to ask for that. CIDR fields can be validated with https://golang.org/pkg/net/#ParseCIDR |
Awesome thanks for that. It was the approach I wanted to check before diving in any further. Yeah we could do a start/end for the dhcp range too and test that it's in the network CIDR. |
|
Build SUCCESS, see build http://10.8.144.11:8080/job/dev-tools/1194/ |
a4b403f to
0d1903c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this replaces the hard-coded default for ClusterProvisioningIP, and we should probably also calculate BootstrapProvisioningIP?
hardys
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pkg/types/baremetal/platform.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This duplicates the existing ClusterProvisioningIP interface so I'll remove it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @sadasu let me know if you'd prefer to move this to the MAO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have modified https://github.com/openshift/api/pull/480/files to accept provisioningIP and provisioningNetworkCIDR as 2 seperate config items so that we do not add the CIDR to provisioningIP. As you had mentioned earlier, this is the more intuitive way of getting config.
|
Build FAILURE, see build http://10.8.144.11:8080/job/dev-tools/1271/ |
|
/retitle WIP: Configure Metal3 from the installer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
openshift/api#480 currently assumes that the DHCP range is provided as comma separated IP address pair where the 1st IP address represents the start of the range and 2nd IP address represents the last address in the range. The enhancement request (openshift/enhancements#90) has been raised with the same format in mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack we can join that here - there was some open discussion on the API PR regarding the comma-separated format vs using a CIDR to express the DHCP range, I'll assume we're going with the comma-separated approach for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sadasu another approach to resolve the API abiguity would be to also adopt explicit start/end parameters I guess, but I'll update this to align with the API PR so we can proceed with testing
Extend the baremetal platform fields to include provisioning information for the pod started by the Machine API Operator. Now includes defaults and the ability to set defaults based on just the network CIDR. Note this depends on openshift/api#480 Co-Authored-By: Steven Hardy <[email protected]>
|
@imain: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions 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/test-infra repository. I understand the commands that are listed here. |
|
Build FAILURE, see build http://10.8.144.11:8080/job/dev-tools/1277/ |
| } | ||
| case baremetal.Name: | ||
| config.Status.PlatformStatus.Type = configv1.BareMetalPlatformType | ||
| // The MAO expects the ProvisioiningDHCPRange in comma-separated format |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| // The MAO expects the ProvisioiningDHCPRange in comma-separated format | |
| // The MAO expects the ProvisioningDHCPRange in comma-separated format |
| HardwareProfile = "default" | ||
| APIVIP = "" | ||
| IngressVIP = "" | ||
| ProvisioningInterface = "ens3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why should there be an interface name default?
|
Note this is blocked on openshift/enhancements#119 since openshift/enhancements#90 and related API change this was based on got rejected |
|
@imain: PR needs rebase. DetailsInstructions 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/test-infra repository. |
|
@imain do you have a new version of this you can share? As mentioned in #2758 I wonder if it'd be easier to approach this as either two PRs, or at least two commits - one which adds the install-config interfaces and templating for the boostrap hosted ironic, and another which writes out the CR based on openshift/api#540 I think that would simplify reviews/testing, and also enable us to fix #2091 which would be useful for some ongoing testing. |
|
Should have shortly. Sorry it's taking so long. |
|
Is there anything blocking this other than openshift/machine-api-operator#460? |
Extend the baremetal platform fields to include provisioning information
for the pod started by the Machine API Operator. This is a work in progress
and I would appreciate feedback on this approach.