What are we going to do to change the public data types?

[arschles]

Data types should be cleaned up in preparation for our beta release (at which point we should keep them backward compatible. see https://github.com/kubernetes-incubator/service-catalog/wiki/Roadmap#010 for detail). Some ideas:

• Removing OSB prefixes from some fields in Instances (Determine long-term plan for OSB Organization and Space GUIDs #583)
• Moving the checksum (Move "Checksum" to *Status resource #852)

Note that this issue specifically targets the 0.0.7 release for changes to the public data types. We will create another issue for future milestones if necessary.

[pmorie]

Moving this to the beta release milestone.

[arschles]

I'd like everyone to look at our data types (Broker, ServiceClass, Instance and Binding) between 5/1/2017 and 5/8/2017. Come to the SIG meeting on 5/8 with suggestions for changes. We'll decide on the final data types and implement necessary changes for the 0.1.0 release scheduled for 5/17/2017

[MHBauer]

For top-level names:

In the context of Service-Catalog and Service-Broker, I think the ServiceClass and ServicePlan names are the odd ones out and should be Service and Plan.

Within the context of kubernetes, Service could be problematic. I do not see any problem with Plan.

[duglin]

I'd like to better understand why we need a Checksum property. For Binding it should write-once so at worst we may need a boolean flag to indicate if we've created the binding on the broker yet or not. For Instances it seems like a boolean to indicate that we need to sync with the broker should be sufficient. Do we care which field changed? Especially when the checksum won't tell us which one, and right now only "plan" can change anyway. I'm not sure I see the value of the extra complexity of a Checksum when a boolean "dirty" type of flag will do.

(edit) @vaikas-google explained why we need to use a checksum instead of a dirty bit - so we can drop that part of the conversation.

[duglin]

Also, whether we keep checksum or not, it seems like that should be in the Status struct since its read-only to the user, right?

[MHBauer]

I think checksum to status makes sense.

[pmorie]

I'd like to better understand why we need a Checksum property.

For posterity: we need the checksum field because we can't query the OSB API to see what the last successful state we reconciled to was. (See #582 and #573)

I agree - for now binding should be write-once. We could change to a boolean in the status if we wanted to. If we ever become able to update binding parameters, and we do not yet have a way to query the last values sent (see openservicebrokerapi/servicebroker#159), we would need to add the checksum back for bindings.

[pmorie]

Related:

• Store dashboard SSO information for a service in a k8s secret #813
• Description for ServiceClass and ServicePlan should be required #828
• Add bindable field for Plan #814
• Kubernetes names of ServiceClass and Plan versus OSB Guids #802

[MHBauer]

How about #297 ?

[pmorie]

@MHBauer I just closed #297, but that would have been in scope if there was work to do :)

[duglin]

opened #852 to deal with the checksum topics

[duglin]

@arschles can we close this since it appears we have PRs and issues to track the issues mentioned?

[pmorie]

I think #1080 supercedes this