search

servicebinding / spec

Specification for binding services to k8s workloads
https://servicebinding.io
Apache License 2.0
92 stars 35 forks source link

Redefine Provisioned Service for flexibility #223

Closed baijum closed 1 year ago

baijum commented 1 year ago

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.

https://github.com/aws-controllers-k8s/community/pull/1539#discussion_r1018479243

Signed-off-by: Baiju Muthukadan baiju.m.mail@gmail.com

scothis commented 1 year ago

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:

  1. spec extension: since extensions are inherently opt-in, there's no disruption to the existing ecosystem
  2. mapping resource: define a mapping resource that adapts the existing ACK resources to the existing Provisioned Service duck type
arthurdm commented 1 year ago

Thanks for working with other communities and increasing the adoption of the spec @baijum! 👍

I agree with @scothis's second suggestion:

mapping resource: define a mapping resource that adapts the existing ACK resources to the existing Provisioned Service duck type

I believe we'll encounter many CRs in k8s that each have their specific requirements and restrictions for their .status, so if we can have synthetic resources that maps these into the Provisioned Service, that's a clean way to go.

baijum commented 1 year ago

Based on working group discussion yesterday, we have decided to close this PR. The alternatives suggested in the comments can be used by users.