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

Description for ServiceClass and ServicePlan should be required #828

Closed pmorie closed 7 years ago

pmorie commented 7 years ago

...and not optional, as they seem to be by virtue of being pointers. Instead these fields should just be strings.

pmorie commented 7 years ago

Services: https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#service-objects Plans: https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#plan-object-

MHBauer commented 7 years ago

looks easy enough

jwforres commented 7 years ago

@bparees since this affects your broker since template descriptions are optional

bparees commented 7 years ago

@pmorie what's the justification for making them mandatory? seems unnecessarily burdensome.

duglin commented 7 years ago

the OSB API spec mandates it

bparees commented 7 years ago

you're gonna get a lot of "" descriptions.

MHBauer commented 7 years ago

They are described as REQUIRED in the API definition.

Do we need a lax flag?

pmorie commented 7 years ago

@bparees if they're required, I'm inclined to say that we should reject services/plans that do not have them

bparees commented 7 years ago

@bparees if they're required, I'm inclined to say that we should reject services/plans that do not have them

yes i would assume that's what the service catalog is going to do (arguably is obligated to do).

it's more a question for broker authors as to what they want to do if they don't have sufficient information to provide a useful description of the service/plan (in our case, a template where the template author did not provide a description). I'm inclined to have us just generate one, like "this is a %name% template."

bparees commented 7 years ago

@jim-minter fyi.

pmorie commented 7 years ago

@bparees i think that is fine. We should have guidance for template authors intending to integrate with catalog that lets them know there's an incentive to write a description for their template.

vaikas commented 7 years ago

@bparees @pmorie Yeah, if there's a broker that wraps templates, then I'd push/force/encourage the template writers to provide meaningful descriptions. Not sure how the user of the catalog is going to just choose these serviced templates just based on the name?

bparees commented 7 years ago

@bparees @pmorie Yeah, if there's a broker that wraps templates, then I'd push/force/encourage the template writers to provide meaningful descriptions. Not sure how the user of the catalog is going to just choose these serviced templates just based on the name?

it's pretty easy to envision people just playing around w/ this stuff who just want to quickly see if they can make a template show up in the service catalog tripping over this.

vaikas commented 7 years ago

For playing around, then they can still just put the description themselves as 'service'? It hardly seems worth it to add extra machinery and not encourage good habits from the get go because adding a description just seems so trivial to do?

MHBauer commented 7 years ago

I do not understand the template conversation. There seem to be two separate uses of the word template.

bparees commented 7 years ago

i'm pretty sure all the uses of "template" in this thread refer to openshift templates, which are a way of defining a set of openshift/k8s resources that will be created together. We're creating a service broker which will let you pick a template and deploy it (meaning create the resources it defines).