2014-04-07 23:11 GMT+02:00 Sylvain Bauza <sylvain.ba...@gmail.com>: > Hi Phil, > > > > 2014-04-07 18:48 GMT+02:00 Day, Phil <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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev