KREP-003: Decorators (Collection Watching)

[ellistarn]

KREP-003 introduces Decorators (a.k.a Collection Watching), an extension of Collections and ExternalRefs. We extend externalRef to support watching a collection of objects, rather than just a single object.

See the full proposal here: https://github.com/ellistarn/kro/blob/krep/docs/design/proposals/decorators.md

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ellistarn
Once this PR has been reviewed and has the lgtm label, please assign nicslatts for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[n3wscott]

Lgtm, I think you can flatten the API a little.

[n3wscott]

What if selector had an optional "Namespace" field to continue filtering labeled resources.

[ellistarn]

I wanted the full semantics to do things like opt namespaces in by label. Can you be a hair more concrete about what you're proposing? Structs?

[jakobmoellerdev]

when using Selector and NamespaceSelector, there is even more reason to keep it as Reference because even Kubernetes calls it reference

[tjamet]

I'm unsure I get the difference between Selector and NamespaceSelector

What would be in Metadata that makes it impossible to craft a good Selector?

I smell that we would gain simplicity by having a single Selector to filter object of Kind whether it's a namespace or any other object.

There is another question, whether it is allowed, to watch resources from other namespaces (or cluster-wide for namespaced RGDs).

Maybe we can inspire from NetworkPolicies and define:

NamespaceSelector a selector to match namespace labels in which the resource should be
Selector a selector to match the resource labels

[ellistarn]

The example from NetworkPolicies is exactly what I was thinking. The NamespaceSelector constrains what Namespaces we look at and the regular Selector constrains the individual objects by label.

namespaceSelector: # Only include namespaces with the opt-in label
  matchLabels:
    "opt-in-namespace": true
selector:
  matchLabels
    "opt-in-object": true

In this example, you would only include objects that are opted in in both their own metadata.labels, as well as the metadata.labels of the namespace. e.g.

kind: Namespace
metadata:
  labels:
    "opt-in-namespace": true
  ...
---
kind: Object
metadata:
  labels: 
    "opt-in-object": true

[tjamet]

Why having metadata? for backward compatibility?

[k8s-ci-robot]

@ellistarn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
presubmits-build-image	789e818	link	true	/test presubmits-build-image
presubmits-e2e-tests	789e818	link	true	/test presubmits-e2e-tests
presubmits-integration-tests	789e818	link	true	/test presubmits-integration-tests
presubmits-verify-lint	789e818	link	true	/test presubmits-verify-lint

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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-sigs/prow repository. I understand the commands that are listed here.