Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On 03/28/2014 05:01 AM, Jesse Pretorius wrote: On 27 March 2014 20:52, Chris Friesen mailto:chris.frie...@windriver.com>> wrote: It'd be nice to be able to do a heat template where you could specify things like "put these three servers on separate hosts from each other, and these other two servers on separate hosts from each other (but maybe on the same hosts as the first set of servers), and they all have to be on the same network segment because they talk to each other a lot and I want to minimize latency, and they all need access to the same shared instance storage for live migration". Surely this can be achieved with: 1) Configure compute hosts with shared storage and on the same switch infrastructure in a host aggregate, with an AZ set in the aggregate (setting the AZ gives visibility to the end-user) 2) Ensure that both the GroupAntiAffinityFilter and AvailabilityZoneFilter are setup on the scheduler 3) Boot the instances using the availability zone and group scheduler hints Last I checked, heat doesn't support creating server groups. Is it possible to use GroupAntiAffinityFilter without server groups? I'm thinking of a setup where you may have multiple shared storage zones, such that not all compute nodes have access to the same storage (for performance reasons). Similarly, in a large environment it's possible that compute nodes don't all have access to the same network. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On Fri, 2014-03-28 at 19:38 +, CARVER, PAUL wrote: > Jay Pipes wrote: > >I'm proposing getting rid of the host aggregate hack (or maybe evolving > >it?) as well as the availability zone concept and replacing them with a > >more flexible generic container object that may be hierarchical in > >nature. > > Is the thing you're proposing to replace them with something that already > exists or a brand new thing you're proposing should be created? Either an evolution of the host aggregate concept (possibly renamed) or a brand new concept. > We need some sort of construct that allows the tenant to be confident that > they aren't going to lose multiple VMs simultaneously due to a failure of > underlying hardware. ? Tenants currently assume this is the case if they are using multiple availability zones, but there is nothing in Nova that actually prevents multiple availability zones from sharing hardware. Frankly, this is an SLA thing, and should not be part of the API, IMO. If a deployer wishes to advertise an SLA that says "this container of compute resources is a failure domain", then they should be free to make that SLA and even include it in a description of said generic container of compute resource, but there should be no *implicit* SLAs. > The semantics of it need to be easily comprehensible > to the tenant, otherwise you'll get people thinking they're protected because > they built a redundant pair of VMs but sheer bad luck results in them losing > them both at the same time. Umm, that's possible today. There is an implicit trust right now in the API that availability zones are independent failure domains. And what I am telling you is that no such constraint exists in the implementation of Nova availability zones (exposed via host aggregate). > We're using availability zone for that currently and it seems to serve the > purpose in a way that's easy to explain to a tenant. It may be easy to explain to a tenant -- simply because of its use in AWS. But that doesn't mean it's something that is real in practice. You're furthering a false trust if you explain to tenants that an availability zone is an independent failure domain when it can easily NOT be an independent failure domain because of the exposure of availability zones through the host aggregate concept (which themselves may overlap hardware and therefore spoil the promise of independent failure domains). Thus, we need a different concept than availability zone to expose to users. Thus, my proposal. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
Jay Pipes wrote: >I'm proposing getting rid of the host aggregate hack (or maybe evolving >it?) as well as the availability zone concept and replacing them with a >more flexible generic container object that may be hierarchical in >nature. Is the thing you're proposing to replace them with something that already exists or a brand new thing you're proposing should be created? We need some sort of construct that allows the tenant to be confident that they aren't going to lose multiple VMs simultaneously due to a failure of underlying hardware. The semantics of it need to be easily comprehensible to the tenant, otherwise you'll get people thinking they're protected because they built a redundant pair of VMs but sheer bad luck results in them losing them both at the same time. We're using availability zone for that currently and it seems to serve the purpose in a way that's easy to explain to a tenant. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On Fri, 2014-03-28 at 11:01 +, Day, Phil wrote: > >> Personally, I feel it is a mistake to continue to use the Amazon concept > >> of an availability zone in OpenStack, as it brings with it the > >> connotation from AWS EC2 that each zone is an independent failure > >> domain. This characteristic of EC2 availability zones is not enforced in > >> OpenStack Nova or Cinder, and therefore creates a false expectation for > >> Nova users. > > >I think this is backwards training, personally. I think azs as separate > >failure > >domains were done like that for a reason by amazon, and make good sense. > >What we've done is overload that with cells, aggregates etc which should > >have a better interface and are a different concept. Redefining well > >understood > >terms because they don't suite your current implementation is a slippery > >slope, > >and overloading terms that already have a meaning in the industry in just > >annoying. > > +1 > I don't think there is anything wrong with identifying new use cases and > working out how to cope with them: > > - First we generalized Aggregates > - Then we mapped AZs onto aggregates as a special mutually exclusive group > - Now we're recognizing that maybe we need to make those changes to support > AZs more generic so we can create additional groups of mutually exclusive > aggregates > > That all feels like good evolution. I see your point, though I'm not sure it was all that good. > But I don't see why that means we have to fit that in under the existing > concept of AZs - why can't we keep AZs as they are and have a better thing > called Zones that is just an OSAPI concept and is better that AZs ? Phil, that is exactly what I am proposing. For the next major version of the Nova API, introducing a new generic container of compute resources. > Arguments around not wanting to add new options to create server seem a bit > weak to me Who has made that argument? > - for sure we don't want to add them in an uncontrolled way, but if we have a > new, richer, concept we should be able to express that separately. Which is what I've proposed, no? > I'm still not personally convinced by the need use cases of racks having > orthogonal power failure domains and switch failure domains - that seems to > me from a practical perspective that it becomes really hard to work out where > to separate VMs so that they don't share a failure mode.Every physical DC > design I've been involved with tries to get the different failure domains to > align. However if it the use case makes sense to someone then I'm not > against extending aggregates to support multiple mutually exclusive groups. My point is that if we had a concept of a generic container of compute resources, then whether or not that container was an independent failure domain or not would simply be an explicit trait of the container. As it stands now with availability zones, being an independent failure domain is an *implied* trait that isn't enforced by Nova, Neutron or Cinder. Best, -jay > > Phil > > > ___ > 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On Fri, 2014-03-28 at 13:56 +0100, Belmiro Moreira wrote: > +1 for Phil comments. > I agree that VMs should spread between different default avzs if user > doesn't define one at boot time. > There is a blueprint for that feature that unfortunately didn't make > it for icehouse. > https://blueprints.launchpad.net/nova/+spec/schedule-set-availability-zones That's not at all what I've been talking about. I'm talking about the concept of EC2 availability zones being improperly applied in Nova and leading to wrong expectations of the user. Thus, I am proposing to drop the concept of EC2 AZs in the next major API version and instead have a general compute node container that may or may not contain other generic containers of compute nodes. The HostAggregate concept in Nova was a hack to begin with (it was originally just XenServer-specific), and then was further hacked to allow tagging a host aggregate with an AZ -- ostensibly to expose something to the end user that could be used to direct scheduler hints. I'm proposing getting rid of the host aggregate hack (or maybe evolving it?) as well as the availability zone concept and replacing them with a more flexible generic container object that may be hierarchical in nature. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
+1 for Phil comments. I agree that VMs should spread between different default avzs if user doesn't define one at boot time. There is a blueprint for that feature that unfortunately didn't make it for icehouse. https://blueprints.launchpad.net/nova/+spec/schedule-set-availability-zones Belmiro On Fri, Mar 28, 2014 at 12:01 PM, Day, Phil wrote: > >> Personally, I feel it is a mistake to continue to use the Amazon concept > >> of an availability zone in OpenStack, as it brings with it the > >> connotation from AWS EC2 that each zone is an independent failure > >> domain. This characteristic of EC2 availability zones is not enforced in > >> OpenStack Nova or Cinder, and therefore creates a false expectation for > >> Nova users. > > >I think this is backwards training, personally. I think azs as separate > failure > >domains were done like that for a reason by amazon, and make good sense. > >What we've done is overload that with cells, aggregates etc which should > >have a better interface and are a different concept. Redefining well > understood > >terms because they don't suite your current implementation is a slippery > slope, > >and overloading terms that already have a meaning in the industry in just > annoying. > > +1 > I don't think there is anything wrong with identifying new use cases and > working out how to cope with them: > > - First we generalized Aggregates > - Then we mapped AZs onto aggregates as a special mutually exclusive group > - Now we're recognizing that maybe we need to make those changes to > support AZs more generic so we can create additional groups of mutually > exclusive aggregates > > That all feels like good evolution. > > But I don't see why that means we have to fit that in under the existing > concept of AZs - why can't we keep AZs as they are and have a better thing > called Zones that is just an OSAPI concept and is better that AZs ? > Arguments around not wanting to add new options to create server seem a > bit weak to me - for sure we don't want to add them in an uncontrolled way, > but if we have a new, richer, concept we should be able to express that > separately. > > I'm still not personally convinced by the need use cases of racks having > orthogonal power failure domains and switch failure domains - that seems to > me from a practical perspective that it becomes really hard to work out > where to separate VMs so that they don't share a failure mode.Every > physical DC design I've been involved with tries to get the different > failure domains to align. However if it the use case makes sense to > someone then I'm not against extending aggregates to support multiple > mutually exclusive groups. > > I think I see a Design Summit session emerging here > > Phil > > > ___ > 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On 27 March 2014 20:52, Chris Friesen wrote: > It'd be nice to be able to do a heat template where you could specify > things like "put these three servers on separate hosts from each other, and > these other two servers on separate hosts from each other (but maybe on the > same hosts as the first set of servers), and they all have to be on the > same network segment because they talk to each other a lot and I want to > minimize latency, and they all need access to the same shared instance > storage for live migration". > Surely this can be achieved with: 1) Configure compute hosts with shared storage and on the same switch infrastructure in a host aggregate, with an AZ set in the aggregate (setting the AZ gives visibility to the end-user) 2) Ensure that both the GroupAntiAffinityFilter and AvailabilityZoneFilter are setup on the scheduler 3) Boot the instances using the availability zone and group scheduler hints ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
>> Personally, I feel it is a mistake to continue to use the Amazon concept >> of an availability zone in OpenStack, as it brings with it the >> connotation from AWS EC2 that each zone is an independent failure >> domain. This characteristic of EC2 availability zones is not enforced in >> OpenStack Nova or Cinder, and therefore creates a false expectation for >> Nova users. >I think this is backwards training, personally. I think azs as separate failure >domains were done like that for a reason by amazon, and make good sense. >What we've done is overload that with cells, aggregates etc which should >have a better interface and are a different concept. Redefining well >understood >terms because they don't suite your current implementation is a slippery >slope, >and overloading terms that already have a meaning in the industry in just >annoying. +1 I don't think there is anything wrong with identifying new use cases and working out how to cope with them: - First we generalized Aggregates - Then we mapped AZs onto aggregates as a special mutually exclusive group - Now we're recognizing that maybe we need to make those changes to support AZs more generic so we can create additional groups of mutually exclusive aggregates That all feels like good evolution. But I don't see why that means we have to fit that in under the existing concept of AZs - why can't we keep AZs as they are and have a better thing called Zones that is just an OSAPI concept and is better that AZs ? Arguments around not wanting to add new options to create server seem a bit weak to me - for sure we don't want to add them in an uncontrolled way, but if we have a new, richer, concept we should be able to express that separately. I'm still not personally convinced by the need use cases of racks having orthogonal power failure domains and switch failure domains - that seems to me from a practical perspective that it becomes really hard to work out where to separate VMs so that they don't share a failure mode.Every physical DC design I've been involved with tries to get the different failure domains to align. However if it the use case makes sense to someone then I'm not against extending aggregates to support multiple mutually exclusive groups. I think I see a Design Summit session emerging here Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On Mar 26, 2014 6:46 PM, "Jay Pipes" wrote: > Personally, I feel it is a mistake to continue to use the Amazon concept > of an availability zone in OpenStack, as it brings with it the > connotation from AWS EC2 that each zone is an independent failure > domain. This characteristic of EC2 availability zones is not enforced in > OpenStack Nova or Cinder, and therefore creates a false expectation for > Nova users. I think this is backwards training, personally. I think azs as separate failure domains were done like that for a reason by amazon, and make good sense. What we've done is overload that with cells, aggregates etc which should have a better interface and are a different concept. Redefining well understood terms because they don't suite your current implementation is a slippery slope, and overloading terms that already have a meaning in the industry in just annoying. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On 03/27/2014 12:49 PM, Day, Phil wrote: -Original Message- From: Chris Friesen [mailto:chris.frie...@windriver.com] On 03/27/2014 11:48 AM, Day, Phil wrote: 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) I'll admit that I don't have a lot of experience as an end-user of OpenStack, so maybe that colours my judgement. To me it seems quite limiting that if you want the scheduler to match against multiple host aggregate extra specs then you need to create a new flavor. If a regular user could do something like what you specify in your example, I think that would make a lot of sense. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On 3/27/14, 11:03 AM, "Day, Phil" wrote: >> >> The need arises when you need a way to use both the zones to be >>used for >> scheduling when no specific zone is specified. The only way to do that >>is >> either have a AZ which is a superset of the two AZ or the other way >>could be >> if the default_scheduler_zone can take a list of zones instead of just >>1. > >If you don't configure a default_schedule_zone, and don't specify an >availability_zone to the request - then I thought that would make the AZ >filter in effect ignore AZs for that request. Isn't that want you need ? No what I want is a default_schedule_zone that uses hosts from two other AZs but in my deployment I might have other AZs defined as well which I want to be filtered out when the boot command does not specify a AZ. 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On 03/27/2014 12:28 PM, Day, Phil wrote: Personally I'm a bit worried about users having too fine a granularity over where they place a sever - AZs are generally few and big so you can afford to allow this and not have capacity issues, but if I had to expose 40 different rack based zones it would be pretty hard to stop everyone pilling into the first or last - when really want they want to say is "not the same as" or "the same as" - which makes me wonder if this is really the right way to go.It feels more like what we really want is some form of affinity and anti-affinity rules rather than an explicit choice of a particular group. I suspect in many cases server groups with affinity rules would go a long way, but currently the server group policies only select based on compute node. It'd be nice to be able to do a heat template where you could specify things like "put these three servers on separate hosts from each other, and these other two servers on separate hosts from each other (but maybe on the same hosts as the first set of servers), and they all have to be on the same network segment because they talk to each other a lot and I want to minimize latency, and they all need access to the same shared instance storage for live migration". Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
> -Original Message- > From: Chris Friesen [mailto:chris.frie...@windriver.com] > Sent: 27 March 2014 18:15 > To: openstack-dev@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@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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
> -Original Message- > From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] > Sent: 26 March 2014 20:33 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and Host > aggregates.. > > > On Mar 26, 2014, at 11:40 AM, Jay Pipes wrote: > > > On Wed, 2014-03-26 at 09:47 -0700, Vishvananda Ishaya wrote: > >> Personally I view this as a bug. There is no reason why we shouldn't > >> support arbitrary grouping of zones. I know there is at least one > >> problem with zones that overlap regarding displaying them properly: > >> > >> https://bugs.launchpad.net/nova/+bug/1277230 > >> > >> There is probably a related issue that is causing the error you see > >> below. IMO both of these should be fixed. I also think adding a > >> compute node to two different aggregates with azs should be allowed. > >> > >> It also might be nice to support specifying multiple zones in the > >> launch command in these models. This would allow you to limit booting > >> to an intersection of two overlapping zones. > >> > >> A few examples where these ideas would be useful: > >> > >> 1. You have 3 racks of servers and half of the nodes from each rack > >> plugged into a different switch. You want to be able to specify to > >> spread across racks or switches via an AZ. In this model you could > >> have a zone for each switch and a zone for each rack. > >> > >> 2. A single cloud has 5 racks in one room in the datacenter and 5 > >> racks in a second room. You'd like to give control to the user to > >> choose the room or choose the rack. In this model you would have one > >> zone for each room, and smaller zones for each rack. > >> > >> 3. You have a small 3 rack cloud and would like to ensure that your > >> production workloads don't run on the same machines as your dev > >> workloads, but you also want to use zones spread workloads across the > >> three racks. Similarly to 1., you could split your racks in half via > >> dev and prod zones. Each one of these zones would overlap with a rack > >> zone. > >> > >> You can achieve similar results in these situations by making small > >> zones (switch1-rack1 switch1-rack2 switch1-rack3 switch2-rack1 > >> switch2-rack2 switch2-rack3) but that removes the ability to decide > >> to launch something with less granularity. I.e. you can't just > >> specify 'switch1' or 'rack1' or 'anywhere' > >> > >> I'd like to see all of the following work nova boot ... (boot anywhere) > >> nova boot -availability-zone switch1 ... (boot it switch1 zone) nova > >> boot -availability-zone rack1 ... (boot in rack1 zone) nova boot > >> -availability-zone switch1,rack1 ... (boot > > > > Personally, I feel it is a mistake to continue to use the Amazon > > concept of an availability zone in OpenStack, as it brings with it the > > connotation from AWS EC2 that each zone is an independent failure > > domain. This characteristic of EC2 availability zones is not enforced > > in OpenStack Nova or Cinder, and therefore creates a false expectation > > for Nova users. > > > > In addition to the above problem with incongruent expectations, the > > other problem with Nova's use of the EC2 availability zone concept is > > that availability zones are not hierarchical -- due to the fact that > > EC2 AZs are independent failure domains. Not having the possibility of > > structuring AZs hierarchically limits the ways in which Nova may be > > deployed -- just see the cells API for the manifestation of this > > problem. > > > > I would love it if the next version of the Nova and Cinder APIs would > > drop the concept of an EC2 availability zone and introduce the concept > > of a generic region structure that can be infinitely hierarchical in > > nature. This would enable all of Vish's nova boot commands above in an > > even simpler fashion. For example: > > > > Assume a simple region hierarchy like so: > > > > regionA > > / \ > > regionBregionC > > > > # User wants to boot in region B > > nova boot --region regionB > > # User wants to boot in either region B or region C nova boot --region > > regionA > > I think the overlapping zones allows for this and also enables additional use > cases as mentioned in my earlier email. Hie
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. 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. 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. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
> > The need arises when you need a way to use both the zones to be used for > scheduling when no specific zone is specified. The only way to do that is > either have a AZ which is a superset of the two AZ or the other way could be > if the default_scheduler_zone can take a list of zones instead of just 1. If you don't configure a default_schedule_zone, and don't specify an availability_zone to the request - then I thought that would make the AZ filter in effect ignore AZs for that request. Isn't that want you need ? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
Sorry if I'm coming late to this thread, but why would you define AZs to cover "othognal zones" ? 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. 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 ... 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 > -Original Message- > From: Chris Friesen [mailto:chris.frie...@windriver.com] > Sent: 27 March 2014 13:18 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and Host > aggregates.. > > On 03/27/2014 05:03 AM, Khanh-Toan Tran wrote: > > > 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 > > I think it would make more sense to make the availability-zone argument > take a comma-separated list of zones. > > nova boot --flavor 2 --image ubuntu --availability-zone AZ1,AZ2 vm1 > > > Just to clarify, in a case like this we're talking about using the > intersection of > the two zones, right? That's the only way that makes sense when using > orthogonal zones like "hosts with fast CPUs" and "hosts with SSDs". > > Chris > > ___ > 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On 03/27/2014 05:03 AM, Khanh-Toan Tran wrote: 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 I think it would make more sense to make the availability-zone argument take a comma-separated list of zones. nova boot --flavor 2 --image ubuntu --availability-zone AZ1,AZ2 vm1 Just to clarify, in a case like this we're talking about using the intersection of the two zones, right? That's the only way that makes sense when using orthogonal zones like "hosts with fast CPUs" and "hosts with SSDs". Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
> -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" > >> To: "OpenStack Development Mailing List (not for usage questions)" > >> > >> 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" > >> > >> wrote: > >> > >>> > >>> ----- Original Message ----- > >>>> From: "Sangeeta Singh" > >>>> To: "OpenStack Development Mailing List (not for usage questions)" > >>>> > >>>> 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
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" To: "OpenStack Development Mailing List (not for usage questions)" 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" wrote: - Original Message - From: "Sangeeta Singh" To: "OpenStack Development Mailing List (not for usage questions)" 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/
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
No, what I mean is that user should be able to specify multiple AZs in his request, something like: nova boot --flavor 2 --image ubuntu --availability-zone AZ1 --availability-zone AZ2 vm1 De : Jérôme Gallard [mailto:gallard.jer...@gmail.com] Envoyé : jeudi 27 mars 2014 10:51 À : OpenStack Development Mailing List (not for usage questions) Objet : Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates.. Hi Toan, Is what you say related to : https://blueprints.launchpad.net/nova/+spec/schedule-set-availability-zone s ? 2014-03-27 10:37 GMT+01:00 Khanh-Toan Tran : - Original Message - > From: "Sangeeta Singh" > To: "OpenStack Development Mailing List (not for usage questions)" > 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" > wrote: > > > > > > >- Original Message - > >> From: "Sangeeta Singh" > >> To: "OpenStack Development Mailing List (not for usage questions)" > >> > >> 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
Hi Toan, Is what you say related to : https://blueprints.launchpad.net/nova/+spec/schedule-set-availability-zones? 2014-03-27 10:37 GMT+01:00 Khanh-Toan Tran : > > > - Original Message - > > From: "Sangeeta Singh" > > 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" > > wrote: > > > > > > > > > > >- Original Message - > > >> From: "Sangeeta Singh" > > >> To: "OpenStack Development Mailing List (not for usage questions)" > > >> > > >> 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 whe
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
- Original Message - > From: "Sangeeta Singh" > To: "OpenStack Development Mailing List (not for usage questions)" > > 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" > wrote: > > > > > > >- Original Message - > >> From: "Sangeeta Singh" > >> To: "OpenStack Development Mailing List (not for usage questions)" > >> > >> 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 t
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
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 <mailto:sylvain.ba...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, March 26, 2014 at 1:34 PM To: "OpenStack Development Mailing List (not for usage questions)" <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 <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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On Thu, 2014-03-27 at 01:10 +, Joshua Harlow wrote: > Region graphs? > > Sounds like what u are describing sounds like a graph > (non-hierarchical) which has nodes that have defined attributes on > them. > > A region then would just be a set of connected nodes (which could be > connected via a parent<->child edge for example). > > Each node can also have attributes (allowing regions to also be > selected by common attributes). Seems like that might fit what is > wanted? Precisely. -jay > > From: Jay Pipes > Reply-To: "OpenStack Development Mailing List (not for usage > questions)" > Date: Wednesday, March 26, 2014 at 4:45 PM > To: "openstack-dev@lists.openstack.org" > > Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and > Host aggregates.. > > > > On Wed, 2014-03-26 at 13:33 -0700, Vishvananda Ishaya wrote: > On Mar 26, 2014, at 11:40 AM, Jay Pipes > wrote: > > > On Wed, 2014-03-26 at 09:47 -0700, Vishvananda > Ishaya wrote: > >> Personally I view this as a bug. There is no reason > why we shouldn’t > >> support arbitrary grouping of zones. I know there > is at least one > >> problem with zones that overlap regarding > displaying them properly: > >> > >> https://bugs.launchpad.net/nova/+bug/1277230 > >> > >> There is probably a related issue that is causing > the error you see > >> below. IMO both of these should be fixed. I also > think adding a > >> compute node to two different aggregates with azs > should be allowed. > >> > >> It also might be nice to support specifying > multiple zones in the > >> launch command in these models. This would allow > you to limit booting > >> to an intersection of two overlapping zones. > >> > >> A few examples where these ideas would be useful: > >> > >> 1. You have 3 racks of servers and half of the > nodes from each rack > >> plugged into a different switch. You want to be > able to specify to > >> spread across racks or switches via an AZ. In this > model you could > >> have a zone for each switch and a zone for each > rack. > >> > >> 2. A single cloud has 5 racks in one room in the > datacenter and 5 > >> racks in a second room. You’d like to give control > to the user to > >> choose the room or choose the rack. In this model > you would have one > >> zone for each room, and smaller zones for each > rack. > >> > >> 3. You have a small 3 rack cloud and would like to > ensure that your > >> production workloads don’t run on the same machines > as your dev > >> workloads, but you also want to use zones spread > workloads across the > >> three racks. Similarly to 1., you could split your > racks in half via > >> dev and prod zones. Each one of these zones would > overlap with a rack > >> zone. > >> > >> You can achieve similar results in these situations > by making small > >> zones (switch1-rack1 switch1-rack2 switch1-rack3 > switch2-rack1 > >> switch2-rack2 switch2-rack3) but that removes the > ability to decide to > >> launch something with less granularity. I.e. you > can’t just specify > >> ‘switch1' or ‘rack1' or ‘anywhere’ > >> > >> I’d like to see all of the following work > >> nova boot … (boot anywhere) > >> nova boot —availability-zone switch1 … (boot it > switch1 zone) >
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
Region graphs? Sounds like what u are describing sounds like a graph (non-hierarchical) which has nodes that have defined attributes on them. A region then would just be a set of connected nodes (which could be connected via a parent<->child edge for example). Each node can also have attributes (allowing regions to also be selected by common attributes). Seems like that might fit what is wanted? From: Jay Pipes mailto:jaypi...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, March 26, 2014 at 4:45 PM To: "openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates.. On Wed, 2014-03-26 at 13:33 -0700, Vishvananda Ishaya wrote: On Mar 26, 2014, at 11:40 AM, Jay Pipes mailto:jaypi...@gmail.com>> wrote: > On Wed, 2014-03-26 at 09:47 -0700, Vishvananda Ishaya wrote: >> Personally I view this as a bug. There is no reason why we shouldn’t >> support arbitrary grouping of zones. I know there is at least one >> problem with zones that overlap regarding displaying them properly: >> >> https://bugs.launchpad.net/nova/+bug/1277230 >> >> There is probably a related issue that is causing the error you see >> below. IMO both of these should be fixed. I also think adding a >> compute node to two different aggregates with azs should be allowed. >> >> It also might be nice to support specifying multiple zones in the >> launch command in these models. This would allow you to limit booting >> to an intersection of two overlapping zones. >> >> A few examples where these ideas would be useful: >> >> 1. You have 3 racks of servers and half of the nodes from each rack >> plugged into a different switch. You want to be able to specify to >> spread across racks or switches via an AZ. In this model you could >> have a zone for each switch and a zone for each rack. >> >> 2. A single cloud has 5 racks in one room in the datacenter and 5 >> racks in a second room. You’d like to give control to the user to >> choose the room or choose the rack. In this model you would have one >> zone for each room, and smaller zones for each rack. >> >> 3. You have a small 3 rack cloud and would like to ensure that your >> production workloads don’t run on the same machines as your dev >> workloads, but you also want to use zones spread workloads across the >> three racks. Similarly to 1., you could split your racks in half via >> dev and prod zones. Each one of these zones would overlap with a rack >> zone. >> >> You can achieve similar results in these situations by making small >> zones (switch1-rack1 switch1-rack2 switch1-rack3 switch2-rack1 >> switch2-rack2 switch2-rack3) but that removes the ability to decide to >> launch something with less granularity. I.e. you can’t just specify >> ‘switch1' or ‘rack1' or ‘anywhere’ >> >> I’d like to see all of the following work >> nova boot … (boot anywhere) >> nova boot —availability-zone switch1 … (boot it switch1 zone) >> nova boot —availability-zone rack1 … (boot in rack1 zone) >> nova boot —availability-zone switch1,rack1 … (boot > > Personally, I feel it is a mistake to continue to use the Amazon concept > of an availability zone in OpenStack, as it brings with it the > connotation from AWS EC2 that each zone is an independent failure > domain. This characteristic of EC2 availability zones is not enforced in > OpenStack Nova or Cinder, and therefore creates a false expectation for > Nova users. > > In addition to the above problem with incongruent expectations, the > other problem with Nova's use of the EC2 availability zone concept is > that availability zones are not hierarchical -- due to the fact that EC2 > AZs are independent failure domains. Not having the possibility of > structuring AZs hierarchically limits the ways in which Nova may be > deployed -- just see the cells API for the manifestation of this > problem. > > I would love it if the next version of the Nova and Cinder APIs would > drop the concept of an EC2 availability zone and introduce the concept > of a generic region structure that can be infinitely hierarchical in > nature. This would enable all of Vish's nova boot commands above in an > even simpler fashion. For example: > > Assume a simple region hierarchy like so: > > regionA > / \ > regionBregionC > > # User wants to boot in region B > nova boot --region
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On Wed, 2014-03-26 at 13:33 -0700, Vishvananda Ishaya wrote: > On Mar 26, 2014, at 11:40 AM, Jay Pipes wrote: > > > On Wed, 2014-03-26 at 09:47 -0700, Vishvananda Ishaya wrote: > >> Personally I view this as a bug. There is no reason why we shouldn’t > >> support arbitrary grouping of zones. I know there is at least one > >> problem with zones that overlap regarding displaying them properly: > >> > >> https://bugs.launchpad.net/nova/+bug/1277230 > >> > >> There is probably a related issue that is causing the error you see > >> below. IMO both of these should be fixed. I also think adding a > >> compute node to two different aggregates with azs should be allowed. > >> > >> It also might be nice to support specifying multiple zones in the > >> launch command in these models. This would allow you to limit booting > >> to an intersection of two overlapping zones. > >> > >> A few examples where these ideas would be useful: > >> > >> 1. You have 3 racks of servers and half of the nodes from each rack > >> plugged into a different switch. You want to be able to specify to > >> spread across racks or switches via an AZ. In this model you could > >> have a zone for each switch and a zone for each rack. > >> > >> 2. A single cloud has 5 racks in one room in the datacenter and 5 > >> racks in a second room. You’d like to give control to the user to > >> choose the room or choose the rack. In this model you would have one > >> zone for each room, and smaller zones for each rack. > >> > >> 3. You have a small 3 rack cloud and would like to ensure that your > >> production workloads don’t run on the same machines as your dev > >> workloads, but you also want to use zones spread workloads across the > >> three racks. Similarly to 1., you could split your racks in half via > >> dev and prod zones. Each one of these zones would overlap with a rack > >> zone. > >> > >> You can achieve similar results in these situations by making small > >> zones (switch1-rack1 switch1-rack2 switch1-rack3 switch2-rack1 > >> switch2-rack2 switch2-rack3) but that removes the ability to decide to > >> launch something with less granularity. I.e. you can’t just specify > >> ‘switch1' or ‘rack1' or ‘anywhere’ > >> > >> I’d like to see all of the following work > >> nova boot … (boot anywhere) > >> nova boot —availability-zone switch1 … (boot it switch1 zone) > >> nova boot —availability-zone rack1 … (boot in rack1 zone) > >> nova boot —availability-zone switch1,rack1 … (boot > > > > Personally, I feel it is a mistake to continue to use the Amazon concept > > of an availability zone in OpenStack, as it brings with it the > > connotation from AWS EC2 that each zone is an independent failure > > domain. This characteristic of EC2 availability zones is not enforced in > > OpenStack Nova or Cinder, and therefore creates a false expectation for > > Nova users. > > > > In addition to the above problem with incongruent expectations, the > > other problem with Nova's use of the EC2 availability zone concept is > > that availability zones are not hierarchical -- due to the fact that EC2 > > AZs are independent failure domains. Not having the possibility of > > structuring AZs hierarchically limits the ways in which Nova may be > > deployed -- just see the cells API for the manifestation of this > > problem. > > > > I would love it if the next version of the Nova and Cinder APIs would > > drop the concept of an EC2 availability zone and introduce the concept > > of a generic region structure that can be infinitely hierarchical in > > nature. This would enable all of Vish's nova boot commands above in an > > even simpler fashion. For example: > > > > Assume a simple region hierarchy like so: > > > > regionA > > / \ > > regionBregionC > > > > # User wants to boot in region B > > nova boot --region regionB > > # User wants to boot in either region B or region C > > nova boot --region regionA > > I think the overlapping zones allows for this and also enables additional use > cases as mentioned in my earlier email. You are assuming that the region hierarchy I was describing had only a single root region. I didn't say that. I envision multiple root regions, which would enable compute nodes to reside in multiple regions. > Hierarchical doesn’t work for the > rack/switch model. Sure it does. Just not a single root hierarchy. > I’m definitely +1 on breaking from the amazon usage > of availability zones but I’m a bit leery to add another parameter to > the create request. It wouldn't add another *required* parameter to the create request. The region would default to whatever region the keystone endpoint that returned the service catalog for the novaclient had as its default region. > It is also unfortunate that region already has a meaning > in the amazon world which will add confusion. OK. We could call it something else... though IIRC, trying to come up with a name for this kind of thing is, we
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
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] Thanks, Sangeeta [1] https://bugs.launchpad.net/nova/+bug/1277230 From: Sylvain Bauza mailto:sylvain.ba...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, March 26, 2014 at 1:34 PM To: "OpenStack Development Mailing List (not for usage questions)" 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 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
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 : > 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 > 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On Mar 26, 2014, at 11:40 AM, Jay Pipes wrote: > On Wed, 2014-03-26 at 09:47 -0700, Vishvananda Ishaya wrote: >> Personally I view this as a bug. There is no reason why we shouldn’t >> support arbitrary grouping of zones. I know there is at least one >> problem with zones that overlap regarding displaying them properly: >> >> https://bugs.launchpad.net/nova/+bug/1277230 >> >> There is probably a related issue that is causing the error you see >> below. IMO both of these should be fixed. I also think adding a >> compute node to two different aggregates with azs should be allowed. >> >> It also might be nice to support specifying multiple zones in the >> launch command in these models. This would allow you to limit booting >> to an intersection of two overlapping zones. >> >> A few examples where these ideas would be useful: >> >> 1. You have 3 racks of servers and half of the nodes from each rack >> plugged into a different switch. You want to be able to specify to >> spread across racks or switches via an AZ. In this model you could >> have a zone for each switch and a zone for each rack. >> >> 2. A single cloud has 5 racks in one room in the datacenter and 5 >> racks in a second room. You’d like to give control to the user to >> choose the room or choose the rack. In this model you would have one >> zone for each room, and smaller zones for each rack. >> >> 3. You have a small 3 rack cloud and would like to ensure that your >> production workloads don’t run on the same machines as your dev >> workloads, but you also want to use zones spread workloads across the >> three racks. Similarly to 1., you could split your racks in half via >> dev and prod zones. Each one of these zones would overlap with a rack >> zone. >> >> You can achieve similar results in these situations by making small >> zones (switch1-rack1 switch1-rack2 switch1-rack3 switch2-rack1 >> switch2-rack2 switch2-rack3) but that removes the ability to decide to >> launch something with less granularity. I.e. you can’t just specify >> ‘switch1' or ‘rack1' or ‘anywhere’ >> >> I’d like to see all of the following work >> nova boot … (boot anywhere) >> nova boot —availability-zone switch1 … (boot it switch1 zone) >> nova boot —availability-zone rack1 … (boot in rack1 zone) >> nova boot —availability-zone switch1,rack1 … (boot > > Personally, I feel it is a mistake to continue to use the Amazon concept > of an availability zone in OpenStack, as it brings with it the > connotation from AWS EC2 that each zone is an independent failure > domain. This characteristic of EC2 availability zones is not enforced in > OpenStack Nova or Cinder, and therefore creates a false expectation for > Nova users. > > In addition to the above problem with incongruent expectations, the > other problem with Nova's use of the EC2 availability zone concept is > that availability zones are not hierarchical -- due to the fact that EC2 > AZs are independent failure domains. Not having the possibility of > structuring AZs hierarchically limits the ways in which Nova may be > deployed -- just see the cells API for the manifestation of this > problem. > > I would love it if the next version of the Nova and Cinder APIs would > drop the concept of an EC2 availability zone and introduce the concept > of a generic region structure that can be infinitely hierarchical in > nature. This would enable all of Vish's nova boot commands above in an > even simpler fashion. For example: > > Assume a simple region hierarchy like so: > > regionA > / \ > regionBregionC > > # User wants to boot in region B > nova boot --region regionB > # User wants to boot in either region B or region C > nova boot --region regionA I think the overlapping zones allows for this and also enables additional use cases as mentioned in my earlier email. Hierarchical doesn’t work for the rack/switch model. I’m definitely +1 on breaking from the amazon usage of availability zones but I’m a bit leery to add another parameter to the create request. It is also unfortunate that region already has a meaning in the amazon world which will add confusion. Vish > > I think of the EC2 availability zone concept in the Nova and Cinder APIs > as just another example of implementation leaking out of the API. The > fact that EC2 availability zones are implemented as independent failure > domains and thus have a non-hierarchical structure has caused the Nova > API to look and feel a certain way that locks the API into the > implementation of a non-OpenStack product. > > Best, > -jay > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
Yes, Vish description describes the uses cases and the need for multiple overlapping availability zones nicely. If multiple availability zone can be specified in the launch command that will allow End user to select hosts that satisfy all there constraints. Thanks, Sangeeta On 3/26/14, 11:00 AM, "Chris Friesen" wrote: >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 >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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On Wed, 2014-03-26 at 09:47 -0700, Vishvananda Ishaya wrote: > Personally I view this as a bug. There is no reason why we shouldn’t > support arbitrary grouping of zones. I know there is at least one > problem with zones that overlap regarding displaying them properly: > > https://bugs.launchpad.net/nova/+bug/1277230 > > There is probably a related issue that is causing the error you see > below. IMO both of these should be fixed. I also think adding a > compute node to two different aggregates with azs should be allowed. > > It also might be nice to support specifying multiple zones in the > launch command in these models. This would allow you to limit booting > to an intersection of two overlapping zones. > > A few examples where these ideas would be useful: > > 1. You have 3 racks of servers and half of the nodes from each rack > plugged into a different switch. You want to be able to specify to > spread across racks or switches via an AZ. In this model you could > have a zone for each switch and a zone for each rack. > > 2. A single cloud has 5 racks in one room in the datacenter and 5 > racks in a second room. You’d like to give control to the user to > choose the room or choose the rack. In this model you would have one > zone for each room, and smaller zones for each rack. > > 3. You have a small 3 rack cloud and would like to ensure that your > production workloads don’t run on the same machines as your dev > workloads, but you also want to use zones spread workloads across the > three racks. Similarly to 1., you could split your racks in half via > dev and prod zones. Each one of these zones would overlap with a rack > zone. > > You can achieve similar results in these situations by making small > zones (switch1-rack1 switch1-rack2 switch1-rack3 switch2-rack1 > switch2-rack2 switch2-rack3) but that removes the ability to decide to > launch something with less granularity. I.e. you can’t just specify > ‘switch1' or ‘rack1' or ‘anywhere’ > > I’d like to see all of the following work > nova boot … (boot anywhere) > nova boot —availability-zone switch1 … (boot it switch1 zone) > nova boot —availability-zone rack1 … (boot in rack1 zone) > nova boot —availability-zone switch1,rack1 … (boot Personally, I feel it is a mistake to continue to use the Amazon concept of an availability zone in OpenStack, as it brings with it the connotation from AWS EC2 that each zone is an independent failure domain. This characteristic of EC2 availability zones is not enforced in OpenStack Nova or Cinder, and therefore creates a false expectation for Nova users. In addition to the above problem with incongruent expectations, the other problem with Nova's use of the EC2 availability zone concept is that availability zones are not hierarchical -- due to the fact that EC2 AZs are independent failure domains. Not having the possibility of structuring AZs hierarchically limits the ways in which Nova may be deployed -- just see the cells API for the manifestation of this problem. I would love it if the next version of the Nova and Cinder APIs would drop the concept of an EC2 availability zone and introduce the concept of a generic region structure that can be infinitely hierarchical in nature. This would enable all of Vish's nova boot commands above in an even simpler fashion. For example: Assume a simple region hierarchy like so: regionA / \ regionBregionC # User wants to boot in region B nova boot --region regionB # User wants to boot in either region B or region C nova boot --region regionA I think of the EC2 availability zone concept in the Nova and Cinder APIs as just another example of implementation leaking out of the API. The fact that EC2 availability zones are implemented as independent failure domains and thus have a non-hierarchical structure has caused the Nova API to look and feel a certain way that locks the API into the implementation of a non-OpenStack product. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On 3/26/14, 10:17 AM, "Khanh-Toan Tran" wrote: > > >- Original Message - >> From: "Sangeeta Singh" >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> 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. > >> 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On 3/26/14, 10:17 AM, "Khanh-Toan Tran" wrote: > > >- Original Message - >> From: "Sangeeta Singh" >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> 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). The need arises when you need a way to use both the zones to be used for scheduling when no specific zone is specified. The only way to do that is either have a AZ which is a superset of the two AZ or the other way could be if the default_scheduler_zone can take a list of zones instead of just 1. > >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? > >> 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
From: , Santiago B mailto:santiago.b.baldas...@intel.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, March 26, 2014 at 5:17 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates.. I would say that the requirement is not valid. A host aggregate con only have one availability zone so what you actually can have is a compute node that’s part of 2 host aggregates, which actually have the same availability zone. It is in our case where we have a superset host aggregate that has all the hosts and then we have subset host aggregates(AZ) based on PDU. Need is that our user can specify the AZ based on the PDU but also in case no AZ is specified we want to load balance from the superset which contains two host-aggregates(AZ). In the scenario you mentioned below where you create the aggregates without associating the availability zone, after updating the aggregates with the zones, the hosts still share the same availability zone right? No the host becomes part of two availability zones one for each of the host aggregates. From: John Garbutt [mailto:j...@johngarbutt.com] Sent: Wednesday, March 26, 2014 8:47 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates.. Sounds like an extra weighter to try and balance load between your two AZs might be a nicer way to go. The easiest way might be via cells, one for each AZ . But not sure we merged that support yet. But there are patches for that. John On 25 Mar 2014 20:53, "Sangeeta Singh" mailto:sin...@yahoo-inc.com>> wrote: 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. 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. Any pointers. Thanks, Sangeeta ___ 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
- Original Message - > From: "Sangeeta Singh" > To: "OpenStack Development Mailing List (not for usage questions)" > > 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? > 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On 03/26/2014 10:47 AM, Vishvananda Ishaya wrote: Personally I view this as a bug. There is no reason why we shouldn’t support arbitrary grouping of zones. I know there is at least one problem with zones that overlap regarding displaying them properly: https://bugs.launchpad.net/nova/+bug/1277230 There's also this bug that I reported a while back, where nova will let you specify multiple host aggregates with the same zone name. https://bugs.launchpad.net/nova/+bug/1213224 If the end user then specifies the availability zone for an instance, it is unspecified which aggregate will be used. There is probably a related issue that is causing the error you see below. IMO both of these should be fixed. I also think adding a compute node to two different aggregates with azs should be allowed. It also might be nice to support specifying multiple zones in the launch command in these models. This would allow you to limit booting to an intersection of two overlapping zones. Totally agree. I actually mention both of these cases in the comments for the bug above. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
Personally I view this as a bug. There is no reason why we shouldn’t support arbitrary grouping of zones. I know there is at least one problem with zones that overlap regarding displaying them properly: https://bugs.launchpad.net/nova/+bug/1277230 There is probably a related issue that is causing the error you see below. IMO both of these should be fixed. I also think adding a compute node to two different aggregates with azs should be allowed. It also might be nice to support specifying multiple zones in the launch command in these models. This would allow you to limit booting to an intersection of two overlapping zones. A few examples where these ideas would be useful: 1. You have 3 racks of servers and half of the nodes from each rack plugged into a different switch. You want to be able to specify to spread across racks or switches via an AZ. In this model you could have a zone for each switch and a zone for each rack. 2. A single cloud has 5 racks in one room in the datacenter and 5 racks in a second room. You’d like to give control to the user to choose the room or choose the rack. In this model you would have one zone for each room, and smaller zones for each rack. 3. You have a small 3 rack cloud and would like to ensure that your production workloads don’t run on the same machines as your dev workloads, but you also want to use zones spread workloads across the three racks. Similarly to 1., you could split your racks in half via dev and prod zones. Each one of these zones would overlap with a rack zone. You can achieve similar results in these situations by making small zones (switch1-rack1 switch1-rack2 switch1-rack3 switch2-rack1 switch2-rack2 switch2-rack3) but that removes the ability to decide to launch something with less granularity. I.e. you can’t just specify ‘switch1' or ‘rack1' or ‘anywhere’ I’d like to see all of the following work nova boot … (boot anywhere) nova boot —availability-zone switch1 … (boot it switch1 zone) nova boot —availability-zone rack1 … (boot in rack1 zone) nova boot —availability-zone switch1,rack1 … (boot Vish On Mar 25, 2014, at 1:50 PM, Sangeeta Singh wrote: > 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. > > 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. > > Any pointers. > > Thanks, > Sangeeta > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
On 03/25/2014 02:50 PM, Sangeeta Singh wrote: 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 haven't actually tried it, but it might be worth configuring two different alternate availability zones each with half of the resources. Then if the user doesn't specify a zone they just get the nova zone which should then balance by load. My impression was that the support for multiple host aggregates were intended to support orthogonal groupings of of hosts. So "hosts with SSDs" could be one group, and "hosts with 10gig ethernet" another, and "hosts with lots of RAM" another group, and in that case you could have hosts that are part of any or all of those groups. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
I would say that the requirement is not valid. A host aggregate con only have one availability zone so what you actually can have is a compute node that's part of 2 host aggregates, which actually have the same availability zone. In the scenario you mentioned below where you create the aggregates without associating the availability zone, after updating the aggregates with the zones, the hosts still share the same availability zone right? From: John Garbutt [mailto:j...@johngarbutt.com] Sent: Wednesday, March 26, 2014 8:47 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates.. Sounds like an extra weighter to try and balance load between your two AZs might be a nicer way to go. The easiest way might be via cells, one for each AZ . But not sure we merged that support yet. But there are patches for that. John On 25 Mar 2014 20:53, "Sangeeta Singh" mailto:sin...@yahoo-inc.com>> wrote: 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. 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. Any pointers. Thanks, Sangeeta ___ 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
Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..
Sounds like an extra weighter to try and balance load between your two AZs might be a nicer way to go. The easiest way might be via cells, one for each AZ . But not sure we merged that support yet. But there are patches for that. John On 25 Mar 2014 20:53, "Sangeeta Singh" wrote: > 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. > > 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. > > 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] [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. 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. Any pointers. Thanks, Sangeeta ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
