The main thing that the idea of host-aggregates provides is the ability to specify metadata at a group of hosts level. If you put 10 hosts into a single aggregate, you can specify characteristics for those hosts as a group (i.e. which san they are backing files onto, whether they support live migration, etc.) It is also the way that xen (and esx) model things internally, so if we don't do it we have to map our custom tags to resource pools in the hypervisor anyway. Finally, it also simplifies some scheduler logic. For example if you are trying to find a valid host to migrate instances onto, you can just ask for hosts in the same "group" and it is the cloud administrator's responsibility to make sure that all of the systems in that group have the required functionality. These "groups" could be implemented with tags, but I think conceptually the idea of a tag implies a more tenuous relationship than aggregate group.
I look at it as a grouping of hosts that is smaller than a zone (say a cluster). Large enough for shared metadata but small enough so that splitting the db and api would be a pain. Vish On Nov 10, 2011, at 5:01 AM, Sandy Walsh wrote: > Ok, that helps ... now I see the abstraction your going for (a new layer > under availability zones). > > Personally I prefer a tagging approach to a modeled hierarchy. It was > something we debated at great length with Zones. In this case, the "tag" > would be in the capabilities assigned to the host. > > I think both availability zones (and host aggregates) should be modeled using > tags/capabilities without having to explicitly model it as a tree or in the > db ... which is how I see this evolving. At the scheduler level we should be > able to make decisions using simple tag collections. > > "WestCoast, HasGPU, GeneratorBackup, PriorityNetwork" > > Are we saying the same thing? > > Are there use cases that this approach couldn't handle? > > -S > > ________________________________________ > From: Armando Migliaccio [armando.migliac...@eu.citrix.com] > Sent: Thursday, November 10, 2011 8:50 AM > To: Sandy Walsh > Cc: openstack@lists.launchpad.net > Subject: RE: Host Aggregates ... > > Hi Sandy, > > Thanks for taking the time to read this. > > My understanding is that a typical Nova deployment would span across multiple > zones, that zones may have subzones, and that child zones will have a number > of availability zones in them; please do correct me if I am wrong :) > > That stated, it was assumed that an aggregate will be a grouping of servers > within an availability zone (hence the introduction of the extra concept), > and would be used to manage hypervisor pools when and if required. This > introduces benefits like VM live migration, VM HA and zero-downtime host > upgrades. The introduction of hypervisor pools is just the easy way to get > these benefits in the short term. > > Going back to your point, it is possible to match "host-aggregates" with > "single-zone that uses capabilities" on the implementation level (assumed > that it is okay to be unable to represent aggregates as children of > availability zones). Nevertheless, I still see zones and aggregates as being > different on the conceptual level. > > What is your view if we went with the approach of implementing an aggregate > as a special "single-zone that uses capabilities"? Would there be a risk of > tangling the zone management API a bit? > > Thanks for feedback! > > Cheers, > Armando > >> -----Original Message----- >> From: Sandy Walsh [mailto:sandy.wa...@rackspace.com] >> Sent: 09 November 2011 21:10 >> To: Armando Migliaccio >> Cc: openstack@lists.launchpad.net >> Subject: Host Aggregates ... >> >> Hi Armando, >> >> I finally got around to reading >> https://blueprints.launchpad.net/nova/+spec/host-aggregates. >> >> Perhaps you could elaborate a little on how this differs from host >> capabilities (key-value pairs associated with a service) that the scheduler >> can use when making decisions? >> >> The distributed scheduler doesn't need zones to operate, but will use them if >> available. Would host-aggregates simply be a single-zone that uses >> capabilities? >> >> Cheers, >> Sandy > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
