Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Matt Riedemann]

On 5/23/2017 7:12 PM, Michael Glasgow wrote:


A slight disadvantage of this approach is that the resulting 
incongruence between the client and the API is obfuscating.  When an end 
user can make accurate inferences about the API based on how the client 
works, that's a form of transparency that can pay dividends.


Also in terms of the "slippery slope" that has been raised, putting 
small bits of orchestration into the client creates a grey area there as 
well:  how much is too much?


OTOH I don't disagree with you.  This approach might be the best of 
several not-so-great options, but I wish I could think of a better one.


Just an FYI that this same 'pass volume type when booting from volume' 
request came up again today:


https://review.openstack.org/#/c/579520/

We might want to talk about this again at the Stein PTG in September to 
see if the benefit of adding this for people outweighs the orchestration 
cost since it seems it's never going to go away and lots of deployments 
are already patching it in.


--

Thanks,

Matt

__
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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Matt Riedemann]

On 6/2/2017 12:40 AM, 한승진 wrote:

Hello, stackers

I am just curious about the results of lots of discussions on the below 
blueprint.


https://blueprints.launchpad.net/nova/+spec/support-volume-type-with-bdm-parameter

Can I ask what the concolusion is?




__
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



There wasn't one really. There is a mailing list discussion here:

http://lists.openstack.org/pipermail/openstack-dev/2017-May/117242.html

Which turned into a discussion about porcelain APIs.

--

Thanks,

Matt

__
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-dev] [nova] Supporting volume_type when booting from volume

[한승진]

Hello, stackers

I am just curious about the results of lots of discussions on the below
blueprint.

https://blueprints.launchpad.net/nova/+spec/support-volume-type-with-bdm-parameter

Can I ask what the concolusion is?
__
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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[John Griffith]

On Tue, May 23, 2017 at 3:43 PM, Dean Troyer  wrote:

> On Tue, May 23, 2017 at 3:42 PM, Sean McGinnis 
> wrote:
> >
> >> If it's just too much debt and risk of slippery slope type arguments on
> >> the Nova side (and that's fair, after lengthy conversations with Nova
> folks
> >> I get it), do we consider just orchestrating this from say OpenStack
> Client
> >> completely?  The last resort (and it's an awful option) is orchestrate
> the
> >> whole thing from Cinder.  We can certainly make calls to Nova and pass
> in
> >> the volume using the semantics that are already accepted and in use.
> >>
> >> John
> >>
> >
> > /me runs away screaming!
>
> Now I know Sean's weakness...
>
​Ha!  I thought it was the put it in Cinder part (so I have a patch queued
up for emergencies when I need to threaten him). :)
​


>
> In this particular case it may not be necessary, but I think early
> implementation of composite features in clients is actually the right
> way to prove the utility of these things going forward.

​Yeah, I've been doing more with OSC as of late and it really has all the
pieces and currently is one of the few places in OpenStack that really
knows what the other actors are up to (or at least how to communicate with
them and ask them to do things).

It does seem like a reasonable place (OSC), and as far as some major
objections I've heard already around "where would you draw the line"...
yeah, that's important.  To start though orchestrated "features" that have
been requested for multiple releases that are actually fairly trivial to
implement might be a great starting point.  It's at least worth thinking on
for a bit in my opinion.
​


> Establish and
> document the process, implement in a way for users to opt-in, and move
> into the services as they are proven useful.  With the magic of
> microversions we can then migrate from client-side to server-side as
> the implementations roll through the deployment lifecycle.
>
> This last bit is important.   Even today many of our users are unable
> to take advantage of useful features that are already over a year old
> due to the upgrade delay that production deployments see.
> Implementing new things in clients helps users on existing clouds.
> Sure other client implementations are left to their own work, but they
> should have a common process model to follow, and any choice to
> deviate from that is their own.
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> 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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Yingjun Li]

It’s definitely a nice feature to have for end user, actually we implemented it 
our own because we need this but
nova doesn’t support.

Yingjun

> On May 24, 2017, at 6:58 AM, Jay Bryant  wrote:
> 
> 
> On 5/23/2017 9:56 AM, Duncan Thomas wrote:
>> 
>> 
>> On 23 May 2017 4:51 am, "Matt Riedemann" > > wrote:
>> 
>> 
>> Is this really something we are going to have to deny at least once per 
>> release? My God how is it that this is the #1 thing everyone for all time 
>> has always wanted Nova to do for them?
>> 
>> Is it entirely unreasonable to turn the question around and ask why, given 
>> it is such a commonly requested feature, the Nova team are so resistant to 
>> it?
>> 
>> 
>> __
>> 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 
>> 
> 
> I am going to jump into the fray here ...
> 
> I think that at some point we need to do a cost/benefit analysis.  If 
> customers really want this, than maybe it is worth the potential technical 
> debt.  Going down a route of hacking something together from the client seems 
> to potentially incur more technical debt and create a worse UX.
> 
> At the risks of having things thrown at me, I am going to say that this could 
> have a number of benefits.  It could be leveraged by the Cinder Ephemeral 
> driver that is being considered.  Volume types associated with compute hosts 
> could be used to ensure use of storage local to the compute host that is 
> managed by Cinder.
> 
> Anyway, that is my $0.02.
> 
> Jay
> __
> 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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Michael Glasgow]

On 5/23/2017 4:43 PM, Dean Troyer wrote:

In this particular case it may not be necessary, but I think early
implementation of composite features in clients is actually the right
way to prove the utility of these things going forward.  Establish and
document the process, implement in a way for users to opt-in, and move
into the services as they are proven useful.


A slight disadvantage of this approach is that the resulting 
incongruence between the client and the API is obfuscating.  When an end 
user can make accurate inferences about the API based on how the client 
works, that's a form of transparency that can pay dividends.


Also in terms of the "slippery slope" that has been raised, putting 
small bits of orchestration into the client creates a grey area there as 
well:  how much is too much?


OTOH I don't disagree with you.  This approach might be the best of 
several not-so-great options, but I wish I could think of a better one.


--
Michael Glasgow

__
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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Jay Bryant]

On 5/23/2017 9:56 AM, Duncan Thomas wrote:



On 23 May 2017 4:51 am, "Matt Riedemann" > wrote:




Is this really something we are going to have to deny at least
once per release? My God how is it that this is the #1 thing
everyone for all time has always wanted Nova to do for them?


Is it entirely unreasonable to turn the question around and ask why, 
given it is such a commonly requested feature, the Nova team are so 
resistant to it?



__
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


I am going to jump into the fray here ...

I think that at some point we need to do a cost/benefit analysis.  If 
customers really want this, than maybe it is worth the potential 
technical debt.  Going down a route of hacking something together from 
the client seems to potentially incur more technical debt and create a 
worse UX.


At the risks of having things thrown at me, I am going to say that this 
could have a number of benefits.  It could be leveraged by the Cinder 
Ephemeral driver that is being considered.  Volume types associated with 
compute hosts could be used to ensure use of storage local to the 
compute host that is managed by Cinder.


Anyway, that is my $0.02.

Jay

__
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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Dean Troyer]

On Tue, May 23, 2017 at 3:42 PM, Sean McGinnis  wrote:
>
>> If it's just too much debt and risk of slippery slope type arguments on
>> the Nova side (and that's fair, after lengthy conversations with Nova folks
>> I get it), do we consider just orchestrating this from say OpenStack Client
>> completely?  The last resort (and it's an awful option) is orchestrate the
>> whole thing from Cinder.  We can certainly make calls to Nova and pass in
>> the volume using the semantics that are already accepted and in use.
>>
>> John
>>
>
> /me runs away screaming!

Now I know Sean's weakness...

In this particular case it may not be necessary, but I think early
implementation of composite features in clients is actually the right
way to prove the utility of these things going forward.  Establish and
document the process, implement in a way for users to opt-in, and move
into the services as they are proven useful.  With the magic of
microversions we can then migrate from client-side to server-side as
the implementations roll through the deployment lifecycle.

This last bit is important.   Even today many of our users are unable
to take advantage of useful features that are already over a year old
due to the upgrade delay that production deployments see.
Implementing new things in clients helps users on existing clouds.
Sure other client implementations are left to their own work, but they
should have a common process model to follow, and any choice to
deviate from that is their own.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Sean McGinnis]

If it's just too much debt and risk of slippery slope type arguments on 
the Nova side (and that's fair, after lengthy conversations with Nova 
folks I get it), do we consider just orchestrating this from say 
OpenStack Client completely?  The last resort (and it's an awful option) 
is orchestrate the whole thing from Cinder.  We can certainly make calls 
to Nova and pass in the volume using the semantics that are already 
accepted and in use.


John



/me runs away screaming!


__
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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[John Griffith]

On Tue, May 23, 2017 at 10:13 AM, Matt Riedemann 
wrote:

> On 5/23/2017 9:56 AM, Duncan Thomas wrote:
>
>> Is it entirely unreasonable to turn the question around and ask why,
>> given it is such a commonly requested feature, the Nova team are so
>> resistant to it?
>>
>
> Because it's technical debt for one thing. Adding more orchestration adds
> complexity, which adds bugs. Also, as noted in the linked devref on this,
> when nova proxies something via the compute API to another service's API,
> if that other service changes their API (like with nova's image proxy API
> to glance v1 for example, and needing to get to glance v2), then we have
> this weird situation with compatibility. Which is more technical debt.
> Microversions should make that less of an issue, but it's still there.
>
> It's also a slippery slope. Once you allow proxies and orchestration into
> part of the API, people use it as grounds for justifying doing more of it
> elsewhere, i.e. if we do this for volumes, when are we going to start
> seeing people asking for passing more detailed information about Neutron
> ports when creating a server?
>
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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
>
​I get the concern about adding more orchestration etc, I'm not totally
convinced only because it's adding another flag as opposed to functionality
etc.  But, regardless I get the argument and the slippery slope after
talking through it with Matt and Dan multiple times.

The disappointing part of this for me is that the main reason this comes up
(I believe) is not only because Cinder volumes are AWESOME!  But, probably
more accurately; all of the non-OpenStack public clouds behave this way (or
the big ones do at least).  Service Providers using OpenStack as well as
user consuming OpenStack have voiced that they'd like to have this same
functionality/behavior that includes selecting what type of volume.

If it's just too much debt and risk of slippery slope type arguments on the
Nova side (and that's fair, after lengthy conversations with Nova folks I
get it), do we consider just orchestrating this from say OpenStack Client
completely?  The last resort (and it's an awful option) is orchestrate the
whole thing from Cinder.  We can certainly make calls to Nova and pass in
the volume using the semantics that are already accepted and in use.

John
__
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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Matt Riedemann]

On 5/23/2017 9:56 AM, Duncan Thomas wrote:
Is it entirely unreasonable to turn the question around and ask why, 
given it is such a commonly requested feature, the Nova team are so 
resistant to it?


Because it's technical debt for one thing. Adding more orchestration 
adds complexity, which adds bugs. Also, as noted in the linked devref on 
this, when nova proxies something via the compute API to another 
service's API, if that other service changes their API (like with nova's 
image proxy API to glance v1 for example, and needing to get to glance 
v2), then we have this weird situation with compatibility. Which is more 
technical debt. Microversions should make that less of an issue, but 
it's still there.


It's also a slippery slope. Once you allow proxies and orchestration 
into part of the API, people use it as grounds for justifying doing more 
of it elsewhere, i.e. if we do this for volumes, when are we going to 
start seeing people asking for passing more detailed information about 
Neutron ports when creating a server?


--

Thanks,

Matt

__
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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Duncan Thomas]

On 23 May 2017 4:51 am, "Matt Riedemann"  wrote:



Is this really something we are going to have to deny at least once per
release? My God how is it that this is the #1 thing everyone for all time
has always wanted Nova to do for them?


Is it entirely unreasonable to turn the question around and ask why, given
it is such a commonly requested feature, the Nova team are so resistant to
it?
__
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

Re: [openstack-dev] [nova] Supporting volume_type when booting from volume

[Sean McGinnis]

On Mon, May 22, 2017 at 10:47:44PM -0500, Matt Riedemann wrote:
> Just wanted to point out that someone else requested this again today:
> 
> https://review.openstack.org/#/c/466595/
> 
> 30 seconds going through launchpad for old blueprints found at least 4
> others:
> 
> https://blueprints.launchpad.net/nova/+spec/vol-type-with-blank-vol
> 
> https://blueprints.launchpad.net/nova/+spec/volume-support-for-multi-hypervisors
> 
> https://blueprints.launchpad.net/nova/+spec/support-boot-instance-set-store-type
> 
> https://blueprints.launchpad.net/nova/+spec/ec2-volume-type
> 
> And I know cburgess and garyk at least had one each of their own.
> 
> Is this really something we are going to have to deny at least once per
> release? My God how is it that this is the #1 thing everyone for all time
> has always wanted Nova to do for them?
> 
> I'm honestly starting to get concerned.

To add to this, I've had this question/ask coming in on the Cinder side
quite often as well. There's a definite desire from users to be able to
do this.

Sean

__
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-dev] [nova] Supporting volume_type when booting from volume

[Matt Riedemann]

Just wanted to point out that someone else requested this again today:

https://review.openstack.org/#/c/466595/

30 seconds going through launchpad for old blueprints found at least 4 
others:


https://blueprints.launchpad.net/nova/+spec/vol-type-with-blank-vol

https://blueprints.launchpad.net/nova/+spec/volume-support-for-multi-hypervisors

https://blueprints.launchpad.net/nova/+spec/support-boot-instance-set-store-type

https://blueprints.launchpad.net/nova/+spec/ec2-volume-type

And I know cburgess and garyk at least had one each of their own.

Is this really something we are going to have to deny at least once per 
release? My God how is it that this is the #1 thing everyone for all 
time has always wanted Nova to do for them?


I'm honestly starting to get concerned.

--

Thanks,

Matt

__
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