Open Stack

> On Sep 26, 2013, at 8:49 AM, Michael Basnight <mbasnight at gmail.com> wrote:
> 
>> On Sep 25, 2013, at 7:16 PM, Craig Vyvial wrote:
>> 
>> So we have a blueprint for this and there are a couple things to point out that have changed since the inception of this BP.
>> 
>> https://blueprints.launchpad.net/trove/+spec/configuration-management
>> 
>> This is an overview of the API calls for 
>> 
>> POST /configurations - create config
>> GET  /configurations - list all configs
>> PUT  /configurations/{id} - update all the parameters
>> 
>> GET  /configurations/{id} - get details on a single config
>> GET  /configurations/{id}/{key} - get single parameter value that was set for the configuration
>> 
>> PUT  /configurations/{id}/{key} - update/insert a single parameter
>> DELETE  /configurations/{id}/{key} - delete a single parameter
>> 
>> GET  /configurations/{id}/instances - list of instances the config is assigned to
>> GET  /configurations/parameters - list of all configuration parameters
>> 
>> GET  /configurations/parameters/{key} - get details on a configuration parameter
>> 
>> There has been talk about using PATCH http action instead of PUT action for thie update of individual parameter(s).
>> 
>> PUT  /configurations/{id}/{key} - update/insert a single parameter
>> and/or
>> PATCH  /configurations/{id} - update/insert parameter(s)
>> 
>> 
>> I am not sold on the idea of using PATCH unless its widely used in other projects across Openstack. What does everyone think about this?
>> 
>> If there are any concerns around this please let me know.
> 
> Im a fan of PATCH. Id rather have a different verb on the same resource than creating a new sub-resource just to do the job of what PATCH defines. Im not sure the [1] gives us any value, and i think its only around because of [2]. I can see PATCH removing the need for [1], simplifying the API. And of course removing the need for [2] since it _is_ the updating of a single kv pair. And i know keystone and glance use PATCH for "updates" in their API as well. 
> 
> [1]  GET /configurations/{id}/{key} 
> [2] PUT  /configurations/{id}/{key} 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

So from this API, I see that a configuration is a standalone resource that could be applied to N number of instances.  It's not clear to me what the API is for 'applying' a configuration to an existing instance.  Also if we change a single item in a given configuration, does that change propagate to all instances that configuration belongs to? 

What about making 'configuration' a sub-resource of /instances?  

Unless we think configurations will be common amongst instances for a given tenant, it may not make sense to make them high level resources.