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.ba...@gmail.com
<mailto:sylvain.ba...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage
questions)" <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, March 26, 2014 at 1:34 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@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.frie...@windriver.com
<mailto:chris.frie...@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@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
