Le 27/03/2014 10:37, Khanh-Toan Tran a écrit :

----- Original Message -----
From: "Sangeeta Singh" <sin...@yahoo-inc.com>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Sent: Wednesday, March 26, 2014 6:54:18 PM
Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and Host 
aggregates..



On 3/26/14, 10:17 AM, "Khanh-Toan Tran" <khanh-toan.t...@cloudwatt.com>
wrote:


----- Original Message -----
From: "Sangeeta Singh" <sin...@yahoo-inc.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Sent: Tuesday, March 25, 2014 9:50:00 PM
Subject: [openstack-dev] [nova][scheduler] Availability Zones and Host
aggregates..

Hi,

The availability Zones filter states that theoretically a compute node
can be
part of multiple availability zones. I have a requirement where I need
to
make a compute node part to 2 AZ. When I try to create a host aggregates
with AZ I can not add the node in two host aggregates that have AZ
defined.
However if I create a host aggregate without associating an AZ then I
can
add the compute nodes to it. After doing that I can update the
host-aggregate an associate an AZ. This looks like a bug.

I can see the compute node to be listed in the 2 AZ with the
availability-zone-list command.

Yes it appears a bug to me (apparently the AZ metadata indertion is
considered as a normal metadata so no check is done), and so does the
message in the AvailabilityZoneFilter. 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. It's smaller than Regions which ensure total
separation at the cost of low-layer connectivity and central management
(e.g. scheduling per region).

See: http://www.linuxjournal.com/content/introduction-openstack

The former purpose of regouping hosts with the same characteristics is
ensured by host-aggregates.

The problem that I have is that I can still not boot a VM on the
compute node
when I do not specify the AZ in the command though I have set the
default
availability zone and the default schedule zone in nova.conf.

I get the error ³ERROR: The requested availability zone is not
available²

What I am  trying to achieve is have two AZ that the user can select
during
the boot but then have a default AZ which has the HV from both AZ1 AND
AZ2
so that when the user does not specify any AZ in the boot command I
scatter
my VM on both the AZ in a balanced way.

I do not understand your goal. When you create two availability-zones and
put ALL of your compute nodes into these AZs, then if you don't specifies
the AZ in your request, then AZFilter will automatically accept all hosts.
The defaut weigher (RalWeigher) will then distribute the workload fairely
among these nodes regardless of AZ it belongs to. Maybe it is what you
want?
   With Havana that does not happen as there is a concept of
default_scheduler_zone which is none if not specified and when we specify
one can only specify a since AZ whereas in my case I basically want the 2
AZ that I create both to be considered default zones if nothing is
specified.
If you look into the code of the AvailabilityFilter, you'll see that the filter 
automatically accepts host if there is NO availability-zone in the request, 
which is the case when user does not specify AZ. This is exactly what I see in 
my Openstack platform (Hanava stable). FYI, I didn't set up a default AZ in 
config. So whenever I creates several VMs without specifying an AZ, the 
scheduler spreads the VMs into all hosts regardless of their AZ.

What I think lacking is that user can not select a set of AZs instead of one or 
none right now.

That's because this is not the goal of this filter to exclude AZs if none specified ;-)

If you want to isolate, there is another filter responsible for this [1]

IMHO, a filter should still be as simple as possible. That's only combination of filters which should match any needs.

[1] :https://github.com/openstack/nova/blob/a2b454c87863fbb4cf3ddaa5a5fd22841339bc8f/nova/scheduler/filters/aggregate_multitenancy_isolation.py

-Sylvain
Any pointers.

Thanks,
Sangeeta

_______________________________________________
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

_______________________________________________
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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to