Bug 1794154

I would like understand the workflow that this is failing today, because we shouldn't need this AFAIK

Two things.  First, I misunderstood [1].  My impression was the broken CI workflow was:

1. Set up manifests/cluster-scheduler-02-config.yml with 'mastersSchedulable: false'.
2. Call 'openshift-install create ...', and have it ignore the manifest from (1).
3. #6741 adds a new 'sed' to fix the clobbered manifest.

In reality, the flow has always been:

1. Call 'openshift-install create manifest'.
2. 'sed' the manifest to set mastersSchedulable false.

and #6741 was just extending to AWS the logic we'd had since September for GCP:

$ git blame ci-operator/templates/openshift/installer/cluster-launch-installer-upi-e2e.yaml | grep mastersSchedulable
a3907909b4 (Jeremiah Stuever         2020-01-16 10:36:59 -0800 1106)           sed -i "s;mastersSchedulable: true;mastersSchedulable: false;g" /tmp/artifacts/installer/manifests/cluster-scheduler-02-config.yml
8218fea99d (Jeremiah Stuever         2019-09-20 13:15:40 -0700 1133)           sed -i "s;mastersSchedulable: true;mastersSchedulable: false;g" /tmp/artifacts/installer/manifests/cluster-scheduler-02-config.yml

So that makes me less concerned about the lack of from-disk loading.

Second, I still think setting up manifests ahead of time can be more convenient than having to stop after 'create manifests' and shuffle things around.  But since part of our shuffling in the UPI case is removing the Machine(Set)s, there's no removing 'create manifests' in this case, so the 'sed' approach isn't that big a deal.

So I'd still be happiest if all manifests we render to disk we could also load from disk.  But I don't care about this particular manifest enough to mind a NOTABUG or WONTFIX or whatever here ;).

[1]: https://github.com/openshift/release/pull/6741

(In reply to W. Trevor King from comment #3)
> Two things.  First, I misunderstood [1].  My impression was the broken CI
> workflow was:
> 
> 1. Set up manifests/cluster-scheduler-02-config.yml with
> 'mastersSchedulable: false'.
> 2. Call 'openshift-install create ...', and have it ignore the manifest from
> (1).
> 3. #6741 adds a new 'sed' to fix the clobbered manifest.
> 
> In reality, the flow has always been:
> 
> 1. Call 'openshift-install create manifest'.
> 2. 'sed' the manifest to set mastersSchedulable false.
> 
> and #6741 was just extending to AWS the logic we'd had since September for
> GCP:
> 
> $ git blame
> ci-operator/templates/openshift/installer/cluster-launch-installer-upi-e2e.
> yaml | grep mastersSchedulable
> a3907909b4 (Jeremiah Stuever         2020-01-16 10:36:59 -0800 1106)        
> sed -i "s;mastersSchedulable: true;mastersSchedulable: false;g"
> /tmp/artifacts/installer/manifests/cluster-scheduler-02-config.yml
> 8218fea99d (Jeremiah Stuever         2019-09-20 13:15:40 -0700 1133)        
> sed -i "s;mastersSchedulable: true;mastersSchedulable: false;g"
> /tmp/artifacts/installer/manifests/cluster-scheduler-02-config.yml
> 
> So that makes me less concerned about the lack of from-disk loading.
> 
> Second, I still think setting up manifests ahead of time can be more
> convenient than having to stop after 'create manifests' and shuffle things
> around.  But since part of our shuffling in the UPI case is removing the
> Machine(Set)s, there's no removing 'create manifests' in this case, so the
> 'sed' approach isn't that big a deal.
> 
> So I'd still be happiest if all manifests we render to disk we could also
> load from disk. 

Agree with that and i think that would be nice, but that is something we will implement as an RFE which we try to track in JIRA, so closing this as WONTFIX.

 But I don't care about this particular manifest enough to
> mind a NOTABUG or WONTFIX or whatever here ;).
> 
> [1]: https://github.com/openshift/release/pull/6741