If a configuration is updated that is attached to N instances then those instances will be updated with the configuration overrides. This will keep the configuration n-sync[hah 90s boy band reference] with instances that have it attached. I'm not sure that this is really a "confusing situation" because you are updating the configuration key/values. This will not update the UUID of the configuration because we are not trying to make the changes like a sub-versioned system.
'configuration' is a resource that can be applied only to instances. Making it a sub-resource of '/instances' is an option but does that warrant it always being tied to an instance? Each configuration is unique to a tenant and therefore doesnt allow a reseller to create a tweaked out config. I see value in allowing resellers to do this but currently they can update the templates that are used in the system. On Tue, Oct 1, 2013 at 9:55 PM, Michael Basnight <mbasni...@gmail.com>wrote: > 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. > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev