<div dir="ltr">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. <div>
<br></div><div>'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?</div><div>
<br></div><div>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.</div>
<div><div><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 1, 2013 at 9:55 PM, Michael Basnight <span dir="ltr"><<a href="mailto:mbasnight@gmail.com" target="_blank">mbasnight@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Oct 1, 2013, at 7:19 PM, Vipul Sabhaya wrote:<br>
><br>
> 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.<br>

<br>
</div><a href="https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.28PUT.29" target="_blank">https://wiki.openstack.org/wiki/Trove/Configurations#Update_an_Instance_.28PUT.29</a><br>
<div class="im"><br>
> Also if we change a single item in a given configuration, does that change propagate to all instances that configuration belongs to?<br>
<br>
</div>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.<br>

<br>
Blueprint designers, im looking to you for clarity.<br>
<div class="im"><br>
> What about making 'configuration' a sub-resource of /instances?<br>
><br>
> Unless we think configurations will be common amongst instances for a given tenant, it may not make sense to make them high level resources.<br>
<br>
</div>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.<br>

<br>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div></div>