> -----Message d'origine-----
> De : Sylvain Bauza [mailto:sylvain.ba...@bull.net]
> Envoyé : jeudi 27 mars 2014 11:05
> À : OpenStack Development Mailing List (not for usage questions)
> Objet : Re: [openstack-dev] [nova][scheduler] Availability Zones and Host
> aggregates..
>
> 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/a2b454c87863fbb4cf3ddaa5a5fd228
> 41339bc8f/nova/scheduler/filters/aggregate_multitenancy_isolation.py
>
> -Sylvain
Well, perhaps I didn't make it clearly enough. What I intended to say is
that user should be able to select a set of AZs in his request, something
like :
nova boot --flavor 2 --image ubuntu --availability-zone
Z1 --availability-zone AZ2 vm1
And I totally agree that the filter should keep accepting all host if no AZ
is specified in the request (as the way it does now) :)
> >>>> 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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
