Informer logging lacks type detail

[marun]

KubeFed's sync controller uses informers to watch federated resources in the host cluster and target resources in member clusters. The sync controller is configured with type information via the API to support the federation of types (e.g. CRDs) for which golang structs may not be available at compilation time. Accordingly, the sync controller configures its informers with an ObjectType (indicating the type of resource that will be watched) of nil. ObjectType is passed by an informer to an internal Reflector instance, where it is used to:

1 - check that the type of an event's object is as expected (i.e. 1)
2 - indicate the type of resource that a log pertains to (e.g. 1, 2)

Passing nil for ObjectType avoids the type check to support watching resources for which a golang struct is not available, but also results in most Reflector log messages displaying <nil> instead of a type name:

0806 13:49:50.180103    3856 reflector.go:131] Starting reflector <nil> (0s) from sigs.k8s.io/kubefed/pkg/controller/sync/accessor.go:161
I0806 13:49:50.180207    3856 reflector.go:169] Listing and watching <nil> from sigs.k8s.io/kubefed/pkg/controller/sync/accessor.go:161
I0806 13:49:50.180106    3856 reflector.go:169] Listing and watching <nil> from sigs.k8s.io/kubefed/pkg/controller/sync/accessor.go:156

Ideally Reflector could be configured with a typeName to be used in log messages. If typeName were not provided, it would be continue to be computed as expectedType.String(). A new constructor for Reflector and Informer could be added to support provision of typeName.

Note that KubeFed would likely prefer to supply a typeName of <cluster name>/<type name> to ensure traceability of an informer not just to a sync controller but also to the cluster it is targeting.

[marun]

Fixing this is likely to require changes to client-go (i.e. kubernetes/kubernetes) since that's where the informer and reflector code is sourced from.

@sttts @deads2k Your feedback on the feasibility of resolving this issue would be much appreciated.

[pjferrell]

@marun With a small change to reflector.go logging, an Unstructured object can be used for the expected type and GroupVersionKind could be used for logging. If this is acceptable, I can raise PRs.

kubefed:
snaproute-mino@45947e9

client-go:
snaproute-mino/kubernetes@f5e9b91

[marun]

@pjferrell I'm already working on this after discussing with @sttts earlier this week. He indicated that Unstructured support was desirable for the reflector but only to the degree that the kind be checked for and logged (vs gvk).

[pjferrell]

Ok, just thought I'd share the diffs since we had to address this internally. IMO... as a general purpose change it'd be more helpful to provide group and kind in logs.
We have some controllers handling config and state as different groups with same kind in a controller (would be nice for log to differentiate). For kubefed, I could imagine multiple federatedtypes with same kind, but different groups.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.