UPSTREAM: <carry>: Fix to avoid REST API calls at log level 2.

[aveshagarwal]

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1484095. Its a regression in origin master (3.7). @sjenning

This PR is carry because the previous PR to 3.6 was carry too (#13844) due to uncertainty around upstream PR (kubernetes/kubernetes#40933).

@stevekuznetsov @deads2k Also is something broken in the rebase process or any related scripts that previous carry PR (#13844) was dropped? Not to blame anyone, just informing as I am wondering if there are other carry PRs that got dropped and we are not aware causing regressions in future, so that if something is broken (process or script), can be fixed.

[deads2k]

This was not accidentally lost. It was intentionally removed since it was rejected upstream and directions for suppressing in openshift without upstream patching provided: #15660 .

[aveshagarwal]

@deads2k thanks.

[aveshagarwal]

@deads2k Do you know how to use glog's vmodule with openshift?

[deads2k]

@deads2k Do you know how to use glog's vmodule with openshift?

It's --logspec= right?

[aveshagarwal]

@deads2k nice, thanks.

[sjenning]

/assign @eparis

/retest

[eparis]

thank you switching from upstream to carry.
/lgtm

[openshift-merge-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aveshagarwal, eparis

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 [eparis]

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

[eparis]

/retest

[openshift-merge-robot]

Automatic merge from submit-queue (batch tested with PRs 16089, 16305, 16219, 15934, 16366)

[deads2k]

thank you switching from upstream to carry.
/lgtm

@eparis Why are we carrying patch for this instead of updating our deployment mechanism to pass the flags designed to keep exactly this sort of message under control? It's needless debt to tote around.

[mfojtik]

+1 this is just increasing our tech debt. @eparis can we revert this and fix it using vmodule?

[soltysh]

+1 we cannot increase the amount of our carry patches, especially if a reasonable workaround is available. Carries should by always our last resort.

[eparis]

I agree that carries are horrible. I'm still fighting upstream. Agreeing with me there would be a better solution to this problem. V(2) is the standard logging level and should not contain spammy debug.

kubernetes/kubernetes#40933

We will not ship a product with this spam at V(2). If you would like to overrule me please talk to @smarterclayton

If the answer is vmodule instead of this 1 liner that means either

1. The end user (of which we have literally hundreds) must get this right. This is an absolute non-starter.
   or
2. The openshift ansible team should deal with this. BUT that is actually saying that they must tote this tech debt instead of the master team. Two major problems with that. (a) They will not know if the location of the log spam moved. Only the team doing a rebase will know is this moves and needs updated. and (b) we have (sadly) many customers who don't use openshift-ansible. Thus they digress to case 1, which is a non-starter.

If there is a better way than this 1 liner I'm fine with that, but I admit that any such solution will suffer from the problems of 2(b).

I like to believe that I recognize that carries are the worst thing we do/have and have rarely said we need to do it. But I am saying that this time. Making our product usable and maintainable by our users will always be my top priority. Even if it sometimes means more work for us.

[deads2k]

We will not ship a product with this spam at V(2). If you would like to overrule me please talk to @smarterclayton

This needs to be agreed to as a strong goal in the upstream product or you will be chasing these across the entire stack and just hoping a local approver agrees with you. If @smarterclayton agrees with you, you two should give us a place we can point to in the community repo that gives a frequency of particular v(2) messages.

The end user (of which we have literally hundreds) must get this right. This is an absolute non-starter.
or
The openshift ansible team should deal with this. BUT that is actually saying that they must tote this tech debt instead of the master team. Two major problems with that. (a) They will not know if the location of the log spam moved. Only the team doing a rebase will know is this moves and needs updated. and (b) we have (sadly) many customers who don't use openshift-ansible. Thus they digress to case 1, which is a non-starter.

Or you choose to centralize all of your logging patches using a vmodule defaulting/reseting on the flag we're already propogating through via a shim. Making it obvious in one place, all the messages we're having trouble with, eliminating any carry conflicts, and avoiding special-case patches that require ongoing maintenance.

[eparis]

The vmodule suggestion has similar but worse carry problems since it won't conflict and you won't know you need to update it. It suffers from the same issues as 2(a).