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.
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
