Re: [openstack-dev] [nova] how to address boot from volume failures

2015-10-01 Thread Alex Xu 
2015-10-01 5:45 GMT+08:00 Andrew Laski :

> On 09/30/15 at 05:03pm, Sean Dague wrote:
>
>> Today we attempted to branch devstack and grenade for liberty, and are
>> currently blocked because in liberty with openstack client and
>> novaclient, it's not possible to boot a server from volume using just
>> the volume id.
>>
>> That's because of this change in novaclient -
>> https://review.openstack.org/#/c/221525/
>>
>> That was done to resolve the issue that strong schema validation in Nova
>> started rejecting the kinds of calls that novaclient was making for boot
>> from volume, because the bdm 1 and 2 code was sharing common code and
>> got a bit tangled up. So 3 bdm 2 params were being sent on every request.
>>
>> However, https://review.openstack.org/#/c/221525/ removed the ==1 code
>> path. If you pass in just {"vda": "$volume_id"} the code falls through,
>> volume id is lost, and nothing is booted. This is how the devstack
>> exercises and osc recommends booting from volume. I expect other people
>> might be doing that as well.
>>
>> There seem to be a few options going forward:
>>
>> 1) fix the client without a revert
>>
>> This would bring back a ==1 code path, which is basically just setting
>> volume_id, and move on. This means that until people upgrade their
>> client they loose access to this function on the server.
>>
>> 2) revert the client and loose up schema validation
>>
>> If we revert the client to the old code, we also need to accept the fact
>> that novaclient has been sending 3 extra parameters to this API call
>> since as long as people can remember. We'd need a nova schema relax to
>> let those in and just accept that people are going to pass those.
>>
>> 3) fix osc and novaclient cli to not use this code path. This will also
>> require everyone upgrades both of those to not explode in the common
>> case of specifying boot from volume on the command line.
>>
>> I slightly lean towards #2 on a compatibility front, but it's a chunk of
>> change at this point in the cycle, so I don't think there is a clear win
>> path. It would be good to collect opinions here. The bug tracking this
>> is - https://bugs.launchpad.net/python-openstackclient/+bug/1501435
>>
>
> I have a slight preference for #1.  Nova is not buggy here novaclient is
> so I think we should contain the fix there.
>

+1, this is novaclient bug.


>
> Is using the v2 API an option?  That should also allow the 3 extra
> parameters mentioned in #2.
>
>
>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> __
>> 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

Re: [openstack-dev] [nova] how to address boot from volume failures

2015-10-01 Thread Sean Dague 
On 09/30/2015 10:41 PM, melanie witt wrote:
> On Sep 30, 2015, at 14:45, Andrew Laski  > wrote:
> 
>> I have a slight preference for #1.  Nova is not buggy here novaclient
>> is so I think we should contain the fix there.
>>
>> Is using the v2 API an option?  That should also allow the 3 extra
>> parameters mentioned in #2.

It could be, but it would invalidate the claim that operators can just
point people at v2.1 and it won't be noticed.

> 
> +1. I have put up https://review.openstack.org/229669 in -W mode in case
> we decide to go that route. 
> 
> -melanie 

As the concensus is for item #1, I'm fine with that. +2 on
https://review.openstack.org/229669.

Let's get that landed and cut a new release today.

-Sean

-- 
Sean Dague
http://dague.net

__
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] how to address boot from volume failures

2015-10-01 Thread Andrew Laski 

On 10/01/15 at 06:17am, Sean Dague wrote:

On 09/30/2015 10:41 PM, melanie witt wrote:

On Sep 30, 2015, at 14:45, Andrew Laski > wrote:


I have a slight preference for #1.  Nova is not buggy here novaclient
is so I think we should contain the fix there.

Is using the v2 API an option?  That should also allow the 3 extra
parameters mentioned in #2.


It could be, but it would invalidate the claim that operators can just
point people at v2.1 and it won't be noticed.


I thought we were always clear that it shouldn't be noticed, unless the 
client in use was doing something it shouldn't be.  The goal of strict 
validation was to make that known to users.  Bugs in Tempest were 
discovered this way and bugs in novaclient and the previous response has 
always been to fix client behavior.






+1. I have put up https://review.openstack.org/229669 in -W mode in case
we decide to go that route.

-melanie


As the concensus is for item #1, I'm fine with that. +2 on
https://review.openstack.org/229669.

Let's get that landed and cut a new release today.

-Sean

--
Sean Dague
http://dague.net

__
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] how to address boot from volume failures

2015-10-01 Thread Andrey Kurilin 
>1) fix the client without a revert

I prefer to go with this option, since fix already done and pending review.

>This means that until people upgrade their
>client they loose access to this function on the server.

This applies to any of the proposed options.

On Thu, Oct 1, 2015 at 12:03 AM, Sean Dague  wrote:

> Today we attempted to branch devstack and grenade for liberty, and are
> currently blocked because in liberty with openstack client and
> novaclient, it's not possible to boot a server from volume using just
> the volume id.
>
> That's because of this change in novaclient -
> https://review.openstack.org/#/c/221525/
>
> That was done to resolve the issue that strong schema validation in Nova
> started rejecting the kinds of calls that novaclient was making for boot
> from volume, because the bdm 1 and 2 code was sharing common code and
> got a bit tangled up. So 3 bdm 2 params were being sent on every request.
>
> However, https://review.openstack.org/#/c/221525/ removed the ==1 code
> path. If you pass in just {"vda": "$volume_id"} the code falls through,
> volume id is lost, and nothing is booted. This is how the devstack
> exercises and osc recommends booting from volume. I expect other people
> might be doing that as well.
>
> There seem to be a few options going forward:
>
> 1) fix the client without a revert
>
> This would bring back a ==1 code path, which is basically just setting
> volume_id, and move on. This means that until people upgrade their
> client they loose access to this function on the server.
>
> 2) revert the client and loose up schema validation
>
> If we revert the client to the old code, we also need to accept the fact
> that novaclient has been sending 3 extra parameters to this API call
> since as long as people can remember. We'd need a nova schema relax to
> let those in and just accept that people are going to pass those.
>
> 3) fix osc and novaclient cli to not use this code path. This will also
> require everyone upgrades both of those to not explode in the common
> case of specifying boot from volume on the command line.
>
> I slightly lean towards #2 on a compatibility front, but it's a chunk of
> change at this point in the cycle, so I don't think there is a clear win
> path. It would be good to collect opinions here. The bug tracking this
> is - https://bugs.launchpad.net/python-openstackclient/+bug/1501435
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>



-- 
Best regards,
Andrey Kurilin.
__
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] how to address boot from volume failures

2015-10-01 Thread Nikola Đipanov 
On 09/30/2015 10:45 PM, Andrew Laski wrote:
> On 09/30/15 at 05:03pm, Sean Dague wrote:
>> Today we attempted to branch devstack and grenade for liberty, and are
>> currently blocked because in liberty with openstack client and
>> novaclient, it's not possible to boot a server from volume using just
>> the volume id.
>>
>> That's because of this change in novaclient -
>> https://review.openstack.org/#/c/221525/
>>
>> That was done to resolve the issue that strong schema validation in Nova
>> started rejecting the kinds of calls that novaclient was making for boot
>> from volume, because the bdm 1 and 2 code was sharing common code and
>> got a bit tangled up. So 3 bdm 2 params were being sent on every request.
>>
>> However, https://review.openstack.org/#/c/221525/ removed the ==1 code
>> path. If you pass in just {"vda": "$volume_id"} the code falls through,
>> volume id is lost, and nothing is booted. This is how the devstack
>> exercises and osc recommends booting from volume. I expect other people
>> might be doing that as well.
>>
>> There seem to be a few options going forward:
>>
>> 1) fix the client without a revert
>>
>> This would bring back a ==1 code path, which is basically just setting
>> volume_id, and move on. This means that until people upgrade their
>> client they loose access to this function on the server.
>>
>> 2) revert the client and loose up schema validation
>>
>> If we revert the client to the old code, we also need to accept the fact
>> that novaclient has been sending 3 extra parameters to this API call
>> since as long as people can remember. We'd need a nova schema relax to
>> let those in and just accept that people are going to pass those.
>>
>> 3) fix osc and novaclient cli to not use this code path. This will also
>> require everyone upgrades both of those to not explode in the common
>> case of specifying boot from volume on the command line.
>>
>> I slightly lean towards #2 on a compatibility front, but it's a chunk of
>> change at this point in the cycle, so I don't think there is a clear win
>> path. It would be good to collect opinions here. The bug tracking this
>> is - https://bugs.launchpad.net/python-openstackclient/+bug/1501435
> 
> I have a slight preference for #1.  Nova is not buggy here novaclient is
> so I think we should contain the fix there.
> 

+1 - this is obviously a client bug

> Is using the v2 API an option?  That should also allow the 3 extra
> parameters mentioned in #2.
> 

This could be a short term solution I guess, but long term we want to be
testing the code that is there to stay so really we want to fix the
client ASAP.

N.


__
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] how to address boot from volume failures

2015-09-30 Thread Sean Dague 
Today we attempted to branch devstack and grenade for liberty, and are
currently blocked because in liberty with openstack client and
novaclient, it's not possible to boot a server from volume using just
the volume id.

That's because of this change in novaclient -
https://review.openstack.org/#/c/221525/

That was done to resolve the issue that strong schema validation in Nova
started rejecting the kinds of calls that novaclient was making for boot
from volume, because the bdm 1 and 2 code was sharing common code and
got a bit tangled up. So 3 bdm 2 params were being sent on every request.

However, https://review.openstack.org/#/c/221525/ removed the ==1 code
path. If you pass in just {"vda": "$volume_id"} the code falls through,
volume id is lost, and nothing is booted. This is how the devstack
exercises and osc recommends booting from volume. I expect other people
might be doing that as well.

There seem to be a few options going forward:

1) fix the client without a revert

This would bring back a ==1 code path, which is basically just setting
volume_id, and move on. This means that until people upgrade their
client they loose access to this function on the server.

2) revert the client and loose up schema validation

If we revert the client to the old code, we also need to accept the fact
that novaclient has been sending 3 extra parameters to this API call
since as long as people can remember. We'd need a nova schema relax to
let those in and just accept that people are going to pass those.

3) fix osc and novaclient cli to not use this code path. This will also
require everyone upgrades both of those to not explode in the common
case of specifying boot from volume on the command line.

I slightly lean towards #2 on a compatibility front, but it's a chunk of
change at this point in the cycle, so I don't think there is a clear win
path. It would be good to collect opinions here. The bug tracking this
is - https://bugs.launchpad.net/python-openstackclient/+bug/1501435

-Sean

-- 
Sean Dague
http://dague.net

__
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] how to address boot from volume failures

2015-09-30 Thread Andrew Laski 

On 09/30/15 at 05:03pm, Sean Dague wrote:

Today we attempted to branch devstack and grenade for liberty, and are
currently blocked because in liberty with openstack client and
novaclient, it's not possible to boot a server from volume using just
the volume id.

That's because of this change in novaclient -
https://review.openstack.org/#/c/221525/

That was done to resolve the issue that strong schema validation in Nova
started rejecting the kinds of calls that novaclient was making for boot
from volume, because the bdm 1 and 2 code was sharing common code and
got a bit tangled up. So 3 bdm 2 params were being sent on every request.

However, https://review.openstack.org/#/c/221525/ removed the ==1 code
path. If you pass in just {"vda": "$volume_id"} the code falls through,
volume id is lost, and nothing is booted. This is how the devstack
exercises and osc recommends booting from volume. I expect other people
might be doing that as well.

There seem to be a few options going forward:

1) fix the client without a revert

This would bring back a ==1 code path, which is basically just setting
volume_id, and move on. This means that until people upgrade their
client they loose access to this function on the server.

2) revert the client and loose up schema validation

If we revert the client to the old code, we also need to accept the fact
that novaclient has been sending 3 extra parameters to this API call
since as long as people can remember. We'd need a nova schema relax to
let those in and just accept that people are going to pass those.

3) fix osc and novaclient cli to not use this code path. This will also
require everyone upgrades both of those to not explode in the common
case of specifying boot from volume on the command line.

I slightly lean towards #2 on a compatibility front, but it's a chunk of
change at this point in the cycle, so I don't think there is a clear win
path. It would be good to collect opinions here. The bug tracking this
is - https://bugs.launchpad.net/python-openstackclient/+bug/1501435


I have a slight preference for #1.  Nova is not buggy here novaclient 
is so I think we should contain the fix there.


Is using the v2 API an option?  That should also allow the 3 extra 
parameters mentioned in #2.




-Sean

--
Sean Dague
http://dague.net

__
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] how to address boot from volume failures

2015-09-30 Thread melanie witt 
On Sep 30, 2015, at 14:45, Andrew Laski  wrote:
> 
> I have a slight preference for #1.  Nova is not buggy here novaclient is so I 
> think we should contain the fix there.
> 
> Is using the v2 API an option?  That should also allow the 3 extra parameters 
> mentioned in #2.

+1. I have put up https://review.openstack.org/229669 in -W mode in case we 
decide to go that route. 

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