Split Plans from ServiceClasses

Proposed: 2017-08-08 Approved: 2017-08-15


Proposal to split Plans from ServiceClass to become a top-level object in our API.


If we get a ServiceClass, we get all of the Plans, which potentially contain a lot of data. The data of concern is primarily the Schema information used for exposing the details of a ServicePlan to a UI.

Constraints and Assumptions

Proposed Design

ServiceClass API Changes

We remove the array of ServicePlans defined inline.

// ServiceClass represents an offering in the service catalog.
type ServiceClass struct {

    // All references to ServicePlans are removed

ServicePlan API Resource

Added the kubernetes TypeMeta and ObjectMeta.

Add a Kubernetes LocalObjectReference for the ServiceClass that owns the ServicePlan.

Annotations for client and not being namespaced.

No other changes.

// ServicePlan represents a tier of a ServiceClass.
type ServicePlan struct {
	metav1.TypeMeta   `json:",inline"`
	metav1.ObjectMeta `json:"metadata,omitempty"`

        // ServiceClass is the Class of Service that this plan implements. 
	ServiceClass v1.LocalObjectReference `json:"serviceClass"`
// ServicePlanList is a list of instances.
type ServicePlanList struct {
	metav1.TypeMeta `json:",inline"`
	metav1.ListMeta `json:"metadata,omitempty"`

	Items []ServicePlan `json:"items"`

ServiceClass is cluster-scoped, so ServicePlan is cluster-scoped. Possibility of collision of two ServicePlans from different ServiceClass based on Name. This will be addressed by concatinating the ServiceClass ExternalID onto the end of the incoming ServicePlan Name and separated by a dash.

API Server Changes

Addition of new types. A not namespaced type ServicePlan and the list of the ServicePlan type. Plumbing of ServicePlan from rest input to storage. Validation code changes for ServiceClass and ServicePlan.

Controller-Manager Changes

Creation of ServiceClass separate from ServicePlan.

Separate creation of each individual ServicePlan.

Create each ServicePlan with link to the owning ServiceClass. Create ServiceClass after all ServicePlans have been created.

Lookup of a ServicePlan changes. Lookup by name can be done directly.

Lookup of all Plans a serviceclass owns involves iterating over all of the plans from every service class and accumulating them.


ServicePlanDefault controller is modified to adapt to new API and client.

Build Changes

No changes, but new build output. Code generation output for ServicePlan. Client and listers and informers.


Later Options