Open Stack

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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev