Open Stack

Le 27/03/2014 00:16, Sangeeta Singh a écrit :
> Hi,
>
> To update the thread the initial problem that I mentioned that when I 
> add a host to multiple availability zone(AZ) and then do a
> "nova boot" without specifying a AZ expecting the default zone to be 
> picked up.
>
> This is due to the bug [1] as mentioned by Vish. I have updated the 
> bug with the problem.
>
> The validation fails during instance create due to the [1]
>

Yup, I understood the issue, as the name of the AZ is consequently 
different from the default one.

I still need to jump on unittests and see what needs to be changed, but 
apart from that, the change by itself should be quick to do.

-Sylvain


> Thanks,
> Sangeeta
>
> [1] https://bugs.launchpad.net/nova/+bug/1277230
> From: Sylvain Bauza <sylvain.bauza at gmail.com 
> <mailto:sylvain.bauza at gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage 
> questions)" <openstack-dev at lists.openstack.org 
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Wednesday, March 26, 2014 at 1:34 PM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org 
> <mailto:openstack-dev at lists.openstack.org>>
> Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and 
> Host aggregates..
>
> I can't agree more on this. Although the name sounds identical to AWS, 
> Nova AZs are *not* for segregating compute nodes, but rather exposing 
> to users a certain sort of grouping.
> Please see this pointer for more info if needed : 
> http://russellbryantnet.wordpress.com/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/
>
> Regarding the bug mentioned by Vish [1], I'm the owner of it. I took 
> it a while ago, but things and priorities changed so I can take a look 
> over it this week and hope to deliver a patch by next week.
>
> Thanks,
> -Sylvain
>
> [1] https://bugs.launchpad.net/nova/+bug/1277230
>
>
>
>
> 2014-03-26 19:00 GMT+01:00 Chris Friesen <chris.friesen at windriver.com 
> <mailto:chris.friesen at windriver.com>>:
>
>     On 03/26/2014 11:17 AM, Khanh-Toan Tran wrote:
>
>         I don't know why you need a
>         compute node that belongs to 2 different availability-zones. Maybe
>         I'm wrong but for me it's logical that availability-zones do not
>         share the same compute nodes. The "availability-zones" have
>         the role
>         of partition your compute nodes into "zones" that are physically
>         separated (in large term it would require separation of physical
>         servers, networking equipments, power sources, etc). So that when
>         user deploys 2 VMs in 2 different zones, he knows that these
>         VMs do
>         not fall into a same host and if some zone falls, the others
>         continue
>         working, thus the client will not lose all of his VMs.
>
>
>     See Vish's email.
>
>     Even under the original meaning of availability zones you could
>     realistically have multiple orthogonal availability zones based on
>     "room", or "rack", or "network", or "dev" vs "production", or even
>     "has_ssds" and a compute node could reasonably be part of several
>     different zones because they're logically in different namespaces.
>
>     Then an end-user could boot an instance, specifying "networkA",
>     "dev", and "has_ssds" and only hosts that are part of all three
>     zones would match.
>
>     Even if they're not used for orthogonal purposes, multiple
>     availability zones might make sense.  Currently availability zones
>     are the only way an end-user has to specify anything about the
>     compute host he wants to run on.  So it's not entirely surprising
>     that people might want to overload them for purposes other than
>     physical partitioning of machines.
>
>     Chris
>
>
>     _______________________________________________
>     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/20140327/da974508/attachment.html>