Include labels in ServiceInstance definition

[darahayes]

Hi folks, on the Red Hat Mobile team we're building out a number of APBs for provisioning mobile services on OpenShift.

In our case, we need each ServiceInstance to have some labels. Right now we're doing some janky stuff in our APBs to retrieve the ServiceInstance name and then add labels after it's been created.

The result of this PR is that we can define labels in apb.yml and the apb serviceinstance command will include those labels in the ServiceInstance yaml file that gets created. However I'm not sure if this change will also propagate into the actual provisioning of the ServiceInstance when the APB is run.

I'd love if someone could point me in the right direction so we can implement this behaviour

[rthallisey]

However I'm not sure if this change will also propagate into the actual provisioning of the ServiceInstance when the APB is run.

Since you're adding it to the ServiceInstance resource, it will propagate to the ServiceInstance on provision.

In our case, we need each ServiceInstance to have some labels. Right now we're doing some janky stuff in our APBs to retrieve the ServiceInstance name and then add labels after it's been created.

Are you trying to use labels to establish a dependency between two apbs? Or is the goal to pass information between a running apb and a soon to be running apb? I'm just trying to better understand the whole picture in case I can offer some additional input.

[dymurray]

I'm not opposed to this change, but it does require a minor version bump if we are going to add an additional optional field to the APB spec. I also would like to know how you guys are using labels because it is a use case that we have discussed recently as well.

[eriknelson]

Sounds like a use-case a few people have been interested in. Probably deserves some attention and a proposal, since the broker will need to support this as well.

[dymurray]

+1 to Erik's point about a proposal. This is also relevant to the discussion around dependent APBs.

[maleck13]

One of the uses here is to essentially provide useful metadata for other consuming clients. For example a CLI or a UI. Being able to add labels means that the UI or CLI can filter out the services instances to the ones it is interested in without needing to track back up to the ClusterServiceClass itself. Being able to add metadata to objects like the serviceinstance and bindinginstance etc provides great utility IMO

Different question, is this a feature that belongs in the service catalog. Where as part of the service class definition a set of labels can be defined that the catalog then appends to each object created for services of that type.

I am happy to work with @darahayes here to come up with a proposal

[rthallisey]

Different question, is this a feature that belongs in the service catalog. Where as part of the service class definition a set of labels can be defined that the catalog then appends to each object created for services of that type.

It sounds like a useful feature. Bring it up with the catalog and see what folks think.

[maleck13]

issue created here back in September by myself (lol) updated with more details https://github.com/kubernetes-incubator/service-catalog/issues/1222

[dymurray]

@darahayes Could we get an update on this? Curious if you need this merged or how it's being used.

[maleck13]

@dymurray there is a proposal in progress for the service catalog to allow labels and annotations to be specified in the metadata for the cluster service class. If you look at the last few comments it is clear.

an option to specify some meta data (annotations and labels ) on the ClusterServiceClass that are then added to any child resources created from the ClusterServiceClass. I have a particular neeed for service instances, service bindings and the credentials secret.