search

kubernetes-retired / service-catalog

Consume services in Kubernetes using the Open Service Broker API
https://svc-cat.io
Apache License 2.0
1.05k stars 385 forks source link

Onboarding of the Service Binding Specification #2857

Closed arthurdm closed 2 years ago

arthurdm commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

arthurdm commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

/remove-lifecycle stale

k8s-triage-robot commented 3 years ago

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:

You can:

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

/lifecycle stale

scothis commented 3 years ago

/remove-lifecycle stale

k8s-triage-robot commented 2 years ago

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:

You can:

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

/lifecycle stale

k8s-triage-robot commented 2 years ago

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:

You can:

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

/lifecycle rotten

k8s-triage-robot commented 2 years ago

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:

You can:

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

/close

k8s-ci-robot commented 2 years ago

@k8s-triage-robot: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/service-catalog/issues/2857#issuecomment-1025035836): >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][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.