Open Stack

I'll be honest, after reading your proposal Denis and looking over
what Kaleb has it feels like you both are calling 2 different things
"capabilities".  Denis, your proposal provides a way of blocking or
enabling api paths to the users.  Kaleb's proposal is more about
informing consumers of the api what things are required or not for
making those api calls.  One example that Kaleb is implementing is the
volume on create.  In the end, this will give a user the ability to
query the api for a datastore, redis for example, and find out that
redis does *not* use an ephemeral volume so they cannot pass a volume
size to the create call.  Another good example is users, again using
redis as an example.  If I am a company making a UI for trove and I
need to know when constructing the page for managing a redis instance
in trove, do I display the users tab of my UI or not.  Now I see some
definite overlap with some of the pathing stuff but if you dig further
into it, like with ephemeral volumes, I don't see a logical way to fit
that into your DSL.  Further I don't like changing the model of things
that are displayed to users via the api and having them stored in a
flat file anywhere.  Whether or not you come up with a clever way to
reload that file without restarting the trove process is irrelevant to
me.  In my mind, if data is for displaying to users then it gets put
in the database, plain and simple.  Then we don't need to do any
tricks with looking at a database entry and then looking in some
dictionary that was deserialized from a yaml file to see which ones
are actually shown or used.