Open Stack

2014-04-07 23:11 GMT+02:00 Sylvain Bauza <sylvain.bauza at gmail.com>:

> Hi Phil,
>
>
>
> 2014-04-07 18:48 GMT+02:00 Day, Phil <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/ for a proposal to fix.

-Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/1c1d61ab/attachment.html>