Is any discussion on this topic scheduled during the summit ? Thanks, Meghal
On Apr 9, 2014, at 9:03 AM, Sylvain Bauza <sylvain.ba...@gmail.com<mailto:sylvain.ba...@gmail.com>> wrote: 2014-04-07 23:11 GMT+02:00 Sylvain Bauza <sylvain.ba...@gmail.com<mailto:sylvain.ba...@gmail.com>>: Hi Phil, 2014-04-07 18:48 GMT+02:00 Day, Phil <philip....@hp.com<mailto:philip....@hp.com>>: Hi Sylvain, There was a similar thread on this recently – which might be worth reviewing: http://lists.openstack.org/pipermail/openstack-dev/2014-March/031006.html Some interesting use cases were posted, and a I don’t think a conclusion was reached, which seems to suggest this might be a good case for a session in Atlanta. The funny fact is that I was already part of this discussion as owner of a bug related to it (see the original link I provided). That's only when reviewing the code by itself that I found some discrepancies and raised the question here, before committing. Personally I’m not sure that selecting more than one AZ really makes a lot of sense – they are generally objects which are few in number and large in scale, so if for example there are 3 AZs and you want to create two servers in different AZs, does it really help if you can do the sequence: - Create a server in any AZ - Find the AZ the server is in - Create a new server in any of the two remaining AZs Rather than just picking two from the list to start with ? If you envisage a system with many AZs, and thereby allow users some pretty find grained choices about where to place their instances, then I think you’ll end up with capacity management issues. If the use case is more to get some form of server isolation, then server-groups might be worth looking at, as these are dynamic and per user. I can see a case for allowing more than one set of mutually exclusive host aggregates – at the moment that’s a property implemented just for the set of aggregates that are designated as AZs, and generalizing that concept so that there can be other sets (where host overlap is allowed between sets, but not within a set) might be useful. Phil That's a good point for discussing at the Summit. I don't have yet an opinion on this, I'm just trying to stabilize things now :-) At the moment, I'm pretty close to submit a change which will fix two things : - the decisional will be the same for both adding a server to an aggregate and update metadata from an existing aggregate (there was duplicate code leading to a few differences) - when checking existing AZs for one host, we will also get the aggregates to know if the default AZ is related to an existing aggregate with the same name or just something unrelated Folks interested in the initial issue can review https://review.openstack.org/#/c/85961/ for a proposal to fix. -Sylvain _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto: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
