openshift-diagnostics: package as oc alias

[sosiouxme]

Makes openshift-diagnostics a symlink to oc (like kubectl) so that
it can be packaged inside origin pods to be run from diagnostics.

fixes #18141

[sosiouxme]

This is the approach I personally prefer for openshift-diagnostics, just because it doesn't require a whole separate binary for this tiny function. But I'm not stuck on it, #18145 could be fine too. Someone tell me which way to go :)

Looks like the bot assigned the world on this one. That wasn't me.

[sosiouxme]

/retest

[juanvallejo]

This is the approach I personally prefer for openshift-diagnostics, just because it doesn't require a whole separate binary for this tiny function.

I agree with this approach as well.
Changes lgtm from a cli perspective.

/lgtm

cc @deads2k

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: juanvallejo, sosiouxme
We suggest the following additional approver: liggitt

Assign the PR to them by writing /assign @liggitt in a comment when ready.

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

Needs approval from an approver in each of these OWNERS Files:

• OWNERS

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[deads2k]

I'm -1 on this.

Aliases and polymorphic commands have not served us well in the past. Why can't you be built separately or even be a different image. I don't see a strong reason to couple our diagnostics to the same release schedule as oc. Especially as oc, kubectl, and ktl become more independent from the server bits.

[sosiouxme]

Why can't you be built separately or even be a different image.

The binary can be built separately as it is now; that's the other PR. It just seems like a waste of space ( >100MB ) when everything it needs is already in the oc binary except the command definition.

There are a number of benefits to reusing the existing image. First, no need to build, ship, track a separate RPM and separate image (which is no small job for RCM, security team, etc). Second, the image is likely to be present when the diagnostic calls for it (less user time spent waiting for it to pull; the whole reason we went with the deployer image). I think there would have to be a pretty compelling argument for the overhead to separate out this tiny function.

I don't see a strong reason to couple our diagnostics to the same release schedule as oc.

Diagnostics are in oc already. This is just another diagnostics client running in the pod. I don't see why we would want those on a separate release schedule.

Especially as oc, kubectl, and ktl become more independent from the server bits.

Not sure what you mean... these aren't server bits either.

[sosiouxme]

In fact... since this command just runs some "special" diagnostics, I could do away with it and unify these with the existing diagnostics command instead. Just pull in #17773 (which lacks only an approver) and add hidden oc adm diagnostics subcommands for network and pod diagnostics. @deads2k would that be better?

[deads2k]

and add hidden oc adm diagnostics subcommands for network and pod diagnostics. @deads2k would that be better?

Yeah. I can go with subcommands under oc adm.

[sosiouxme]

closed in favor of #18186