Just got alerted to this on the operator list. We very much rely on this.
We have multiple availability zones in nova and each zone has a corresponding cinder-volume service(s) in the same availability zone. We don’t want people attaching a volume from one zone to another as the network won’t allow that as the zones are in different network domains and different data centres. I wonder if you guys can reconsider deprecating this option as it is very useful to us. Cheers, Sam > On 24 Sep 2015, at 7:43 am, Mathieu Gagné <mga...@internap.com> wrote: > > On 2015-09-23 4:50 PM, Andrew Laski wrote: >> On 09/23/15 at 04:30pm, Mathieu Gagné wrote: >>> On 2015-09-23 4:12 PM, Andrew Laski wrote: >>>> On 09/23/15 at 02:55pm, Matt Riedemann wrote: >>>>> >>>>> Heh, so when I just asked in the cinder channel if we can just >>>>> deprecate nova boot from volume with source=(image|snapshot|blank) >>>>> (which automatically creates the volume and polls for it to be >>>>> available) and then add a microversion that doesn't allow it, I was >>>>> half joking, but I see we're on the same page. This scenario seems to >>>>> introduce a lot of orchestration work that nova shouldn't necessarily >>>>> be in the business of handling. >>>> >>>> I am very much in support of this. This has been a source of >>>> frustration for our users because it is prone to failures we can't >>>> properly expose to users and timeouts. There are much better places to >>>> handle the orchestration of creating a volume and then booting from it >>>> than Nova. >>>> >>> >>> Unfortunately, this is a feature our users *heavily* rely on and we >>> worked very hard to make it happen. We had a private patch on our side >>> for years to optimize boot-from-volume before John Griffith came up with >>> an upstream solution for SolidFire [2] and others with a generic >>> solution [3] [4]. >>> >>> Being able to "nova boot" and have everything done for you is awesome. >>> Just see what Monty Taylor mentioned in his thread about sane default >>> networking [1]. Having orchestration on the client side is just >>> something our users don't want to have to do and often complain about. >> >> At risk of getting too offtopic I think there's an alternate solution to >> doing this in Nova or on the client side. I think we're missing some >> sort of OpenStack API and service that can handle this. Nova is a low >> level infrastructure API and service, it is not designed to handle these >> orchestrations. I haven't checked in on Heat in a while but perhaps >> this is a role that it could fill. >> >> I think that too many people consider Nova to be *the* OpenStack API >> when considering instances/volumes/networking/images and that's not >> something I would like to see continue. Or at the very least I would >> like to see a split between the orchestration/proxy pieces and the >> "manage my VM/container/baremetal" bits. >> > > "too many people" happens to include a lot of 3rd party tools supporting > OpenStack which our users complain a lot about. Just see all the > possible way to get an external IP [5]. Introducing yet another service > would increase the pain on our users which will see their tools and > products not working even more. > > Just see how EC2 is doing it [6], you won't see them suggest to use yet > another service to orchestrate what I consider a fundamental feature "I > wish to boot an instance on a volume". > > The current ease to boot from volume is THE selling feature our users > want and heavily/actively use. We fought very hard to make it work and > reading about how it should be removed is frustrating. > > Issues we identified shouldn't be a reason to drop this feature. Other > providers are making it work and I don't see why we couldn't. I'm > convinced we can do better. > > [5] > https://github.com/openstack-infra/shade/blob/03c1556a12aabfc21de60a9fac97aea7871485a3/shade/meta.py#L106-L173 > [6] > http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html > > Mathieu > >>> >>> [1] >>> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074527.html >>> >>> [2] https://review.openstack.org/#/c/142859/ >>> [3] https://review.openstack.org/#/c/195795/ >>> [4] https://review.openstack.org/#/c/201754/ >>> >>> -- >>> Mathieu > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
