Open Stack

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