[Openstack] Host aggregates - FF-Exception request
Hi folks, I am asking for a Feature-Freeze exception for the blueprint https://blueprints.launchpad.net/nova/+spec/host-aggregates. I appreciate that is now late for getting the bulk of this feature into E3, however we are ready to get this feature early in E4. We have got a few reviews in the queue, and we are close to completing them. It was my understanding that E4 was not for big changes (or even API changes), however Host Aggregates is barely touching the core code (actually, it can be argued that is not touching it at all). More importantly, having this stuff in trunk will unblock other features that will help close the gap between KVM and XenAPI. Thanks, Armando ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] 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
Re: [Openstack] Host Aggregates ...
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
Re: [Openstack] Host Aggregates ...
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
[Openstack] 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
