Open Stack

2014-04-04 10:30 GMT+02:00 Sylvain Bauza <sylvain.bauza at gmail.com>:

> Hi all,
>
>
>
> 2014-04-03 18:47 GMT+02:00 Meghal Gosalia <meghal at yahoo-inc.com>:
>
>  Hello folks,
>>
>>  Here is the bug [1] which is currently not allowing a host to be part
>> of two availability zones.
>> This bug was targeted for havana.
>>
>>  The fix in the bug was made because it was assumed
>> that openstack does not support adding hosts to two zones by design.
>>
>>  The assumption was based on the fact that ---
>> if hostX is added to zoneA as well as zoneB,
>> and if you boot a vm vmY passing zoneB in boot params,
>> nova show vmY still returns zoneA.
>>
>>  In my opinion, we should fix the case of nova show
>> rather than changing aggregate api to not allow addition of hosts to
>> multiple zones.
>>
>>  I have added my comments in comments #7 and #9 on that bug.
>>
>>  Thanks,
>> Meghal
>>
>>
>  [1] Bug - https://bugs.launchpad.net/nova/+bug/1196893
>>
>>
>>
>
>
> Thanks for the pointer, now I see why the API is preventing host to be
> added to a 2nd aggregated if there is a different AZ. Unfortunately, this
> patch missed the fact that aggregates metadata can be modified once the
> aggregate is created, so we should add a check when updating metadate in
> order to cover all corner cases.
>
> So, IMHO, it's worth providing a patch for API consistency so as we
> enforce the fact that a host should be in only one AZ (but possibly 2 or
> more aggregates) and see how we can propose to user ability to provide 2
> distincts AZs when booting.
>
> Does everyone agree ?
>
>


Well, I'm replying to myself. The corner case is even trickier. I missed
this patch [1] which already checks that when updating an aggregate to set
an AZ, its hosts are not already part of another AZ. So, indeed, the
coverage is already there... except for one thing :

If an operator is creating an aggregate with an AZ set to the default AZ
defined in nova.conf and adds an host to this aggregate, nova
availability-zone-list does show the host being part of this default AZ
(normal behaviour). If we create an aggregate 'foo' without AZ,  then we
add the same host to that aggregate, and then we update the metadata of the
aggregate to set an AZ 'foo', then the AZ check won't notice that the host
is already part of an AZ and will allow the host to be part of two distinct
AZs.

Proof here : http://paste.openstack.org/show/75066/

I'm on that bug.
-Sylvain

[1] : https://review.openstack.org/#/c/36786

> -Sylvain
>
>
>>    On Apr 3, 2014, at 9:05 AM, Steve Gordon <sgordon at redhat.com> wrote:
>>
>> ----- Original Message -----
>>
>> Currently host aggregates are quite general, but the only ways for an
>> end-user to make use of them are:
>>
>> 1) By making the host aggregate an availability zones (where each host
>> is only supposed to be in one availability zone) and selecting it at
>> instance creation time.
>>
>> 2) By booting the instance using a flavor with appropriate metadata
>> (which can only be set up by admin).
>>
>>
>> I would like to see more flexibility available to the end-user, so I
>> think we should either:
>>
>> A) Allow hosts to be part of more than one availability zone (and allow
>> selection of multiple availability zones when booting an instance), or
>>
>>
>> While changing to allow hosts to be in multiple AZs changes the concept
>> from an operator/user point of view I do think the idea of being able to
>> specify multiple AZs when booting an instance makes sense and would be a
>> nice enhancement for users working with multi-AZ environments - "I'm OK
>> with this instance running in AZ1 and AZ2, but not AZ*".
>>
>> -Steve
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> 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/20140404/aab5f1da/attachment.html>