Recommend CRD label to advertise provisioned services

[scothis]

Refs #81

[scothis]

Is there a better value for the label than "true"?

[baijum]

Is there a better value for the label than "true"?

"true" looks fine to me.

/LGTM

[scothis]

Suggested change

A Provisioned Service resource **MUST** define a `.status.binding.name` which is a `LocalObjectReference`-able to a `Secret`. The `Secret` **MUST** be in the same namespace as the resource. The `Secret` **SHOULD** contain a `type` entry with a value that identifies the abstract classification of the binding. It is **RECOMMENDED** that the `Secret` also contain a `provider` entry with a value that identifies the provider of the binding. The `Secret` **MAY** contain any other entry. To facilitate discoverability, it is **RECOMMENDED** that a `CustomResourceDefinition` exposing a Provisioned Service add `service.binding/provisioned-service=true` as a label.

A Provisioned Service resource **MUST** define a `.status.binding.name` which is a `LocalObjectReference`-able to a `Secret`. The `Secret` **MUST** be in the same namespace as the resource. The `Secret` **SHOULD** contain a `type` entry with a value that identifies the abstract classification of the binding. It is **RECOMMENDED** that the `Secret` also contain a `provider` entry with a value that identifies the provider of the binding. The `Secret` **MAY** contain any other entry. To facilitate discoverability, it is **RECOMMENDED** that a `CustomResourceDefinition` exposing a Provisioned Service add `service.binding/provisioned-service: "true"` as a label.

[nebhale]

@scothis Is this a string in a typical scenario? It doesn’t use the bool type?

[scothis]

the type for labels is map[string]string

[arthurdm]

thanks a lot for this @scothis

I am wondering if this label should be in the CRs instead of the CRDs, for two purposes:

1. Now that we support Secrets as direct services, we would like to annotate which Secrets are provisioned services
2. It is more useful to a user to know which provisioned service CRs they can bind to as opposed to which CRDs they can bind to - since it's the CR information they'll need to put in their ServiceBinding.

[scothis]

I am wondering if this label should be in the CRs instead of the CRDs, for two purposes

See #81 (comment)

1. Now that we support Secrets as direct services, we would like to annotate which Secrets are provisioned services

Restricting which specific resource are bindable is a separate concern that should probably be managed with something like OPA/Gatekeeper.

2. It is more useful to a user to know which provisioned service CRs they can bind to as opposed to which CRDs they can bind to - since it's the CR information they'll need to put in their ServiceBinding.

Before you can discover what CRs are bindable, you have to discover which kinds are bindable. If a CRD is labeled as bindable, then all CRs of that kind are bindable (absent the resource being in an intermediate or error state).

[sbose78]

Would there be use cases to let a user query which services are bindable?

If yes, supporting it on the CR too helps users query those without necessarily having the permissions to query CRDs.

[arthurdm]

Would there be use cases to let a user query which services are bindable?

hey @sbose78 - ya, I definitely had this use case in mind. I agree that supporting both CRD and CR gives enough flexibility to cover it.

[arthurdm]

@scothis - thoughts on augmenting the PR to support the label in either the CRD (for types that are bindable) or the CR (for service instances that are bindable)?

[scothis]

thoughts on augmenting the PR to support the label in either the CRD (for types that are bindable) or the CR (for service instances that are bindable)?

There's no mechanism in Kubernetes for querying with a label selector across resources. So any CR that is discoverable, first needs it's CRD to be discoverable. If the CRD is discovered, then you don't need to make individual resource discoverable (they already are).

In the case of Secrets via direct binding, #130 was merged which should address that concern.

supporting it on the CR too helps users query those without necessarily having the permissions to query CRDs.

There are better ways to solve this aspect of the problem, for example the Knative Discovery API. I don't think it's the spec's place to bless any particular approach, instead the spec should define the minimal amount of metadata required for these other approaches to flourish.

[arthurdm]

LGTM - I think #130 solves my biggest concern with Secrets.