There is a good talk happening today at 2pm @ room B.206 in a Breakout session :
"Divide and conquer: Resource Segregation in OpenStack" (I'm sorry, I can't provide the sched.org link, site seems to be down) -Sylvain Le 13/05/2014 11:12, Meghal Gosalia a écrit : > 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/ >> <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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
