Bug 1746114
| Summary: | BareMetalHost CRD is added for AWS install | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Samuel Padgett <spadgett> |
| Component: | Cloud Compute | Assignee: | sdasu |
| Status: | CLOSED WONTFIX | QA Contact: | Jianwei Hou <jhou> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.2.0 | CC: | abraren, agarcial, brad.ison, dhellmann, mpatel, rbryant, sdasu |
| Target Milestone: | --- | ||
| Target Release: | 4.3.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-08-28 12:49:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Comment 1
Abhinav Dahiya
2019-08-27 17:24:13 UTC
Currently the CRDs within the machine-api-operator are installed for all platforms. There is no way to selectively install CRDs after determining if it is a baremetal platform. IMO, not a release blocker. CRD's are part of the openshift installation, and we provide a very uniform installation across different platforms. This is analogous to the kubelet having compiled-in support for AWS cloud-provider when being run anywhere; it's just a feature, it's not enabled. Similarly, the risk of someone creating baremetal-objects against the existing CRD is likely quite low. I don't think we plan on support UPI to IPI installs, so we'll never do anything with those CRDs anyway. > Similarly, the risk of someone creating baremetal-objects against the existing CRD is likely quite low.
The problem is we highlight it in the web console when the CRD is present, which can cause confusion.
But I agree we could defer this if it's not a simple fix.
(In reply to Samuel Padgett from comment #4) > > Similarly, the risk of someone creating baremetal-objects against the existing CRD is likely quite low. > > The problem is we highlight it in the web console when the CRD is present, > which can cause confusion. > > But I agree we could defer this if it's not a simple fix. Yeah, I think the real issue is that the UX team wanted to enable/disable behavior in the UI based on whether the CRD was there. My opinion is that this is unlikely to get fixed for 4.2, and given that it's possible to check the platform type separately from checking for the presence of the CRD, I'm going to go ahead and bump this to 4.3 target. If anyone strongly disagrees, we can discuss further. This was known when we merged it. I'd propose closing as WONTFIX since it's possible to check for the platform type in a better way (the infrastructure config object). The alternative I can think of would be to have the installer create the CRD conditionally based on the platform type. Works for me. I would like to address this eventually, but I think it should be part of a larger effort to think about how the machine-api-operator interacts with platforms that have more complex deployment requirements. Not sure we need to keep this around in that case. I'll mark as WONTFIX. If anyone has a problem with that, they can re-open it. |