Open Stack

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131001/efec59eb/attachment.pgp>