I am fine with taking the approach of user passing multiple avail. zones Az1,Az2 if he wants vm to be in (intersection of AZ1 and Az2). It will be more cleaner.
But, similar approach should also be used while setting the default_scheduling_zone. Since, we will not be able to add host to multiple zones, only way to guarantee even distribution across zones when user does not pass any zone, is to allow multiple zones in default_scheduling_zone param. Thanks, Meghal On Apr 4, 2014, at 2:38 AM, Sylvain Bauza <sylvain.ba...@gmail.com<mailto:sylvain.ba...@gmail.com>> wrote: 2014-04-04 10:30 GMT+02:00 Sylvain Bauza <sylvain.ba...@gmail.com<mailto:sylvain.ba...@gmail.com>>: Hi all, 2014-04-03 18:47 GMT+02:00 Meghal Gosalia <meg...@yahoo-inc.com<mailto:meg...@yahoo-inc.com>>: Hello folks, Here is the bug [1] which is currently not allowing a host to be part of two availability zones. This bug was targeted for havana. The fix in the bug was made because it was assumed that openstack does not support adding hosts to two zones by design. The assumption was based on the fact that --- if hostX is added to zoneA as well as zoneB, and if you boot a vm vmY passing zoneB in boot params, nova show vmY still returns zoneA. In my opinion, we should fix the case of nova show rather than changing aggregate api to not allow addition of hosts to multiple zones. I have added my comments in comments #7 and #9 on that bug. Thanks, Meghal [1] Bug - https://bugs.launchpad.net/nova/+bug/1196893 Thanks for the pointer, now I see why the API is preventing host to be added to a 2nd aggregated if there is a different AZ. Unfortunately, this patch missed the fact that aggregates metadata can be modified once the aggregate is created, so we should add a check when updating metadate in order to cover all corner cases. So, IMHO, it's worth providing a patch for API consistency so as we enforce the fact that a host should be in only one AZ (but possibly 2 or more aggregates) and see how we can propose to user ability to provide 2 distincts AZs when booting. Does everyone agree ? Well, I'm replying to myself. The corner case is even trickier. I missed this patch [1] which already checks that when updating an aggregate to set an AZ, its hosts are not already part of another AZ. So, indeed, the coverage is already there... except for one thing : If an operator is creating an aggregate with an AZ set to the default AZ defined in nova.conf and adds an host to this aggregate, nova availability-zone-list does show the host being part of this default AZ (normal behaviour). If we create an aggregate 'foo' without AZ, then we add the same host to that aggregate, and then we update the metadata of the aggregate to set an AZ 'foo', then the AZ check won't notice that the host is already part of an AZ and will allow the host to be part of two distinct AZs. Proof here : http://paste.openstack.org/show/75066/ I'm on that bug. -Sylvain [1] : https://review.openstack.org/#/c/36786 -Sylvain On Apr 3, 2014, at 9:05 AM, Steve Gordon <sgor...@redhat.com<mailto:sgor...@redhat.com>> wrote: ----- Original Message ----- Currently host aggregates are quite general, but the only ways for an end-user to make use of them are: 1) By making the host aggregate an availability zones (where each host is only supposed to be in one availability zone) and selecting it at instance creation time. 2) By booting the instance using a flavor with appropriate metadata (which can only be set up by admin). I would like to see more flexibility available to the end-user, so I think we should either: A) Allow hosts to be part of more than one availability zone (and allow selection of multiple availability zones when booting an instance), or While changing to allow hosts to be in multiple AZs changes the concept from an operator/user point of view I do think the idea of being able to specify multiple AZs when booting an instance makes sense and would be a nice enhancement for users working with multi-AZ environments - "I'm OK with this instance running in AZ1 and AZ2, but not AZ*". -Steve _______________________________________________ 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<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<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
