Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create an implementor guide #101

Open
nebhale opened this issue Sep 15, 2020 · 6 comments
Open

Create an implementor guide #101

nebhale opened this issue Sep 15, 2020 · 6 comments
Milestone

Comments

@nebhale
Copy link
Member

nebhale commented Sep 15, 2020

The spec is focused (properly) on what implementations must and must not do. It's hard for an implementor trying to understand how they can implement the specification. We should create an implementor guide that gives a non-normative overview of the concepts and recommendations for implementing the spec.

Topics to cover include:

mounting secrets as readonly

@baijum
Copy link
Contributor

baijum commented Oct 7, 2020

I would like to see this topic explained:
What is the purpose of "type" and "provider" fields in the binding secret?

@baijum
Copy link
Contributor

baijum commented Oct 23, 2020

Add the discussion from #125 into the guide

@baijum
Copy link
Contributor

baijum commented Oct 28, 2020

Based on the discussion in the Slack:


Question: If there is a change in the ProvisionedService secret data value, how to make it reflect in the application container?

It can be achieved by triggering the application reconciliation through a change in the PodSpec-able resource.
To force trigger the application reconciliation, the implementation can change the volume name.
For example, the volume name could be constructed by combining ServiceBinding resource's .metadata.name and Secret resource's resourceVersion value. e.g., account-service-5731

@baijum
Copy link
Contributor

baijum commented Mar 9, 2021

https://kubernetes.slack.com/archives/C012F2GPMTQ/p1615207548014400


Baiju:
The spec is silent about what causes the service binding reconciler to be triggered. I can think of few cases when the service binding reconciler should be triggered. 1) When the secret pointed through provisioned service is changed or a direct secret 2) A new application with a label matching the label selector comes up 3) An application is recreated with the given name. I wonder whether the spec should say something about this?

Scott:
I've viewed this as an implementation detail for the spec itself. The spec is primarily concerned with interoperability by defining the contracts at the edges. These suggestions are useful as part of an implementors guide.

@baijum
Copy link
Contributor

baijum commented Jun 3, 2021

Document how to project ServiceBinding resource's .spec.type and .spec.provider into the container.
See this comment: #154 (comment)

baijum added a commit to baijum/service-binding-specification that referenced this issue Jun 30, 2021
@baijum baijum mentioned this issue Jun 30, 2021
baijum added a commit to baijum/service-binding-specification that referenced this issue Jun 30, 2021
Fixes servicebinding#101

Signed-off-by: Baiju Muthukadan <[email protected]>
baijum added a commit to baijum/service-binding-specification that referenced this issue Jun 30, 2021
Fixes servicebinding#101

Signed-off-by: Baiju Muthukadan <[email protected]>
@nebhale nebhale added this to the post-GA milestone Sep 2, 2021
@baijum
Copy link
Contributor

baijum commented Mar 25, 2022

I think we can move this issue to the website repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants