Redefine Provisioned Service for flexibility #223
Conversation
There are real world Services where the resource schema is auto-generated and no controll over what fields may get added to the status. See this discussion in ACK project. aws-controllers-k8s/community#1539 (comment) Signed-off-by: Baiju Muthukadan <[email protected]>
| 1. a `.status.binding` field which is a `LocalObjectReference`-able (containing a single field `name`) to a `Secret`. | ||
| 2. `.metadata.name` pointing to the Secret | ||
|
|
||
| The `Secret` **MUST** exist in the same namespace as the resource. The `Secret` data **SHOULD** contain a `type` entry with a value that identifies the abstract classification of the binding. The `Secret` type (`.type` verses `.data.type` fields) **SHOULD** reflect this value as `servicebinding.io/{type}`, substituting `{type}` with the `Secret` data type. It is **RECOMMENDED** that the `Secret` data also contain a `provider` entry with a value that identifies the provider of the binding. The `Secret` data **MAY** contain any other entry. To facilitate discoverability, it is **RECOMMENDED** that a `CustomResourceDefinition` exposing a Provisioned Service add `servicebinding.io/provisioned-service: "true"` as a label. | ||
|
|
There was a problem hiding this comment.
@baijum one other possibility I can think of is checking first for a servicebinding.io/binding-fieldpath annotation on a CR and if found, use that information to find the field within the Spec or Status that houses the Binding. That way, things like ACK could store the binding in, say, Status.ACKResourceMetadata.ServiceBinding and set an annotation on CR's of servicebinding.io/binding-fieldpath=status.ackResourceMetadata.serviceBinding. This would be extensible and allow for use cases where the CRD's schema is generated or cannot otherwise accomodate a Status.Binding field.
There was a problem hiding this comment.
@jaypipes Using annotation to specify the binding field path is a good idea. If the annotation is missing in a Provisioned Service, the default location would be the current field path (i.e., .status.binding). So, this change would be backward compatible.
|
As a general concern, any changes we make to how binding secrets are discovered will have the effect of breaking part of the ecosystem. Implementations of the 1.0 version of the spec will not understand these new semantics and will not find the binding secret. It also increases the complexity for implementors as there are more moving parts they need to be aware of and implement. This isn't to say we shouldn't try to solve this problem, but it does mean we need to be deliberate about the changes we make. As a specific concern, creating a lookup hierarchy to discover the binding secret is problematic. If we implemented the behavior as proposed then all Provisioned Services would have at least a brief moment in their lifecycle where the resource exists, but has not exposed a status as no resource can be created with status. At that moment, the secret would resolve to the name of the resource. If the secret doesn't exist, then we're projecting a volume that can never be resolved and the workload will fail. Worse, if the secret does exist but wasn't intended to be used as binding secret then we're injecting ambiguous semantics into the workload. Binding the wrong service to a workload in production can be disastrous, even if for a moment. A solution to the problem needs to satisfy to these requirements:
Potential solutions that follow these requirements:
|
|
Thanks for working with other communities and increasing the adoption of the spec @baijum! 👍 I agree with @scothis's second suggestion:
I believe we'll encounter many CRs in k8s that each have their specific requirements and restrictions for their |
|
Based on working group discussion yesterday, we have decided to close this PR. The alternatives suggested in the comments can be used by users. |
There are real world Services where the resource schema is auto-generated and no controll over what fields may get added to the status. See this discussion in ACK project.
aws-controllers-k8s/community#1539 (comment)
Signed-off-by: Baiju Muthukadan [email protected]