UPSTREAM: google/cadvisor: 1700: Reduce log spam when unable to get network stats

[sjenning]

google/cadvisor#1700

xref https://bugzilla.redhat.com/show_bug.cgi?id=1328913

@derekwaynecarr

[deads2k]

@eparis So I see the log levels as

1. error - an operation failed and the developer doesn't think it will get better on its own.
2. warning - an operation failed and it is likely to self-correct or the thing it was doing is logically optional/optimization.
3. info - explanation of initial config or other notable happening for a user
4. (1) - O(10 minutes) heartbeats, detailed reports on errors. in java, the message would go out an error, the stack would come out (1) for debugging
5. (2) - O(minute) heartbeats, detailed reports on warnings.
6. (3) - coarse grained entry or working messages
7. (4) - any tracing a component wants. You should really turn this on per-component using vmodule or something else ugly
8. (5) - really nothing uses this. We have some core apiserver library tracing here so that levels above can trace (4).

Do you have a different view of the world? I gather you're running (2), which seems questionable given this view of levels.

[eparis]

V(2) appears to be the standard log level most people use (including me). I largely agree with your levels,. I thought kube had a (loose) definition but can't find it...

The most common thing that I've seen which comes out V(2) in kube is system state changes. In any case, this is a cadvisor rebase, so even if we had a kube discussion about levels it wouldn't really be relevant to THIS PR :)

/assign
/lgtm

[openshift-merge-robot]

[APPROVALNOTIFIER] This PR is APPROVED

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

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

[deads2k]

The most common thing that I've seen which comes out V(2) in kube is system state changes. In any case, this is a cadvisor rebase, so even if we had a kube discussion about levels it wouldn't really be relevant to THIS PR :)

To be clear, this isn't a cadvisor rebase, it's a pick. That means this pull is at high risk of accidental reversion in the next rebase. We match upstream cadvisor levels closely. If upstream isn't actually bumped into kube, this will be one of dozens of conflicting packages the rebaser will be trying to reconcile.

[openshift-merge-robot]

Automatic merge from submit-queue (batch tested with PRs 14825, 15756, 16178, 16188, 16189)