Open Stack

On 09/24/15 at 09:34am, Sam Morrison wrote:
>Just got alerted to this on the operator list.
>
>We very much rely on this.
>
>We have multiple availability zones in nova and each zone has a corresponding cinder-volume service(s) in the same availability zone.
>
>We don’t want people attaching a volume from one zone to another as the network won’t allow that as the zones are in different network domains and different data centres.
>
>I wonder if you guys can reconsider deprecating this option as it is very useful to us.

I was perhaps hasty in approving that patch and didn't realize that Matt 
had reached out for operator feedback at the same time that he proposed 
it.  Since this is being used in production I wouldn't want it to be 
removed without at least having an alternative, and hopefully better, 
method of achieving your goal.  Reverting the deprecation seems 
reasonable to me for now while we work out the details around 
Cinder/Nova AZ interactions.



>
>Cheers,
>Sam
>
>
>
>> On 24 Sep 2015, at 7:43 am, Mathieu Gagné <mgagne at internap.com> wrote:
>>
>> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev