Open Stack

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 <mbasnight at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131002/12c1d700/attachment.html>