> On Sep 26, 2013, at 8:49 AM, Michael Basnight <mbasni...@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@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
