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. [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