Upgrading the oc client based on ETag header changes

[gklein]

No description provided.

[russellb]

Can you expand on why the new approach is more desirable? Did the previous code have a problem that this fixes?

[gklein]

No issue with the previous code.

I suggest this approach in order to allow us to upgrade oc as soon as a new build is released, and not just for a single case.

Long term it may help prevent future compatibility issues.

[hardys]

Does oc guarantee backwards compatibility? Just wondering if it would be safer to use the version from kni-installer e.g the buildid from https://github.com/openshift-metal3/kni-installer/blob/master/data/data/rhcos.json, of if always installing the latest will work, even when we lag master with pinned releases?

[gklein]

Does oc guarantee backwards compatibility? Just wondering if it would be safer to use the version from kni-installer e.g the buildid from https://github.com/openshift-metal3/kni-installer/blob/master/data/data/rhcos.json, of if always installing the latest will work, even when we lag master with pinned releases?

The reason I've suggested this solution is to help prevent issues similar to this one:
#401 (comment)

Sticking to the kni-installer version, sounds like a good option to help keep the oc client version aligned with the cluster version.

[stbenjam]

Is this change still something worthwhile? Could you rebase if so?

[russellb]

reopen if you'd like to pursue this further