Bug 1968425
| Summary: | [master] AgentLabelSelector is required yet not supported | |||
|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Osher De Paz <odepaz> | |
| Component: | assisted-installer | Assignee: | Fred Rolland <frolland> | |
| assisted-installer sub component: | assisted-service | QA Contact: | Yuri Obshansky <yobshans> | |
| Status: | CLOSED ERRATA | Docs Contact: | ||
| Severity: | medium | |||
| Priority: | low | CC: | aos-bugs, atraeger, frolland, mfilanov, mhrivnak | |
| Version: | 4.8 | Keywords: | Triaged | |
| Target Milestone: | --- | Flags: | frolland:
needinfo-
|
|
| Target Release: | 4.9.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | KNI-EDGE-JUKE-4.8 AI-Team-Hive | |||
| Fixed In Version: | Doc Type: | No Doc Update | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1970401 (view as bug list) | Environment: | ||
| Last Closed: | 2021-10-18 17:32:56 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1970401 | |||
@atraeger @mhrivnak why is agent label selector required? if it's something that will be used by the users then it should be optional no? @mhrivnak I also don't see why it should be required. What do you think? If it should not be required, I guess we must change this in 4.8.0, no? Yes but let's wait for confirmation from @mhrivnak Summary: - Make the labels optional. - Copy labels once when agent register. If it defaults to empty, and there are two InfraEnvs in the same namespace where a selector and label were not provided, then it won't be possible to identify which Agents go with which InfraEnv. Requiring a selector up-front, just like one is required on a Deployment, ReplicaSet, MachineSet, etc., is easy and avoids potential ambiguity or collision. It would make sense to suggest a convention of "infraenv: <Name of infraenv>" It doesn't mean that users will set a unique value, for all we know it can be foo: bar for all the infra env. As far as i know eventually we will need to know what is the InfraEnv in order to access the host in the backend (related to late binding plans) so in case of labels we can add an infra env label regardless of what we have in the agent label selector. Or even add it to the spec/status. @mhrivnak What do you think? If we auto-generate a unique label and selector, I think that would be fine. in the same namespace it will be a different label selector if we take the name. because agents will be in the same namespace then i think that it will be fine. Just to be clear, my suggestion is just to add a label to the agents with the name of infra env. Summary in the of the meeting that we had: - Move agent labels selector from the spec to the status - When agent register we create it with all the labels from agent labels list + add addition label that will mark the infra env it was created by. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.9.0 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:3759 |
It seems like AgentLabelSelector is a required field in InfraEnv CR, yet not really being used. I would expect it to be optional, and/or be explained that it's not yet implemented: oc explain infraenv.spec.agentLabelSelector KIND: InfraEnv VERSION: agent-install.openshift.io/v1beta1 RESOURCE: agentLabelSelector <Object> DESCRIPTION: AgentLabelSelector specifies a label that should be applied to Agents that boot from the installation media of this InfraEnv. This is how a user would identify which agents are associated with a particular InfraEnv. FIELDS: ... Also, kubectl explain already have a --api-version option for a distinctive instructions per-version. So we should make good use of it.