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é <mga...@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-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
__________________________________________________________________________
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
