Description of problem: When generating an InstallEnv referencing non-existent nmStateConfigLabelSelector to ISO is simply generated without the nmstate configuration. This is counter intuitive from the user perspective. If the user forgot or their automation failed to create the referenced NMStateConfig the ISO is generated with no indication to the user the ISO was generated without the nmstate configuration. Version-Release number of selected component (if applicable): assisted-service-image: quay.io/ocpmetal/assisted-service:@sha256:809d0d863b7d0800a62ebddfa516b8a67adc8f0fcd114090bc2ea72f53edf4c4
i remember that we talked about it but don't remember the conclusion, what should be the expected behavior in this case @atraeger @mhrivnak ?
Thank you for reporting this, Nir. I recall past discussions around that topic. I'll bring it up in tomorrows' sync meeting.
The conclusion from the sync meeting was that lacking a way to know how many NMStateConfigs to expect, there's no way to safely wait for them. We need one of two things for correct behavior: - the user created their NMStateConfigs before the InfraEnv - The InfraEnv re-creates its ISO when new NMStateConfigs are found, and that automatically propagates to any agents that haven't yet started installing. (where we draw the line in the state machine is its own conversation)
Proposed the following doc update to reflect the conclusion Michael mentioned in comment#3: https://github.com/openshift/assisted-service/pull/1656
Moving to verified according to DOC update in https://github.com/openshift/assisted-service/pull/1656
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 (OpenShift Container Platform 4.8.25 bug fix 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/RHBA-2021:5209