Onboarding of the Service Binding Specification

[arthurdm]

In a recent call with @jberkhahn and @jhvhs we have agreed to explore the donation of the Service Binding Specification to the Service Catalog SIG.

We have an issue on the spec side to track changes needed there, and this cross issue will track changes needed on the SIG side to onboard the spec.

CC @nebhale @scothis

[sbose78]

I'm curious, how does this align with the following :)

Service Catalog is a Kubernetes extension project that implements the Open Service Broker API (OSBAPI). It enables application developers to provision cloud services from within Kubernetes and integrates configuration and discovery of those services into Kubernetes resources

[scothis]

@sbose78 good question, and it's a point we should be careful with as this proposal moves forward.

Service Catalog is a bit unlike other SIGs as it has a single sub-project (is project the correct term?) under it. So when people say "Service Catalog" today, it's a bit ambiguous as to whether they are referencing the project or the SIG. Our proposal is for Service Bindings to become a new project (still not sure this is the correct term) that is a sibling to the Service Catalog project, but with both falling under the same SIG.

We don't want to imply or create any artificial coupling between the two, but they should work great together. Service Catalog does not depend on Service Bindings and Service Bindings does not depend on Service Catalog. Service Bindings must continue to be able to bind services not provisioned from an OSBAPI broker.

[arthurdm]

ya - the thought is that someone could adopt the Service Binding aspect from the SIG without needing to use or adopt OSBAPI. There's some integration effort to make them work together nicely if both present, but each should be able to stand on their own.

@jberkhahn and @jhvhs - would like to hear your thoughts on this approach.

[gorkem]

I am not sure if being associated with the Service Catalog SIG is actually for the benefit of the Service Binding Specification. Service Binding can be used in many other ways, for instance Operators and Operator Lifecycle Manager, helm charts etc. I am concerned if this association limits the perception of the specification for no good reason.

[jberkhahn]

Many sigs have many subprojects that are rather loosely related - if anything Service Catalog is unusual in how focused it is. I don't see a problem to existing as a subproject of Service Catalog, especially if you want to be part of the Kubernetes community.

[gorkem]

Sounds like you are saying just be part of a SIG no matter what the optics are .

[arthurdm]

hey everyone - thanks for the comments so far, good discussion.

My 2 cents is that from the spec's perspective one of the main challenges we have is finding a suitable umbrella home - something that solves the "API domain / group" problem but most importantly a place where we can reach the larger k8s community and increase awareness / adoption.

With that frame of mind, and being that the spec is focused solely on k8s, we started to look into the SIGs as matching our needs. There are probably other "homes" we could look into, but this felt like the more neutral place that was closer to the community we want to target.

[jberkhahn]

per the discussion at the 2/22 meeting today, here's the process for contributing existing repositories to the sig:

1. A SIG chair has to open a "Repository creation/migration" issue at kubernetes/org. They'll have to fill out who should have access to the repo and stuff like that, but it should be pretty straightforward
2. The donated repos have to satisfy these requirements from kubernetes/community
3. The kuberetes/org folks will go back and forth with the owners of the repo to make sure everything looks good and for the actual handoff

You can look at this issue and this issue to see the times we've done it before.

[jhvhs]

Please take a look at the proposed changes to the SIG charter. The purpose of the changes is to widen the scope to include projects that would not necessarily be OSBAPI specific, and might be specifications rather than implementations, but would still serve the same purpose.
Link: https://docs.google.com/document/d/1ElbThBA2sT2Q6PxoPcCX2k_grG9VHUSDeanrP7r9now/edit?usp=sharing

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[jhvhs]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[scothis]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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/test-infra repository.