When CNO starts, it validates the network.config.openshift.io spec and then copies it to the status (and the network.operator.openshift.io spec). Components other than the CNO are expected to only look at status, since the spec may have unvalidated/incorrect values (eg if the administrator attempts to make a disallowed config change).

But this means that components that run at bootstrap time before the CNO starts have to look at spec rather than status, because CNO won't have copied it over yet. This is mostly OK at bootstrap time, since the values in spec are guaranteed to either (a) be correct/usable and eventually get copied over to status by CNO, or (b) be so wrong that the cluster install will fail so it doesn't matter anyway. But it makes things complicated for reconciliation loops that run both at bootstrap time and at "runtime".

One fix for this would be to just have the installer fill in the config status as well as the spec, since it's guaranteed that if the cluster comes up, then the initial spec will also be the status. (This may require changes in CNO since it may get confused if status is non-empty but there is no previous config?)

Alternatively we could run some fragment of the CNO as a one-shot at bootstrap time rather than putting the logic into the installer. This could also possibly help with the network.config.openshift.io vs network.operator.openshift.io thing.