On Oct 1, 2013, at 7:19 PM, Vipul Sabhaya wrote: > > 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.
https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.28PUT.29 > Also if we change a single item in a given configuration, does that change > propagate to all instances that configuration belongs to? Thats a good question. Maybe PATCH'ing a configuration is not a good thing. We either have 1) drift between an attached config on an instance vs the template, or 2) a confusing situation where we are potentially updating configurations on running instances. Another possibility is that a PATCH would in effect, clone the existing template, if its in use, giving it a new UUID with the updated parameters. But im not sure i like that approach either… Its really not a PATCH at that point anyway id think. Blueprint designers, im looking to you for clarity. > 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. As in /instances/configurations, or /instances/{id}/configurations ? I do see commonality between a configuration and a bunch of instances, such that a configuration is not unique to a single instance. I can see a reseller having a tweaked out "works with _insert your favorite CMS here_" template applied to all the instances they provision.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
