Remove cvo overrides

[rajatchopra]

1. Remove legacy cvo overrides template file. Follow up from Drop legacy cvo overrides #739 .
2. Remove CVO overrides altogether. Not sure if we are ready for this. @abhinavdahiya ?

This will help clean up dependence of manifest assets on cluster id. So that we can push cluster id as something that only the 'cluster' and 'destroy' targets need. Which means we can possibly re-use assets to create multiple clusters, and most importantly cluster-id stays unexposed for any erroneous edit. (PR #783)

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rajatchopra

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [rajatchopra]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[abhinavdahiya]

Remove CVO overrides altogether. Not sure if we are ready for this. @abhinavdahiya ?

I don't think we can.
@smarterclayton we do want CVO to use the cluster-id generated by installer right?

will help clean up dependence of manifest assets on cluster id. So that we can push cluster id as something that only the 'cluster' and 'destroy' targets need.

there is always going to be dependence of cluster-id and manifests. in form of infrastructure.config.openshift.io

[smarterclayton]

So we might be able to get away with the cluster managing it’s own id. It’s one less thing, we don’t want the user to specify, and if hive is ok with waiting it should be set before masters come up anyway. On Dec 5, 2018, at 6:46 PM, Abhinav Dahiya <[email protected]> wrote: Remove CVO overrides altogether. Not sure if we are ready for this. @abhinavdahiya <https://github.com/abhinavdahiya> ? I don't think we can. @smarterclayton <https://github.com/smarterclayton> we do want CVO to use the cluster-id generated by installer right? will help clean up dependence of manifest assets on cluster id. So that we can push cluster id as something that only the 'cluster' and 'destroy' targets need. there is always going to be dependence of cluster-id and manifests. in form of infrastructure.config.openshift.io — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#799 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_pyKNxUHrQIymFAiXiXzbxm299doPks5u2FragaJpZM4ZFfRA> .

[wking]

It’s one less thing, we don’t want the user to specify, and if hive is ok with waiting it should be set before masters come up anyway.

The issue with this is handling cases where we crash part-way through an install, leaving orphaned resources tagged with the cluster ID. How do we clean them up if the cluster died before it could tell us the ID? How did the resources get tagged for cleanup in the first place if the installer created them before there was a cluster to generate the ID?

[openshift-ci-robot]

@rajatchopra: PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.