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