Open Stack

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.bauza at gmail.com
> <mailto:sylvain.bauza at gmail.com>> wrote:
>
>>
>>
>>
>> 2014-04-07 23:11 GMT+02:00 Sylvain Bauza <sylvain.bauza at gmail.com
>> <mailto:sylvain.bauza at gmail.com>>:
>>
>>     Hi Phil,
>>
>>
>>
>>     2014-04-07 18:48 GMT+02:00 Day, Phil <philip.day at hp.com
>>     <mailto:philip.day at 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 at lists.openstack.org
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140513/6c9ed9cf/attachment.html>