Open Stack

Hi Phil,



2014-04-07 18:48 GMT+02:00 Day, Phil <philip.day at hp.com>:

>  Hi Sylvain,
>
>
>
> There was a similar thread on this recently - which might be worth
> reviewing:
> http://lists.openstack.org/pipermail/openstack-dev/2014-March/031006.html
>
>
>
> Some interesting use cases were posted, and a I don't think a conclusion
> was reached, which seems to suggest this might be a good case for a session
> in Atlanta.
>
>

The funny fact is that I was already part of this discussion as owner of a
bug related to it (see the original link I provided).
That's only when reviewing the code by itself that I found some
discrepancies and raised the question here, before committing.



>
>
> Personally I'm not sure that selecting more than one AZ really makes a lot
> of sense - they are generally objects which are few in number and large in
> scale, so if for example there are 3 AZs and you want to create two servers
> in different AZs, does it really help if you can do the sequence:
>
>
>
> -          Create a server in any AZ
>
> -          Find the AZ the server is in
>
> -          Create a new server in any of the two remaining AZs
>
>
>
> Rather than just picking two from the list to start with ?
>
>
>
> If you envisage a system with many AZs, and thereby allow users some
> pretty find grained choices about where to place their instances, then I
> think you'll end up with capacity management issues.
>
>
>
> If the use case is more to get some form of server isolation, then
> server-groups might be worth looking at, as these are dynamic and per user.
>
>
>
> I can see a case for allowing more than one set of mutually exclusive host
> aggregates - at the moment that's a property implemented just for the set
> of aggregates that are designated as AZs, and generalizing that concept so
> that there can be other sets (where host overlap is allowed between sets,
> but not within a set) might be useful.
>
>
>
> Phil
>
>
>

That's a good point for discussing at the Summit. I don't have yet an
opinion on this, I'm just trying to stabilize things now :-)
At the moment, I'm pretty close to submit a change which will fix two
things :
 - the decisional will be the same for both adding a server to an aggregate
and update metadata from an existing aggregate (there was duplicate code
leading to a few differences)
 - when checking existing AZs for one host, we will also get the aggregates
to know if the default AZ is related to an existing aggregate with the same
name or just something unrelated

Thanks,
-Sylvain



>   *From:* Murray, Paul (HP Cloud Services)
> *Sent:* 03 April 2014 16:34
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Nova] Hosts within two Availability Zones
> : possible or not ?
>
>
>
> Hi Sylvain,
>
>
>
> I would go with keeping AZs exclusive. It is a well-established concept
> even if it is up to providers to implement what it actually means in terms
> of isolation. Some good use cases have been presented on this topic
> recently, but for me they suggest we should develop a better concept rather
> than bend the meaning of the old one. We certainly don't have hosts in more
> than one AZ in HP Cloud and I think some of our users would be very
> surprised if we changed that.
>
>
>
> Paul.
>
>
>
> *From:* Khanh-Toan Tran [mailto:khanh-toan.tran at cloudwatt.com<khanh-toan.tran at cloudwatt.com>]
>
> *Sent:* 03 April 2014 15:53
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Nova] Hosts within two Availability Zones
> : possible or not ?
>
>
>
> +1 for AZs not sharing hosts.
>
>
>
> Because it's the only mechanism that allows us to segment the datacenter.
> Otherwise we cannot provide redundancy to client except using Region which
> is dedicated infrastructure and networked separated and anti-affinity
> filter which IMO is not pragmatic as it has tendency of abusive usage.  Why
> sacrificing this power so that users can select the types of his desired
> physical hosts ? The latter can be exposed using flavor metadata, which is
> a lot safer and more controllable than using AZs. If someone insists that
> we really need to let users choose the types of physical hosts, then I
> suggest creating a new hint, and use aggregates with it. Don't sacrifice AZ
> exclusivity!
>
>
>
> Btw, there is a datacenter design called "dual-room" [1] which I think
> best fit for AZs to make your cloud redundant even with one datacenter.
>
>
>
> Best regards,
>
>
>
> Toan
>
>
>
> [1] IBM and Cisco: Together for a World Class Data Center, Page 141.
> http://books.google.fr/books?id=DHjJAgAAQBAJ&pg=PA141#v=onepage&q&f=false
>
>
>
>
>
>
>
> *De :* Sylvain Bauza [mailto:sylvain.bauza at gmail.com<sylvain.bauza at gmail.com>]
>
> *Envoyé :* jeudi 3 avril 2014 15:52
> *À :* OpenStack Development Mailing List (not for usage questions)
> *Objet :* [openstack-dev] [Nova] Hosts within two Availability Zones :
> possible or not ?
>
>
>
> Hi,
>
>
>
> I'm currently trying to reproduce [1]. This bug requires to have the same
> host on two different aggregates, each one having an AZ.
>
>
>
> IIRC, Nova API prevents hosts of being part of two distinct AZs [2], so
> IMHO this request should not be possible.
>
> That said, there are two flaws where I can identify that no validation is
> done :
>
>  - when specifying an AZ in nova.conf, the host is overriding the existing
> AZ by its own
>
>  - when adding an host to an aggregate without AZ defined, and afterwards
> update the aggregate to add an AZ
>
>
>
>
>
> So, I need direction. Either we consider it is not possible to share 2 AZs
> for the same host and then we need to fix the two above scenarios, or we
> say it's nice to have 2 AZs for the same host and then we both remove the
> validation check in the API and we fix the output issue reported in the
> original bug [1].
>
>
>
>
>
> Your comments are welcome.
>
> Thanks,
>
> -Sylvain
>
>
>
>
>
> [1] : https://bugs.launchpad.net/nova/+bug/1277230
>
>
>
> [2] :
> https://github.com/openstack/nova/blob/9d45e9cef624a4a972c24c47c7abd57a72d74432/nova/compute/api.py#L3378
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140407/73ff3cd7/attachment.html>