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
