Discuss rough ideas for better UX around naming of ServiceClass/Plan

[duglin]

See #802

We need to make sure that we have a rough idea of how we'll provide a better UX for people so they don't have to use GUID when they really should use the human-readable names.

[pmorie]

I suggest porcelain commands for provision and bind may work to mitigate this. I would prefer that over API-level indirection.

[duglin]

I think it kind of depends on how much porcelain we can add and where. For example, we might be able to modify kubectl stuff to allow them to specify nice names on the cmd line, but can we allow them to use the nice names in the yaml? For example, some of the questions I have, and these are probably more "what's the kube way?" type of questions:

• are we allowed to twiddle people's spec data during a create? e.g. can we convert a Name string to a GUID string?
• are we allowed (or can we) modify a user's Spec data during a GET response? e.g. convert the GUID string back to a Name string?
• kind of related to the previous two, does Kube allow for there to be virtual resources? By that I mean, resources that the user can CRUD on that are really not stored in the DB exactly as it was seen by the user. For example, say the user sees one resource but its really stored as 3 different resources behind the scenes. I'm guessing no, but I thought I'd ask.

[pmorie]

are we allowed to twiddle people's spec data during a create? e.g. can we convert a Name string to a GUID string?

We can manipulate data (default, fill in fields) during a create, in general. In this case, the name of a service or plan isn't stable, so I don't think that's a good idea. If the name of a plan changes, it could break patch.

are we allowed (or can we) modify a user's Spec data during a GET response? e.g. convert the GUID string back to a Name string?

I don't think this is workable. How do you distinguish between clients that want to see the names and clients that want to see the guids? We definitely have no precedent for this in the API as far as I know.

kind of related to the previous two, does Kube allow for there to be virtual resources? By that I mean, resources that the user can CRUD on that are really not stored in the DB exactly as it was seen by the user. For example, say the user sees one resource but its really stored as 3 different resources behind the scenes. I'm guessing no, but I thought I'd ask.

I don't think virtual resources are completely out of the question but don't see an obvious link to this particular issue. What did you have in mind? Thinking about it a little, I wonder if you're thinking about something like the cf marketplace command.

[pmorie]

Rough idea for porcelain commands to smooth this out:

• kubectl plugin service-catalog list - gives you a view similar to what cf marketplace does:

$ kubectl plugin service-catalog list
SERVICECLASS     PLANS          DESCRIPTION
------------     -----          -----------
database         silver,gold    Database as a service!

• kubectl plugin provision-service - lets you provision service by name and plan name:

$ kubectl plugin provision-service my-database database silver
Provisioning a new Instance 'my-database' of service 'database' and plan 'silver'

Maybe this command supports -w to watch for the provision operation to be completed

We do not have the same issues around coordinates for bindings (since we control the names of those objects and they can be user-set), but it might also be nice to have a kubectl plugin service-catalog bind <instance> ...

[pmorie]

I personally think this should be 1.0.0, because it does not have to be done for beta.

[duglin]

not done but discussed because if we decide we need to do something radical that changes our model then we're in trouble.

[MHBauer]

Do we need both this issue and #802?

[pmorie]

Closing; we will make #1080 the issue to record all discussion of API resource naming going forward.