Proposal: Scope of initial beta release

[pmorie]

We've been having some really productive design discussions lately that have been helping me personally feel out where people stand on the overall scope of what our initial beta release should be.

I spent some time this week thinking exactly what the goals and scope should be for an initial beta release.

We should expect that we will have more users after an initial beta release, since many users will not use APIs that are alpha. For this reason, it's important to find a compact, usable nucleus for the initial beta release that unblocks users and allows us to begin getting additional feedback from the community.

Proposed goals

• Make it possible to support service catalog in production environments
• Finalize support for core OSB fundamentals like parameter and plan updates to unblock users
• Provide a smooth experience for users with robust handling of corner-cases
• Allow service brokers to provision resource in Kubernetes under the identity of the user that requested them

Design doctrine

It's important to understand that we necessarily cannot envision all future use-cases for this project and thus cannot design for everything up-front. We should be strategic about where we design for future extensibility.

We should have design documents that are checked into the repository for the major design work elements of this release.

Targeted release version of Kubernetes

I propose that we target version 1.7 of kubernetes - the current version of catalog works on 1.7 and the API aggregator is at a beta level of maturity in 1.7.

Major features

I propose that we scope our initial beta release to the following major features / work items:

• Backward compatible API:
  • API resource names finalized (Finalize naming of resources in servicecatalog API group #1080)
  • Kube names of ServiceClass and Plan determined (Kubernetes names of ServiceClass and Plan versus OSB Guids #802)
  • Use Generation instead of checksum (Use Generation instead of checksum to detect changes in spec #1095)
  • Create new resource for plan (Scalability of retrieving ServiceClasses #454)
• Brokers:
  • API for refresh settings (Configure broker relist behavior on a per-broker basis #705)
  • Refresh semantics (Broker update semantics #801)
  • API for OSB API version to use for broker (Add API surface for broker API version and alpha OSB feature support #982)
  • Opaque bearer token auth (Implementation: Support for Bearer token auth between Service Catalog and brokers #1053)
  • TLS verification of broker (Broker TLS authentication #1064)
• Instances
  • API for sourcing parameters from secrets and configmaps (Design: Instance/Binding parameters #1075)
  • Orphan mitigation (error handling for OSB integration) (Implement orphan mitigation for instances #988)
  • Plan updates (Support parameter updates for Instances #816)
  • Parameter updates (Support plan updates for Instances #748)
  • User impersonation (Enable user impersonation for brokers targeting k8s #462)
  • Clear handling of deletion when an instance has bindings (Determine how to handle deprovision requests to an instance with bindings #820)
  • Ensure no other operations can start during async operations (Ensure no other operations can start during async processes. #781)
  • Reject plan changes for instances of services that are not plan_updateable (Reject updates to Instance that change plan when plan is not updatable #869)
• Bindings
  • Do not retry bindings that have failed (Do not retry bindings that have failed #1051)
  • API for sourcing parameters from secrets and configmaps (Design: Instance/Binding parameters #1075)
  • Orphan mitigation (Implement orphan mitigation for bindings #989)
  • User impersonation (Enable user impersonation for brokers targeting k8s #462)
  • Remove PodPreset integration (Remove PodPreset embedding from Binding #1030)
  • Determine whether to send app_guid on bindings (Send bind_resource.app_guid on bind requests #818)
• Documentation for overall concepts and supported use cases
  • Secret updates (Document our secret update policy #1046)

Nice to have:

• Rebase on 1.8 k8s machinery
• PodPreset being present in service-catalog API server

[duglin]

Overall the list seems fine, but I've been looking at the list of issues in github and assuming that anything tagged with "v0.1.0" is part of our goal - and I haven't done a diff between that list and the one here. So, while seeing this list here is nice, I would prefer to add/remove items from the github issue list (via labels) and use that as our official tracking mechanism since I think the list will change between now and beta.

[pmorie]

@duglin that is ultimately what we should do, but we need a discussion point to finalize the scope in a single place. I believe just about everything currently tagged with 0.1.0 is represented here, but I plan on doing another pass this morning.

Can you please comment with issues that you think are missing from this list?

[pmorie]

I took another pass through the issues labeled for 0.1.0 and I believe everything should be present in the issue description that is currently tagged (I closed a couple that didn't seem relevant anymore).

[pmorie]

To be resolved:

• What degree of further work (if any) will we do on TPR support for 0.1.0 (I guess none or as little as possible)
• What degree of work do we do for CRD support for 0.1.0

[droot]

Overall the list looks good. I am assuming that we will allow implementation of PodPreset (guarded by a feature-flag) to be merged while we work on Beta release. This will allow us to bake PodPreset implementation and integration while we wait for dependencies like k8s 1.8 (initializer will be Beta). This will help us to release PodPreset in an incremental release post Beta and not wait for GA.

[pmorie]

+1 to that @droot - I will make a specific note about that in the issue description.

[MHBauer]

Only one thing stands out to me.
I'm confused about Allow service brokers to provision resource in Kubernetes under the identity of the user that requested them, I think that's user impersonation (#462) ?

That doesn't seem like a beta thing. Is it ready to go upstream? Can we get some docs in that issue on the details?

[pmorie]

@MHBauer

I think that's user impersonation

That's correct.

It's in 'validating through implementation' upstream, so we should implement it as soon as possible to know whether it works for us, beta aside. See the updated issue description on #462 for the use-case and why it's important.

[MHBauer]

I think I'm confusing OSBAPI user impersonation with kubernetes core user impersonation.

[pmorie]

@MHBauer

I think I'm confusing OSBAPI user impersonation with kubernetes core user impersonation.

Still have questions?

[pmorie]

On the August 9, 2017 SIG meeting we established consensus on the scope in the description of this issue.

We also established a consensus to shoot for September 26, 2017 as the date to have 0.1.0 released, which coincides with the planned released date of Kubernetes 1.8.

[pmorie]

I'm not sure what the action item is for this issue, but I think we've made the important decisions. I'm happy to write something up about the scope that we check in, or message to the mailing list, or do any other combination of things people think is appropriate.

Any thoughts?

[duglin]

You could add something to https://github.com/kubernetes-incubator/service-catalog/blob/master/docs/v1/README.md but it would probably get more notice as an email

[pmorie]

How about both putting something into that doc and an email?

…

On Sun, Aug 13, 2017 at 12:24 PM, Doug Davis ***@***.***> wrote: You could add something to https://github.com/kubernetes- incubator/service-catalog/blob/master/docs/v1/README.md but it would probably get more notice as an email — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1098 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWXmK_4leFQtax9Ncu5-dG0NaCT1zhGks5sXyNPgaJpZM4Osvmg> .

[duglin]

sure

[nilebox]

FYI I scanned through the issues required for beta, see the status gist.