Open Stack

> -----Original Message-----
> From: Chris Friesen [mailto:chris.friesen at windriver.com]
> Sent: 27 March 2014 18:15
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and Host
> aggregates..
> 
> On 03/27/2014 11:48 AM, Day, Phil wrote:
> > Sorry if I'm coming late to this thread, but why would you define AZs
> > to cover "othognal zones" ?
> 
> See Vish's first message.
> 
> > AZs are a very specific form of aggregate - they provide a particular
> > isolation schematic between the hosts (i.e. physical hosts are never
> > in more than one AZ) - hence the "availability" in the name.
> 
> That's why I specified orthogonal.  If you're looking at different resources
> then it makes sense to have one host be in different AZs because the AZs are
> essentially in different namespaces.
> 
> So you could have "hosts in server room A" vs "hosts in server room B".
>   Or "hosts on network switch A" vs "hosts on network switch B".  Or "hosts
> with SSDs" vs "hosts with disks".  Then you could specify you want to boot an
> instance in server room A, on switch B, on a host with SSDs.
> 
> > AZs are built on aggregates, and yes aggregates can overlap and
> > aggreagtes are used for scheduling.
> >
> > So if you want to schedule on features as well as (or instead of)
> > physical isolation, then you can already:
> >
> > - Create an aggregate that contains "hosts with fast CPUs" - Create
> > another aggregate that includes "hosts with SSDs" - Write (or
> > configure in some cases) schedule filters that look at something in
> > the request (such as schedule hint, an image property, or a flavor
> > extra_spec) so that the scheduler can filter on those aggregates
> >
> > nova boot --availability-zone az1 --scheduler-hint want-fast-cpu
> > --scheduler-hint want-ssd  ...
> 
> Does this actually work?  The docs only describe setting the metadata on the
> flavor, not as part of the boot command.
> 
If you want to be able to pass it in as explicit hints then you need to write a filter to cope with that hint- I was using it as an example of the kind of relationship between hints and aggregate filtering 
The more realistic example for this kind of attribute is to make it part of the flavor and use the aggregate_instance_extra_spec filter - which does exactly this kind of filtering (for overlapping aggregates)


> > nova boot --availability-zone az1 --flavor 1000 (where flavor 1000 has
> > extra spec that says it needs fast cpu and ssd)
> >
> > But there is no need that I can see to make AZs overlapping just to so
> > the same thing - that would break what everyone (including folks used
> > to working with AWS) expects from an AZ
> 
> 
> As an admin user you can create arbitrary host aggregates, assign metadata,
> and have flavors with extra specs to look for that metadata.
> 
> But as far as I know there is no way to match host aggregate information on a
> per-instance basis.

Matching aggregate information on a per-instance basis is what the scheduler filters do.

Well yes  it is down to the admin to decide what groups are going to be available, how to map them into aggregates, how to map that into flavors (which are often the link to a charging mechanism) - but once they've done that then the user can work within those bounds by choosing the correct flavor, image, etc.    
> 
> Also, unless things have changed since I looked at it last as a regular user you
> can't create new flavors so the only way to associate an instance with a host
> aggregate is via an availability zone.

Well it depends on the roles you want to assign to your users really and how you set up your policy file, but in general you don't want users defining flavors, the cloud admin defines the flavors based on what makes sense from their environment.

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