Re: [openstack-dev] [nova] Next steps for proxy API deprecation
Thank you, Doug. Yes, if the DefCore guidelines have any of these tests, the tests used by DefCore will need to be run beyond EOL of Newton as the DefCore tests last longer than the EOL timeframe. But, first we should check which tests need to be capped and whether they are part of a/some DefCore guidelines. If yes, as Tempest/Defcore summit session would be good. Thanks! --Rocky -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Tuesday, July 26, 2016 10:46 AM To: openstack-dev Subject: Re: [openstack-dev] [nova] Next steps for proxy API deprecation Excerpts from Matt Riedemann's message of 2016-07-26 12:14:03 -0500: > On 7/26/2016 11:59 AM, Matt Riedemann wrote: > > Now that the 2.36 microversion change has merged [1], we can work on the > > python-novaclient changes for this microversion. > > > > At the midcycle we agreed [2] to also return a 404 for network APIs, > > including nova-network (which isn't a proxy), for consistency and > > further signaling that nova-network is going away. > > > > In the client, we agreed to soften the impact for network CLIs by > > determining if the latest microversion supported will fail (so will we > > send >=2.36) and rather than fail, send 2.35 instead (if the user didn't > > specifically specify a different version). However, we'd emit a warning > > saying this is deprecated and will go away in the first major client > > release (in Ocata? after nova-network is removed? after Ocata is > > released?). > > > > We should probably just deprecate any CLIs/APIs in python-novaclient > > today that are part of this server side API change, including network > > CLIs/APIs in novaclient. The baremetal and image proxies in the client > > are already deprecated, and the volume proxies were already removed. > > That leaves the network proxies in the client. > > > > From my notes, Dan Smith was going to work on the novaclient changes for > > 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to > > do that work (please speak up). > > > > We can probably do the network CLI/API deprecations in the client in > > parallel to the 2.36 support, but need someone to step up for that. I'll > > try to get it started this week if no one else does. > > > > [1] https://review.openstack.org/#/c/337005/ > > [2] https://etherpad.openstack.org/p/nova-newton-midcycle > > > > I forgot to mention Tempest. We're going to have to probably put a > max_microversion cap in several tests in Tempest to cap at 2.35 (or > change those to use Neutron?). There are also going to be some response > schema changes like for quota usage/limits, I'm not sure if anyone is > looking at this yet. We could also get it done after feature freeze on > 9/2, but I still need to land the get-me-a-network API change which is > microversion 2.37 and has it's own Tempest test, although that test > relies on Neutron so I might be OK for the most part. > If these tests are being used by DefCore, it would be better to cap the existing behavior and add new tests to use neutron instead of changing the existing tests. That will make it easier for DefCore to handle the transition from the old to new behavior by replacing the old tests in their list with the new ones. Doug __ 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] Next steps for proxy API deprecation
On 7/28/2016 11:20 PM, Ghanshyam Mann wrote: Yes, I also prefer the approach of capping the tests instead of jobs. But along with that we might need to make sure the same tests coverage Tempest provides if min_microversion is set >2.35 in config. For example, if we cap the tests (calls nova-network) with max_microversion = 2.35 then, we might need to implement/modify those tests to start using neutron which can be run if config's min_microversion is set > 2.35. There are two type of test cases- 1. Test only tests nova-network APIs - Example: https://github.com/openstack/tempest/tree/master/tempest/api/compute/floating_ips 2. Test testing other scenario using nova-network - Example: https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_server_rescue.py 1st case if all ok to cap and leave it skip for >2.35. But for 2nd case, I feel we should not leave them skip if config's min_microversion > 2.35 which mean leaving those scenario untested(if min_microversion >2.35). There are 2 options for 2nd case: 1. Implement duplicate tests by using the neutron APIs - This will be duplicate tests but needed because of testing nova-network till newton EOL. 2. Or modify those to switch from nova-network to neutron. - If we do not care about nova-network testing even for stable branches where it is not deprecated. I don't like either option, but I'd rather go with #1 for two reasons: a) Once nova-network is gone these tests wouldn't run ever, so we lose the coverage. b) nova-network wasn't deprecated in stable branches so I think we need to maintain those tests, so 2.1-2.35 are nova-network, 2.36+ are neutron. The duplication cost probably wouldn't be all that terrible, we could probably abstract a lot of the common network setup parts away for the compute API tests for things like creating a floating IP. Thanks gmann __ 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 -- Thanks, Matt Riedemann __ 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] Next steps for proxy API deprecation
> -Original Message- > From: Matthew Treinish [mailto:mtrein...@kortar.org] > Sent: 27 July 2016 02:36 > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [nova] Next steps for proxy API deprecation > > On Tue, Jul 26, 2016 at 01:21:53PM -0400, Sean Dague wrote: > > On 07/26/2016 01:14 PM, Matt Riedemann wrote: > > > On 7/26/2016 11:59 AM, Matt Riedemann wrote: > > >> Now that the 2.36 microversion change has merged [1], we can work > > >> on the python-novaclient changes for this microversion. > > >> > > >> At the midcycle we agreed [2] to also return a 404 for network > > >> APIs, including nova-network (which isn't a proxy), for consistency > > >> and further signaling that nova-network is going away. > > >> > > >> In the client, we agreed to soften the impact for network CLIs by > > >> determining if the latest microversion supported will fail (so will > > >> we send >=2.36) and rather than fail, send 2.35 instead (if the > > >> user didn't specifically specify a different version). However, > > >> we'd emit a warning saying this is deprecated and will go away in > > >> the first major client release (in Ocata? after nova-network is > > >> removed? after Ocata is released?). > > >> > > >> We should probably just deprecate any CLIs/APIs in > > >> python-novaclient today that are part of this server side API > > >> change, including network CLIs/APIs in novaclient. The baremetal > > >> and image proxies in the client are already deprecated, and the volume > proxies were already removed. > > >> That leaves the network proxies in the client. > > >> > > >> From my notes, Dan Smith was going to work on the novaclient > > >> changes for > > >> 2.36 to not fail and use 2.35 - unless anyone else wants to > > >> volunteer to do that work (please speak up). > > >> > > >> We can probably do the network CLI/API deprecations in the client > > >> in parallel to the 2.36 support, but need someone to step up for > > >> that. I'll try to get it started this week if no one else does. > > >> > > >> [1] https://review.openstack.org/#/c/337005/ > > >> [2] https://etherpad.openstack.org/p/nova-newton-midcycle > > >> > > > > > > I forgot to mention Tempest. We're going to have to probably put a > > > max_microversion cap in several tests in Tempest to cap at 2.35 (or > > > change those to use Neutron?). There are also going to be some > > > response schema changes like for quota usage/limits, I'm not sure if > > > anyone is looking at this yet. We could also get it done after > > > feature freeze on 9/2, but I still need to land the get-me-a-network > > > API change which is microversion 2.37 and has it's own Tempest test, > > > although that test relies on Neutron so I might be OK for the most part. > > > > Is that strictly true? We could also just configure all the jobs for > > Nova network to set max microversion at 2.35. That would probably be > > more straight forward way of approaching this, and make it a bit more > > clear how serious we are here. > > > > Yeah, for the gate that should work. By default tempest sends the minimum > microversion based on the config and the test requirements. So we should > never send 2.36 unless the test says it's minimum required microversion is > >=2.36. Setting the max at 2.35 would mean we skip those tests. My bigger > concern is for people using tempest outside of the gate. I still think we > should set a max microversion on any test classes that call nova's network > apis to make sure they're properly skipped just in case someone sets the min > microversion in the tempest config at 2.36. (assuming such a test class exists > at all, I don't actually know) Unless you thinking failing there is the > correct > way to do it? Yes, I also prefer the approach of capping the tests instead of jobs. But along with that we might need to make sure the same tests coverage Tempest provides if min_microversion is set >2.35 in config. For example, if we cap the tests (calls nova-network) with max_microversion = 2.35 then, we might need to implement/modify those tests to start using neutron which can be run if config's min_microversion is set > 2.35. There are two type of test cases- 1. Test only tests nova-network APIs - Example: https://github.com/openstack/tempest/tree/master/tempest/api/compu
Re: [openstack-dev] [nova] Next steps for proxy API deprecation
Excerpts from Matt Riedemann's message of 2016-07-26 12:14:03 -0500: > On 7/26/2016 11:59 AM, Matt Riedemann wrote: > > Now that the 2.36 microversion change has merged [1], we can work on the > > python-novaclient changes for this microversion. > > > > At the midcycle we agreed [2] to also return a 404 for network APIs, > > including nova-network (which isn't a proxy), for consistency and > > further signaling that nova-network is going away. > > > > In the client, we agreed to soften the impact for network CLIs by > > determining if the latest microversion supported will fail (so will we > > send >=2.36) and rather than fail, send 2.35 instead (if the user didn't > > specifically specify a different version). However, we'd emit a warning > > saying this is deprecated and will go away in the first major client > > release (in Ocata? after nova-network is removed? after Ocata is > > released?). > > > > We should probably just deprecate any CLIs/APIs in python-novaclient > > today that are part of this server side API change, including network > > CLIs/APIs in novaclient. The baremetal and image proxies in the client > > are already deprecated, and the volume proxies were already removed. > > That leaves the network proxies in the client. > > > > From my notes, Dan Smith was going to work on the novaclient changes for > > 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to > > do that work (please speak up). > > > > We can probably do the network CLI/API deprecations in the client in > > parallel to the 2.36 support, but need someone to step up for that. I'll > > try to get it started this week if no one else does. > > > > [1] https://review.openstack.org/#/c/337005/ > > [2] https://etherpad.openstack.org/p/nova-newton-midcycle > > > > I forgot to mention Tempest. We're going to have to probably put a > max_microversion cap in several tests in Tempest to cap at 2.35 (or > change those to use Neutron?). There are also going to be some response > schema changes like for quota usage/limits, I'm not sure if anyone is > looking at this yet. We could also get it done after feature freeze on > 9/2, but I still need to land the get-me-a-network API change which is > microversion 2.37 and has it's own Tempest test, although that test > relies on Neutron so I might be OK for the most part. > If these tests are being used by DefCore, it would be better to cap the existing behavior and add new tests to use neutron instead of changing the existing tests. That will make it easier for DefCore to handle the transition from the old to new behavior by replacing the old tests in their list with the new ones. Doug __ 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] Next steps for proxy API deprecation
On Tue, Jul 26, 2016 at 01:21:53PM -0400, Sean Dague wrote: > On 07/26/2016 01:14 PM, Matt Riedemann wrote: > > On 7/26/2016 11:59 AM, Matt Riedemann wrote: > >> Now that the 2.36 microversion change has merged [1], we can work on the > >> python-novaclient changes for this microversion. > >> > >> At the midcycle we agreed [2] to also return a 404 for network APIs, > >> including nova-network (which isn't a proxy), for consistency and > >> further signaling that nova-network is going away. > >> > >> In the client, we agreed to soften the impact for network CLIs by > >> determining if the latest microversion supported will fail (so will we > >> send >=2.36) and rather than fail, send 2.35 instead (if the user didn't > >> specifically specify a different version). However, we'd emit a warning > >> saying this is deprecated and will go away in the first major client > >> release (in Ocata? after nova-network is removed? after Ocata is > >> released?). > >> > >> We should probably just deprecate any CLIs/APIs in python-novaclient > >> today that are part of this server side API change, including network > >> CLIs/APIs in novaclient. The baremetal and image proxies in the client > >> are already deprecated, and the volume proxies were already removed. > >> That leaves the network proxies in the client. > >> > >> From my notes, Dan Smith was going to work on the novaclient changes for > >> 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to > >> do that work (please speak up). > >> > >> We can probably do the network CLI/API deprecations in the client in > >> parallel to the 2.36 support, but need someone to step up for that. I'll > >> try to get it started this week if no one else does. > >> > >> [1] https://review.openstack.org/#/c/337005/ > >> [2] https://etherpad.openstack.org/p/nova-newton-midcycle > >> > > > > I forgot to mention Tempest. We're going to have to probably put a > > max_microversion cap in several tests in Tempest to cap at 2.35 (or > > change those to use Neutron?). There are also going to be some response > > schema changes like for quota usage/limits, I'm not sure if anyone is > > looking at this yet. We could also get it done after feature freeze on > > 9/2, but I still need to land the get-me-a-network API change which is > > microversion 2.37 and has it's own Tempest test, although that test > > relies on Neutron so I might be OK for the most part. > > Is that strictly true? We could also just configure all the jobs for > Nova network to set max microversion at 2.35. That would probably be > more straight forward way of approaching this, and make it a bit more > clear how serious we are here. > Yeah, for the gate that should work. By default tempest sends the minimum microversion based on the config and the test requirements. So we should never send 2.36 unless the test says it's minimum required microversion is >=2.36. Setting the max at 2.35 would mean we skip those tests. My bigger concern is for people using tempest outside of the gate. I still think we should set a max microversion on any test classes that call nova's network apis to make sure they're properly skipped just in case someone sets the min microversion in the tempest config at 2.36. (assuming such a test class exists at all, I don't actually know) Unless you thinking failing there is the correct way to do it? -Matt Treinish signature.asc Description: PGP signature __ 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] Next steps for proxy API deprecation
On Tue, Jul 26, 2016 at 12:14:03PM -0500, Matt Riedemann wrote: > On 7/26/2016 11:59 AM, Matt Riedemann wrote: > > Now that the 2.36 microversion change has merged [1], we can work on the > > python-novaclient changes for this microversion. > > > > At the midcycle we agreed [2] to also return a 404 for network APIs, > > including nova-network (which isn't a proxy), for consistency and > > further signaling that nova-network is going away. > > > > In the client, we agreed to soften the impact for network CLIs by > > determining if the latest microversion supported will fail (so will we > > send >=2.36) and rather than fail, send 2.35 instead (if the user didn't > > specifically specify a different version). However, we'd emit a warning > > saying this is deprecated and will go away in the first major client > > release (in Ocata? after nova-network is removed? after Ocata is > > released?). > > > > We should probably just deprecate any CLIs/APIs in python-novaclient > > today that are part of this server side API change, including network > > CLIs/APIs in novaclient. The baremetal and image proxies in the client > > are already deprecated, and the volume proxies were already removed. > > That leaves the network proxies in the client. > > > > From my notes, Dan Smith was going to work on the novaclient changes for > > 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to > > do that work (please speak up). > > > > We can probably do the network CLI/API deprecations in the client in > > parallel to the 2.36 support, but need someone to step up for that. I'll > > try to get it started this week if no one else does. > > > > [1] https://review.openstack.org/#/c/337005/ > > [2] https://etherpad.openstack.org/p/nova-newton-midcycle > > > > I forgot to mention Tempest. We're going to have to probably put a > max_microversion cap in several tests in Tempest to cap at 2.35 (or change > those to use Neutron?). There are also going to be some response schema > changes like for quota usage/limits, I'm not sure if anyone is looking at > this yet. We could also get it done after feature freeze on 9/2, but I still > need to land the get-me-a-network API change which is microversion 2.37 and > has it's own Tempest test, although that test relies on Neutron so I might > be OK for the most part. The only case where this will matter is for test classes that have an unbound max microversion, which should be very few. It's only classes that specify a higher minimum. The simple way around that is just change the max microversion for those classes to 2.35 and it won't ever send a 2.36 request. For example: http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/compute/volumes/test_attach_volume.py#n187 change 'latest' to 2.35 if it calls nova-network anywhere in that call path. (as an aside to people unfamiliar with microversions in tempest that doesn't mean send 'latest' on the wire but that all microversions are valid for this test, ie it won't skip based on the min microversion in config) However, this does raise a bigger issue about removing nova-network next cycle. It's still the default a lot of places. We can't remove the tempest support until newton eol (assuming an ocata removal) So we'll likely have to add a flag or 2 to make sure we never use it on master, there will also be devstack, devstack-gate, etc changes that will have to happen first too. But this is all probably a topic better suited for another thread or even a summit discussion. -Matt Treinish signature.asc Description: PGP signature __ 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] Next steps for proxy API deprecation
On 07/26/2016 01:14 PM, Matt Riedemann wrote: > On 7/26/2016 11:59 AM, Matt Riedemann wrote: >> Now that the 2.36 microversion change has merged [1], we can work on the >> python-novaclient changes for this microversion. >> >> At the midcycle we agreed [2] to also return a 404 for network APIs, >> including nova-network (which isn't a proxy), for consistency and >> further signaling that nova-network is going away. >> >> In the client, we agreed to soften the impact for network CLIs by >> determining if the latest microversion supported will fail (so will we >> send >=2.36) and rather than fail, send 2.35 instead (if the user didn't >> specifically specify a different version). However, we'd emit a warning >> saying this is deprecated and will go away in the first major client >> release (in Ocata? after nova-network is removed? after Ocata is >> released?). >> >> We should probably just deprecate any CLIs/APIs in python-novaclient >> today that are part of this server side API change, including network >> CLIs/APIs in novaclient. The baremetal and image proxies in the client >> are already deprecated, and the volume proxies were already removed. >> That leaves the network proxies in the client. >> >> From my notes, Dan Smith was going to work on the novaclient changes for >> 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to >> do that work (please speak up). >> >> We can probably do the network CLI/API deprecations in the client in >> parallel to the 2.36 support, but need someone to step up for that. I'll >> try to get it started this week if no one else does. >> >> [1] https://review.openstack.org/#/c/337005/ >> [2] https://etherpad.openstack.org/p/nova-newton-midcycle >> > > I forgot to mention Tempest. We're going to have to probably put a > max_microversion cap in several tests in Tempest to cap at 2.35 (or > change those to use Neutron?). There are also going to be some response > schema changes like for quota usage/limits, I'm not sure if anyone is > looking at this yet. We could also get it done after feature freeze on > 9/2, but I still need to land the get-me-a-network API change which is > microversion 2.37 and has it's own Tempest test, although that test > relies on Neutron so I might be OK for the most part. Is that strictly true? We could also just configure all the jobs for Nova network to set max microversion at 2.35. That would probably be more straight forward way of approaching this, and make it a bit more clear how serious we are here. -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] Next steps for proxy API deprecation
On 7/26/2016 11:59 AM, Matt Riedemann wrote: Now that the 2.36 microversion change has merged [1], we can work on the python-novaclient changes for this microversion. At the midcycle we agreed [2] to also return a 404 for network APIs, including nova-network (which isn't a proxy), for consistency and further signaling that nova-network is going away. In the client, we agreed to soften the impact for network CLIs by determining if the latest microversion supported will fail (so will we send >=2.36) and rather than fail, send 2.35 instead (if the user didn't specifically specify a different version). However, we'd emit a warning saying this is deprecated and will go away in the first major client release (in Ocata? after nova-network is removed? after Ocata is released?). We should probably just deprecate any CLIs/APIs in python-novaclient today that are part of this server side API change, including network CLIs/APIs in novaclient. The baremetal and image proxies in the client are already deprecated, and the volume proxies were already removed. That leaves the network proxies in the client. From my notes, Dan Smith was going to work on the novaclient changes for 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to do that work (please speak up). We can probably do the network CLI/API deprecations in the client in parallel to the 2.36 support, but need someone to step up for that. I'll try to get it started this week if no one else does. [1] https://review.openstack.org/#/c/337005/ [2] https://etherpad.openstack.org/p/nova-newton-midcycle I forgot to mention Tempest. We're going to have to probably put a max_microversion cap in several tests in Tempest to cap at 2.35 (or change those to use Neutron?). There are also going to be some response schema changes like for quota usage/limits, I'm not sure if anyone is looking at this yet. We could also get it done after feature freeze on 9/2, but I still need to land the get-me-a-network API change which is microversion 2.37 and has it's own Tempest test, although that test relies on Neutron so I might be OK for the most part. -- Thanks, Matt Riedemann __ 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] Next steps for proxy API deprecation
Now that the 2.36 microversion change has merged [1], we can work on the python-novaclient changes for this microversion. At the midcycle we agreed [2] to also return a 404 for network APIs, including nova-network (which isn't a proxy), for consistency and further signaling that nova-network is going away. In the client, we agreed to soften the impact for network CLIs by determining if the latest microversion supported will fail (so will we send >=2.36) and rather than fail, send 2.35 instead (if the user didn't specifically specify a different version). However, we'd emit a warning saying this is deprecated and will go away in the first major client release (in Ocata? after nova-network is removed? after Ocata is released?). We should probably just deprecate any CLIs/APIs in python-novaclient today that are part of this server side API change, including network CLIs/APIs in novaclient. The baremetal and image proxies in the client are already deprecated, and the volume proxies were already removed. That leaves the network proxies in the client. From my notes, Dan Smith was going to work on the novaclient changes for 2.36 to not fail and use 2.35 - unless anyone else wants to volunteer to do that work (please speak up). We can probably do the network CLI/API deprecations in the client in parallel to the 2.36 support, but need someone to step up for that. I'll try to get it started this week if no one else does. [1] https://review.openstack.org/#/c/337005/ [2] https://etherpad.openstack.org/p/nova-newton-midcycle -- Thanks, Matt Riedemann __ 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
