Add logging reference format with Group, Version, Kind, Namespace and Name

[killianmuldoon]

It would be useful to have klog reference format that includes all of the information about a resource required to identify it - i.e. Group, Version, Kind, Namespace and Name.

Would it be possible to add a type that holds all of this information (or to add fields to an existing type e.g. KRef)?

This ask comes from usage of klog in Cluster API where full references including kind etc. are needed for related objects e.g. the OwnerRef of the principle object. The struct would be useful as it allows correct logging of the full type information using both text and json logging.

This is what Cluster API has currently:

// logRef is used to correctly render a reference with GroupVersionKind, Namespace and Name for both JSON and text logging.
type logRef struct {
	Group     string `json:"group,omitempty"`
	Version   string `json:"version,omitempty"`
	Kind      string `json:"kind,omitempty"`
	Namespace string `json:"namespace,omitempty"`
	Name      string `json:"name,omitempty"`
}

func (l logRef) String() string {
	var parts []string
	for _, s := range []string{l.Group, l.Version, l.Kind, l.Namespace, l.Name} {
		if strings.TrimSpace(s) != "" {
			parts = append(parts, s)
		}
	}
	return strings.Join(parts, "/")
}

// MarshalLog ensures that loggers with support for structured output will log
// as a struct by removing the String method via a custom type.
func (l logRef) MarshalLog() interface{} {
	type logRefWithoutStringFunc logRef
	return logRefWithoutStringFunc(l)
}

/kind feature

[pohly]

This might be a reasonable addition. What API did you have in mind for creating such a struct?

[killianmuldoon]

This might be a reasonable addition. What API did you have in mind for creating such a struct?

Definitely open to advice on this 🙂.

Would it be reasonable to add it to KRef in a backwards compatible way? Or could we add a new struct e.g. KResourceRef with the same semantics as logRef in Cluster API?

[pohly]

We cannot change KRef, changing its behavior would be unexpected for some users. KResourceRef sounds good to me.

If you want to give it a try, feel free to prepare a PR. However, no promise that it then will really get merged.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.

[killianmuldoon]

Would still like to include this if we can get an agreement on the API over at #351

/reopen

[k8s-ci-robot]

@killianmuldoon: Reopened this issue.

In response to this:

Would still like to include this if we can get an agreement on the API over at #351

/reopen

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.

[dgrisonnet]

/triage accepted
/assign @pohly

[pohly]

/unassign

I don't have time to drive this.

[pohly]

/remove-lifecycle rotten