Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
On 3/9/2016 8:54 AM, Amrith Kumar wrote: Matt, As I understand it, you have 4 changes up for review. Change [1] seeks to revert the change [6] to python-troveclient on master and reinstate the slave_of parameter. Change [2] is doing for stable/liberty, the same things that were done for master in [9] on master, and [7] on Kilo earlier. Change [3] is looking to blacklist python-troveclient 2.1.0 on stable/liberty. Change [4] is looking to bump the minimum python-troveclient version on master to 2.1.0. Right, and there was actually another for that beat me to this: https://review.openstack.org/#/c/290115/ Here are three questions I have: (1) Wouldn't backward compatibility also require that you revert the other change that removed slave_of on the server [5] ? After all, just like a python client that calls create() with slave_of, a REST client could call the endpoint with slave_of. What is the policy for REST API backward compatibility? I guess it depends on the Trove team. In Nova, backward compatibility in the API is serious business and that's why we have left all sorts of warts in the v2.0 API and couldn't remove them. But with the v2.1 API and microversions, we're able to move the API forward (Ironic also has microversions, and I think cinder/neutron/keystone are working on adding that support). So if maintaining backward compatibility in the trove API is important to the trove team and it's users, then yes the API change should probably be reverted. For anyone doing CD with Trove, they are already broken, but people upgrading from liberty to mitaka could save themselves the break. (2) Wouldn't [4] just block 2.1.0 in global-requirements on master (mitaka)? I'm not sure I understand, [4] here bumps the minimum required version of python-troveclient to be 2.1.0, not block it. As noted in the review, I don't know that it's really necessary to bump to 2.1.0 iff we land and release [1]. (3) Something, potentially your patch set [2], should also fix the test that is invoking create() with slave_of, no? [2] is stable/liberty which still has slave_of in the create API, so I don't think that needs to be fixed in stable/liberty. -amrith [1] https://review.openstack.org/290048/ [2] https://review.openstack.org/290023/ [3] https://review.openstack.org/290021/ [4] https://review.openstack.org/290168/ [5] https://review.openstack.org/#/c/245845/ [6] https://review.openstack.org/#/c/245738/ [7] https://review.openstack.org/#/c/246735/ On 03/08/2016 08:24 PM, Matt Riedemann wrote: On 3/8/2016 4:44 PM, Matt Riedemann wrote: On 3/8/2016 3:17 PM, Matt Riedemann wrote: On 3/8/2016 1:18 PM, Amrith Kumar wrote: Matt, See inline below. -amrith -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, March 08, 2016 2:00 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506 On 3/8/2016 12:52 PM, Matt Riedemann wrote: On 3/8/2016 12:35 PM, Amrith Kumar wrote: Matt, The correct solution for liberty is that we should fix the tests. Here's why I believe that this is the case. In pertinent part, the backtrace from your bug includes: 2016-01-27 07:02:06.777 | File "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/ api/replication.py", line 83, in create_slave 2016-01-27 07:02:06.777 | slave_of=instance_info.id) This is in the tests, not the client. The test is now generating a parameter that the client no longer understands. For a user, here are the various situations that could occur. 1. User running python-troveclient from the latest 2.1.0 and a server from liberty. All is good. 2. User running an old python-troveclient and a server from liberty. All is good. Will this work with python-troveclient 1.2.0 which is the minimum required troveclient for stable/liberty? https://github.com/openstack/requirements/blob/stable/liberty/global-r equirements.txt#L174 3. User running an old python-troveclient and a new server from mitaka, this is not supported. How is this not supported? If it's not supported, the minimum required version of troveclient in master g-r is wrong, since it hasn't changed since liberty: https://github.com/openstack/requirements/blob/master/global-requireme nts.txt#L202 I've confirmed that running master (mitaka) unit tests for trove against python-troveclient 1.2.0 don't work: http://paste.openstack.org/show/489719/ [amrith] Just like the bug you listed, this appears to be a case of a broken test. Would you please LP it. 4. User running a current python-troveclient from the latest 2.1.0 and a server from mitaka, All is good. What you have here is a case where a test is generating an argument (slave_of) that the client (master, 2.1.0)
Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
Matt, As I understand it, you have 4 changes up for review. Change [1] seeks to revert the change [6] to python-troveclient on master and reinstate the slave_of parameter. Change [2] is doing for stable/liberty, the same things that were done for master in [9] on master, and [7] on Kilo earlier. Change [3] is looking to blacklist python-troveclient 2.1.0 on stable/liberty. Change [4] is looking to bump the minimum python-troveclient version on master to 2.1.0. Here are three questions I have: (1) Wouldn't backward compatibility also require that you revert the other change that removed slave_of on the server [5] ? After all, just like a python client that calls create() with slave_of, a REST client could call the endpoint with slave_of. What is the policy for REST API backward compatibility? (2) Wouldn't [4] just block 2.1.0 in global-requirements on master (mitaka)? (3) Something, potentially your patch set [2], should also fix the test that is invoking create() with slave_of, no? -amrith [1] https://review.openstack.org/290048/ [2] https://review.openstack.org/290023/ [3] https://review.openstack.org/290021/ [4] https://review.openstack.org/290168/ [5] https://review.openstack.org/#/c/245845/ [6] https://review.openstack.org/#/c/245738/ [7] https://review.openstack.org/#/c/246735/ On 03/08/2016 08:24 PM, Matt Riedemann wrote: > > > On 3/8/2016 4:44 PM, Matt Riedemann wrote: >> >> >> On 3/8/2016 3:17 PM, Matt Riedemann wrote: >>> >>> >>> On 3/8/2016 1:18 PM, Amrith Kumar wrote: >>>> Matt, >>>> >>>> See inline below. >>>> >>>> -amrith >>>> >>>>> -Original Message- >>>>> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] >>>>> Sent: Tuesday, March 08, 2016 2:00 PM >>>>> To: openstack-dev@lists.openstack.org >>>>> Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly >>>>> failing in stable branches; bug 1538506 >>>>> >>>>> >>>>> >>>>> On 3/8/2016 12:52 PM, Matt Riedemann wrote: >>>>>> >>>>>> >>>>>> On 3/8/2016 12:35 PM, Amrith Kumar wrote: >>>>>>> Matt, >>>>>>> >>>>>>> The correct solution for liberty is that we should fix the tests. >>>>>>> Here's why I believe that this is the case. >>>>>>> >>>>>>> In pertinent part, the backtrace from your bug includes: >>>>>>> >>>>>>> 2016-01-27 07:02:06.777 | File >>>>>>> "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/ >>>>>>> >>>>>>> api/replication.py", >>>>>>> line 83, in create_slave >>>>>>> 2016-01-27 07:02:06.777 | slave_of=instance_info.id) >>>>>>> >>>>>>> This is in the tests, not the client. >>>>>>> >>>>>>> The test is now generating a parameter that the client no longer >>>>>>> understands. >>>>>>> >>>>>>> For a user, here are the various situations that could occur. >>>>>>> >>>>>>> 1. User running python-troveclient from the latest 2.1.0 and a >>>>>>> server >>>>>>> from liberty. All is good. >>>>>>> 2. User running an old python-troveclient and a server from >>>>>>> liberty. >>>>>>> All is good. >>>>>> >>>>>> Will this work with python-troveclient 1.2.0 which is the minimum >>>>>> required troveclient for stable/liberty? >>>>>> >>>>>> https://github.com/openstack/requirements/blob/stable/liberty/global-r >>>>>> >>>>>> equirements.txt#L174 >>>>>> >>>>>> >>>>>>> 3. User running an old python-troveclient and a new server from >>>>>>> mitaka, this is not supported. >>>>>> >>>>>> How is this not supported? If it's not supported, the minimum >>>>>> required version of troveclient in master g-r is wrong, since it >>>>>> hasn't changed since liberty: >>>>>> >>>>>> https://github.com/openstack/requirements/blob/master/global-requireme >>>>>> >>>>>> nts.txt#L202 >>>>> >>>>> I'
Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
On 3/8/2016 4:44 PM, Matt Riedemann wrote: On 3/8/2016 3:17 PM, Matt Riedemann wrote: On 3/8/2016 1:18 PM, Amrith Kumar wrote: Matt, See inline below. -amrith -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, March 08, 2016 2:00 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506 On 3/8/2016 12:52 PM, Matt Riedemann wrote: On 3/8/2016 12:35 PM, Amrith Kumar wrote: Matt, The correct solution for liberty is that we should fix the tests. Here's why I believe that this is the case. In pertinent part, the backtrace from your bug includes: 2016-01-27 07:02:06.777 | File "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/ api/replication.py", line 83, in create_slave 2016-01-27 07:02:06.777 | slave_of=instance_info.id) This is in the tests, not the client. The test is now generating a parameter that the client no longer understands. For a user, here are the various situations that could occur. 1. User running python-troveclient from the latest 2.1.0 and a server from liberty. All is good. 2. User running an old python-troveclient and a server from liberty. All is good. Will this work with python-troveclient 1.2.0 which is the minimum required troveclient for stable/liberty? https://github.com/openstack/requirements/blob/stable/liberty/global-r equirements.txt#L174 3. User running an old python-troveclient and a new server from mitaka, this is not supported. How is this not supported? If it's not supported, the minimum required version of troveclient in master g-r is wrong, since it hasn't changed since liberty: https://github.com/openstack/requirements/blob/master/global-requireme nts.txt#L202 I've confirmed that running master (mitaka) unit tests for trove against python-troveclient 1.2.0 don't work: http://paste.openstack.org/show/489719/ [amrith] Just like the bug you listed, this appears to be a case of a broken test. Would you please LP it. 4. User running a current python-troveclient from the latest 2.1.0 and a server from mitaka, All is good. What you have here is a case where a test is generating an argument (slave_of) that the client (master, 2.1.0) no longer understands. There's nothing amiss there, except that the test needs to be fixed. When you get back, let's continue the conversation either in email or IRC #openstack-dev. Looking forward to hearing your feedback on this. Thanks, -amrith -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, March 08, 2016 12:11 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506 On 3/8/2016 10:17 AM, Matt Riedemann wrote: This is a call for help on resolving bug 1538506 [1] where the proboscis tests randomly fail on the stable branches with something like: TypeError: create() got an unexpected keyword argument 'slave_of' Craig Vyvial has a proposed stable/kilo change [2] but it has some issues, at least from me as a reviewer of that change. The tests are failing the periodic-stable job daily [3]. Can we get someone to help out with this? Otherwise I'm inclined to say the tests should be disabled on the stable branches, but that's pretty drastic. Note that this is the kind of thing that breaks stable branch policy, which is going to be part of a review when applying for the stable:follows-policy tag. [4] And the stable:follows-policy tag may be used to determine when a stable branch for a project goes end of life if it's not being maintained. [1] https://bugs.launchpad.net/trove/+bug/1538506 [2] https://review.openstack.org/#/c/276934/ [3] http://goo.gl/fqf11U [4] http://governance.openstack.org/reference/tags/stable_follows-polic y.h tml This is my solution for liberty, cap python-troveclient<2.1.0 in global- requirements on stable/liberty [1]. Then there is a change to trove on stable/liberty to use the g-r version range for python-troveclient for unit tests [2]. Alternatively, we could avoid the cap in stable/liberty by: 1. Reverting https://review.openstack.org/#/c/245738/ 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python- troveclient 2.2.0. It's getting late in the mitaka release to be messing with this though since we're already past client freeze. [1] https://review.openstack.org/#/c/290021/ [2] https://review.openstack.org/#/c/290023/ -- 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] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
On 3/8/2016 3:17 PM, Matt Riedemann wrote: On 3/8/2016 1:18 PM, Amrith Kumar wrote: Matt, See inline below. -amrith -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, March 08, 2016 2:00 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506 On 3/8/2016 12:52 PM, Matt Riedemann wrote: On 3/8/2016 12:35 PM, Amrith Kumar wrote: Matt, The correct solution for liberty is that we should fix the tests. Here's why I believe that this is the case. In pertinent part, the backtrace from your bug includes: 2016-01-27 07:02:06.777 | File "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/ api/replication.py", line 83, in create_slave 2016-01-27 07:02:06.777 | slave_of=instance_info.id) This is in the tests, not the client. The test is now generating a parameter that the client no longer understands. For a user, here are the various situations that could occur. 1. User running python-troveclient from the latest 2.1.0 and a server from liberty. All is good. 2. User running an old python-troveclient and a server from liberty. All is good. Will this work with python-troveclient 1.2.0 which is the minimum required troveclient for stable/liberty? https://github.com/openstack/requirements/blob/stable/liberty/global-r equirements.txt#L174 3. User running an old python-troveclient and a new server from mitaka, this is not supported. How is this not supported? If it's not supported, the minimum required version of troveclient in master g-r is wrong, since it hasn't changed since liberty: https://github.com/openstack/requirements/blob/master/global-requireme nts.txt#L202 I've confirmed that running master (mitaka) unit tests for trove against python-troveclient 1.2.0 don't work: http://paste.openstack.org/show/489719/ [amrith] Just like the bug you listed, this appears to be a case of a broken test. Would you please LP it. 4. User running a current python-troveclient from the latest 2.1.0 and a server from mitaka, All is good. What you have here is a case where a test is generating an argument (slave_of) that the client (master, 2.1.0) no longer understands. There's nothing amiss there, except that the test needs to be fixed. When you get back, let's continue the conversation either in email or IRC #openstack-dev. Looking forward to hearing your feedback on this. Thanks, -amrith -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, March 08, 2016 12:11 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506 On 3/8/2016 10:17 AM, Matt Riedemann wrote: This is a call for help on resolving bug 1538506 [1] where the proboscis tests randomly fail on the stable branches with something like: TypeError: create() got an unexpected keyword argument 'slave_of' Craig Vyvial has a proposed stable/kilo change [2] but it has some issues, at least from me as a reviewer of that change. The tests are failing the periodic-stable job daily [3]. Can we get someone to help out with this? Otherwise I'm inclined to say the tests should be disabled on the stable branches, but that's pretty drastic. Note that this is the kind of thing that breaks stable branch policy, which is going to be part of a review when applying for the stable:follows-policy tag. [4] And the stable:follows-policy tag may be used to determine when a stable branch for a project goes end of life if it's not being maintained. [1] https://bugs.launchpad.net/trove/+bug/1538506 [2] https://review.openstack.org/#/c/276934/ [3] http://goo.gl/fqf11U [4] http://governance.openstack.org/reference/tags/stable_follows-polic y.h tml This is my solution for liberty, cap python-troveclient<2.1.0 in global- requirements on stable/liberty [1]. Then there is a change to trove on stable/liberty to use the g-r version range for python-troveclient for unit tests [2]. Alternatively, we could avoid the cap in stable/liberty by: 1. Reverting https://review.openstack.org/#/c/245738/ 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python- troveclient 2.2.0. It's getting late in the mitaka release to be messing with this though since we're already past client freeze. [1] https://review.openstack.org/#/c/290021/ [2] https://review.openstack.org/#/c/290023/ -- 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
Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
On 3/8/2016 1:18 PM, Amrith Kumar wrote: Matt, See inline below. -amrith -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, March 08, 2016 2:00 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506 On 3/8/2016 12:52 PM, Matt Riedemann wrote: On 3/8/2016 12:35 PM, Amrith Kumar wrote: Matt, The correct solution for liberty is that we should fix the tests. Here's why I believe that this is the case. In pertinent part, the backtrace from your bug includes: 2016-01-27 07:02:06.777 | File "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/ api/replication.py", line 83, in create_slave 2016-01-27 07:02:06.777 | slave_of=instance_info.id) This is in the tests, not the client. The test is now generating a parameter that the client no longer understands. For a user, here are the various situations that could occur. 1. User running python-troveclient from the latest 2.1.0 and a server from liberty. All is good. 2. User running an old python-troveclient and a server from liberty. All is good. Will this work with python-troveclient 1.2.0 which is the minimum required troveclient for stable/liberty? https://github.com/openstack/requirements/blob/stable/liberty/global-r equirements.txt#L174 3. User running an old python-troveclient and a new server from mitaka, this is not supported. How is this not supported? If it's not supported, the minimum required version of troveclient in master g-r is wrong, since it hasn't changed since liberty: https://github.com/openstack/requirements/blob/master/global-requireme nts.txt#L202 I've confirmed that running master (mitaka) unit tests for trove against python-troveclient 1.2.0 don't work: http://paste.openstack.org/show/489719/ [amrith] Just like the bug you listed, this appears to be a case of a broken test. Would you please LP it. 4. User running a current python-troveclient from the latest 2.1.0 and a server from mitaka, All is good. What you have here is a case where a test is generating an argument (slave_of) that the client (master, 2.1.0) no longer understands. There's nothing amiss there, except that the test needs to be fixed. When you get back, let's continue the conversation either in email or IRC #openstack-dev. Looking forward to hearing your feedback on this. Thanks, -amrith -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, March 08, 2016 12:11 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506 On 3/8/2016 10:17 AM, Matt Riedemann wrote: This is a call for help on resolving bug 1538506 [1] where the proboscis tests randomly fail on the stable branches with something like: TypeError: create() got an unexpected keyword argument 'slave_of' Craig Vyvial has a proposed stable/kilo change [2] but it has some issues, at least from me as a reviewer of that change. The tests are failing the periodic-stable job daily [3]. Can we get someone to help out with this? Otherwise I'm inclined to say the tests should be disabled on the stable branches, but that's pretty drastic. Note that this is the kind of thing that breaks stable branch policy, which is going to be part of a review when applying for the stable:follows-policy tag. [4] And the stable:follows-policy tag may be used to determine when a stable branch for a project goes end of life if it's not being maintained. [1] https://bugs.launchpad.net/trove/+bug/1538506 [2] https://review.openstack.org/#/c/276934/ [3] http://goo.gl/fqf11U [4] http://governance.openstack.org/reference/tags/stable_follows-polic y.h tml This is my solution for liberty, cap python-troveclient<2.1.0 in global- requirements on stable/liberty [1]. Then there is a change to trove on stable/liberty to use the g-r version range for python-troveclient for unit tests [2]. Alternatively, we could avoid the cap in stable/liberty by: 1. Reverting https://review.openstack.org/#/c/245738/ 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python- troveclient 2.2.0. It's getting late in the mitaka release to be messing with this though since we're already past client freeze. [1] https://review.openstack.org/#/c/290021/ [2] https://review.openstack.org/#/c/290023/ -- 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 Development Mailing List (not for usage qu
Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
Matt, See inline below. -amrith > -Original Message- > From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > Sent: Tuesday, March 08, 2016 2:00 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly > failing in stable branches; bug 1538506 > > > > On 3/8/2016 12:52 PM, Matt Riedemann wrote: > > > > > > On 3/8/2016 12:35 PM, Amrith Kumar wrote: > >> Matt, > >> > >> The correct solution for liberty is that we should fix the tests. > >> Here's why I believe that this is the case. > >> > >> In pertinent part, the backtrace from your bug includes: > >> > >> 2016-01-27 07:02:06.777 | File > >> "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/ > >> api/replication.py", > >> line 83, in create_slave > >> 2016-01-27 07:02:06.777 | slave_of=instance_info.id) > >> > >> This is in the tests, not the client. > >> > >> The test is now generating a parameter that the client no longer > >> understands. > >> > >> For a user, here are the various situations that could occur. > >> > >> 1. User running python-troveclient from the latest 2.1.0 and a server > >> from liberty. All is good. > >> 2. User running an old python-troveclient and a server from liberty. > >> All is good. > > > > Will this work with python-troveclient 1.2.0 which is the minimum > > required troveclient for stable/liberty? > > > > https://github.com/openstack/requirements/blob/stable/liberty/global-r > > equirements.txt#L174 > > > > > >> 3. User running an old python-troveclient and a new server from > >> mitaka, this is not supported. > > > > How is this not supported? If it's not supported, the minimum > > required version of troveclient in master g-r is wrong, since it > > hasn't changed since liberty: > > > > https://github.com/openstack/requirements/blob/master/global-requireme > > nts.txt#L202 > > I've confirmed that running master (mitaka) unit tests for trove against > python-troveclient 1.2.0 don't work: > > http://paste.openstack.org/show/489719/ [amrith] Just like the bug you listed, this appears to be a case of a broken test. Would you please LP it. > > > > > > >> 4. User running a current python-troveclient from the latest 2.1.0 > >> and a server from mitaka, All is good. > >> > >> What you have here is a case where a test is generating an argument > >> (slave_of) that the client (master, 2.1.0) no longer understands. > >> There's nothing amiss there, except that the test needs to be fixed. > >> > >> When you get back, let's continue the conversation either in email or > >> IRC #openstack-dev. Looking forward to hearing your feedback on this. > >> > >> Thanks, > >> > >> -amrith > >> > >> > >>> -Original Message- > >>> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > >>> Sent: Tuesday, March 08, 2016 12:11 PM > >>> To: openstack-dev@lists.openstack.org > >>> Subject: Re: [openstack-dev] [trove][stable] proboscis tests > >>> randomly failing in stable branches; bug 1538506 > >>> > >>> > >>> > >>> On 3/8/2016 10:17 AM, Matt Riedemann wrote: > >>>> This is a call for help on resolving bug 1538506 [1] where the > >>>> proboscis tests randomly fail on the stable branches with something > >>> like: > >>>> > >>>> TypeError: create() got an unexpected keyword argument 'slave_of' > >>>> > >>>> Craig Vyvial has a proposed stable/kilo change [2] but it has some > >>>> issues, at least from me as a reviewer of that change. > >>>> > >>>> The tests are failing the periodic-stable job daily [3]. > >>>> > >>>> Can we get someone to help out with this? Otherwise I'm inclined to > >>>> say the tests should be disabled on the stable branches, but that's > >>>> pretty drastic. > >>>> > >>>> Note that this is the kind of thing that breaks stable branch > >>>> policy, which is going to be part of a review when applying for the > >>>> stable:follows-policy tag. [4] And the stable:follows-policy tag > >>>> may be used to determine when a stable branch for
Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
See below. > -Original Message- > From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > Sent: Tuesday, March 08, 2016 1:53 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly > failing in stable branches; bug 1538506 > > > > On 3/8/2016 12:35 PM, Amrith Kumar wrote: > > Matt, > > > > The correct solution for liberty is that we should fix the tests. Here's > why I believe that this is the case. > > > > In pertinent part, the backtrace from your bug includes: > > > > 2016-01-27 07:02:06.777 | File > > "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/a > > pi/replication.py", line 83, in create_slave > > 2016-01-27 07:02:06.777 | slave_of=instance_info.id) > > > > This is in the tests, not the client. > > > > The test is now generating a parameter that the client no longer > understands. > > > > For a user, here are the various situations that could occur. > > > > 1. User running python-troveclient from the latest 2.1.0 and a server > from liberty. All is good. > > 2. User running an old python-troveclient and a server from liberty. All > is good. > > Will this work with python-troveclient 1.2.0 which is the minimum required > troveclient for stable/liberty? > > https://github.com/openstack/requirements/blob/stable/liberty/global- > requirements.txt#L174 [amrith] Yes, the server understands replica_of. > > > 3. User running an old python-troveclient and a new server from mitaka, > this is not supported. > > How is this not supported? If it's not supported, the minimum required > version of troveclient in master g-r is wrong, since it hasn't changed > since liberty: > > https://github.com/openstack/requirements/blob/master/global- > requirements.txt#L202 [amrith] My mistake, this specific issue won't cause a problem there. It'll work. > > > 4. User running a current python-troveclient from the latest 2.1.0 and a > server from mitaka, All is good. > > > > What you have here is a case where a test is generating an argument > (slave_of) that the client (master, 2.1.0) no longer understands. There's > nothing amiss there, except that the test needs to be fixed. > > > > When you get back, let's continue the conversation either in email or > IRC #openstack-dev. Looking forward to hearing your feedback on this. > > > > Thanks, > > > > -amrith > > > > > >> -Original Message- > >> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > >> Sent: Tuesday, March 08, 2016 12:11 PM > >> To: openstack-dev@lists.openstack.org > >> Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly > >> failing in stable branches; bug 1538506 > >> > >> > >> > >> On 3/8/2016 10:17 AM, Matt Riedemann wrote: > >>> This is a call for help on resolving bug 1538506 [1] where the > >>> proboscis tests randomly fail on the stable branches with something > >> like: > >>> > >>> TypeError: create() got an unexpected keyword argument 'slave_of' > >>> > >>> Craig Vyvial has a proposed stable/kilo change [2] but it has some > >>> issues, at least from me as a reviewer of that change. > >>> > >>> The tests are failing the periodic-stable job daily [3]. > >>> > >>> Can we get someone to help out with this? Otherwise I'm inclined to > >>> say the tests should be disabled on the stable branches, but that's > >>> pretty drastic. > >>> > >>> Note that this is the kind of thing that breaks stable branch > >>> policy, which is going to be part of a review when applying for the > >>> stable:follows-policy tag. [4] And the stable:follows-policy tag > >>> may be used to determine when a stable branch for a project goes end > >>> of life if it's not being maintained. > >>> > >>> [1] https://bugs.launchpad.net/trove/+bug/1538506 > >>> [2] https://review.openstack.org/#/c/276934/ > >>> [3] http://goo.gl/fqf11U > >>> [4] > >>> http://governance.openstack.org/reference/tags/stable_follows-policy > >>> .h > >>> tml > >>> > >> > >> This is my solution for liberty, cap python-troveclient<2.1.0 in > >> global- requirements on stable/liberty [1]. > >> > >> Then there is a change to trove on stable/liberty to u
Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
On 3/8/2016 12:52 PM, Matt Riedemann wrote: On 3/8/2016 12:35 PM, Amrith Kumar wrote: Matt, The correct solution for liberty is that we should fix the tests. Here's why I believe that this is the case. In pertinent part, the backtrace from your bug includes: 2016-01-27 07:02:06.777 | File "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/api/replication.py", line 83, in create_slave 2016-01-27 07:02:06.777 | slave_of=instance_info.id) This is in the tests, not the client. The test is now generating a parameter that the client no longer understands. For a user, here are the various situations that could occur. 1. User running python-troveclient from the latest 2.1.0 and a server from liberty. All is good. 2. User running an old python-troveclient and a server from liberty. All is good. Will this work with python-troveclient 1.2.0 which is the minimum required troveclient for stable/liberty? https://github.com/openstack/requirements/blob/stable/liberty/global-requirements.txt#L174 3. User running an old python-troveclient and a new server from mitaka, this is not supported. How is this not supported? If it's not supported, the minimum required version of troveclient in master g-r is wrong, since it hasn't changed since liberty: https://github.com/openstack/requirements/blob/master/global-requirements.txt#L202 I've confirmed that running master (mitaka) unit tests for trove against python-troveclient 1.2.0 don't work: http://paste.openstack.org/show/489719/ 4. User running a current python-troveclient from the latest 2.1.0 and a server from mitaka, All is good. What you have here is a case where a test is generating an argument (slave_of) that the client (master, 2.1.0) no longer understands. There's nothing amiss there, except that the test needs to be fixed. When you get back, let's continue the conversation either in email or IRC #openstack-dev. Looking forward to hearing your feedback on this. Thanks, -amrith -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, March 08, 2016 12:11 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506 On 3/8/2016 10:17 AM, Matt Riedemann wrote: This is a call for help on resolving bug 1538506 [1] where the proboscis tests randomly fail on the stable branches with something like: TypeError: create() got an unexpected keyword argument 'slave_of' Craig Vyvial has a proposed stable/kilo change [2] but it has some issues, at least from me as a reviewer of that change. The tests are failing the periodic-stable job daily [3]. Can we get someone to help out with this? Otherwise I'm inclined to say the tests should be disabled on the stable branches, but that's pretty drastic. Note that this is the kind of thing that breaks stable branch policy, which is going to be part of a review when applying for the stable:follows-policy tag. [4] And the stable:follows-policy tag may be used to determine when a stable branch for a project goes end of life if it's not being maintained. [1] https://bugs.launchpad.net/trove/+bug/1538506 [2] https://review.openstack.org/#/c/276934/ [3] http://goo.gl/fqf11U [4] http://governance.openstack.org/reference/tags/stable_follows-policy.h tml This is my solution for liberty, cap python-troveclient<2.1.0 in global- requirements on stable/liberty [1]. Then there is a change to trove on stable/liberty to use the g-r version range for python-troveclient for unit tests [2]. Alternatively, we could avoid the cap in stable/liberty by: 1. Reverting https://review.openstack.org/#/c/245738/ 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python- troveclient 2.2.0. It's getting late in the mitaka release to be messing with this though since we're already past client freeze. [1] https://review.openstack.org/#/c/290021/ [2] https://review.openstack.org/#/c/290023/ -- 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 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] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
On 3/8/2016 12:35 PM, Amrith Kumar wrote: Matt, The correct solution for liberty is that we should fix the tests. Here's why I believe that this is the case. In pertinent part, the backtrace from your bug includes: 2016-01-27 07:02:06.777 | File "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/api/replication.py", line 83, in create_slave 2016-01-27 07:02:06.777 | slave_of=instance_info.id) This is in the tests, not the client. The test is now generating a parameter that the client no longer understands. For a user, here are the various situations that could occur. 1. User running python-troveclient from the latest 2.1.0 and a server from liberty. All is good. 2. User running an old python-troveclient and a server from liberty. All is good. Will this work with python-troveclient 1.2.0 which is the minimum required troveclient for stable/liberty? https://github.com/openstack/requirements/blob/stable/liberty/global-requirements.txt#L174 3. User running an old python-troveclient and a new server from mitaka, this is not supported. How is this not supported? If it's not supported, the minimum required version of troveclient in master g-r is wrong, since it hasn't changed since liberty: https://github.com/openstack/requirements/blob/master/global-requirements.txt#L202 4. User running a current python-troveclient from the latest 2.1.0 and a server from mitaka, All is good. What you have here is a case where a test is generating an argument (slave_of) that the client (master, 2.1.0) no longer understands. There's nothing amiss there, except that the test needs to be fixed. When you get back, let's continue the conversation either in email or IRC #openstack-dev. Looking forward to hearing your feedback on this. Thanks, -amrith -Original Message- From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] Sent: Tuesday, March 08, 2016 12:11 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506 On 3/8/2016 10:17 AM, Matt Riedemann wrote: This is a call for help on resolving bug 1538506 [1] where the proboscis tests randomly fail on the stable branches with something like: TypeError: create() got an unexpected keyword argument 'slave_of' Craig Vyvial has a proposed stable/kilo change [2] but it has some issues, at least from me as a reviewer of that change. The tests are failing the periodic-stable job daily [3]. Can we get someone to help out with this? Otherwise I'm inclined to say the tests should be disabled on the stable branches, but that's pretty drastic. Note that this is the kind of thing that breaks stable branch policy, which is going to be part of a review when applying for the stable:follows-policy tag. [4] And the stable:follows-policy tag may be used to determine when a stable branch for a project goes end of life if it's not being maintained. [1] https://bugs.launchpad.net/trove/+bug/1538506 [2] https://review.openstack.org/#/c/276934/ [3] http://goo.gl/fqf11U [4] http://governance.openstack.org/reference/tags/stable_follows-policy.h tml This is my solution for liberty, cap python-troveclient<2.1.0 in global- requirements on stable/liberty [1]. Then there is a change to trove on stable/liberty to use the g-r version range for python-troveclient for unit tests [2]. Alternatively, we could avoid the cap in stable/liberty by: 1. Reverting https://review.openstack.org/#/c/245738/ 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python- troveclient 2.2.0. It's getting late in the mitaka release to be messing with this though since we're already past client freeze. [1] https://review.openstack.org/#/c/290021/ [2] https://review.openstack.org/#/c/290023/ -- 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 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] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
Matt, The correct solution for liberty is that we should fix the tests. Here's why I believe that this is the case. In pertinent part, the backtrace from your bug includes: 2016-01-27 07:02:06.777 | File "/home/jenkins/workspace/periodic-trove-python27-liberty/trove/tests/api/replication.py", line 83, in create_slave 2016-01-27 07:02:06.777 | slave_of=instance_info.id) This is in the tests, not the client. The test is now generating a parameter that the client no longer understands. For a user, here are the various situations that could occur. 1. User running python-troveclient from the latest 2.1.0 and a server from liberty. All is good. 2. User running an old python-troveclient and a server from liberty. All is good. 3. User running an old python-troveclient and a new server from mitaka, this is not supported. 4. User running a current python-troveclient from the latest 2.1.0 and a server from mitaka, All is good. What you have here is a case where a test is generating an argument (slave_of) that the client (master, 2.1.0) no longer understands. There's nothing amiss there, except that the test needs to be fixed. When you get back, let's continue the conversation either in email or IRC #openstack-dev. Looking forward to hearing your feedback on this. Thanks, -amrith > -Original Message- > From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > Sent: Tuesday, March 08, 2016 12:11 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly > failing in stable branches; bug 1538506 > > > > On 3/8/2016 10:17 AM, Matt Riedemann wrote: > > This is a call for help on resolving bug 1538506 [1] where the > > proboscis tests randomly fail on the stable branches with something > like: > > > > TypeError: create() got an unexpected keyword argument 'slave_of' > > > > Craig Vyvial has a proposed stable/kilo change [2] but it has some > > issues, at least from me as a reviewer of that change. > > > > The tests are failing the periodic-stable job daily [3]. > > > > Can we get someone to help out with this? Otherwise I'm inclined to > > say the tests should be disabled on the stable branches, but that's > > pretty drastic. > > > > Note that this is the kind of thing that breaks stable branch policy, > > which is going to be part of a review when applying for the > > stable:follows-policy tag. [4] And the stable:follows-policy tag may > > be used to determine when a stable branch for a project goes end of > > life if it's not being maintained. > > > > [1] https://bugs.launchpad.net/trove/+bug/1538506 > > [2] https://review.openstack.org/#/c/276934/ > > [3] http://goo.gl/fqf11U > > [4] > > http://governance.openstack.org/reference/tags/stable_follows-policy.h > > tml > > > > This is my solution for liberty, cap python-troveclient<2.1.0 in global- > requirements on stable/liberty [1]. > > Then there is a change to trove on stable/liberty to use the g-r version > range for python-troveclient for unit tests [2]. > > Alternatively, we could avoid the cap in stable/liberty by: > > 1. Reverting https://review.openstack.org/#/c/245738/ > 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python- > troveclient 2.2.0. > > It's getting late in the mitaka release to be messing with this though > since we're already past client freeze. > > [1] https://review.openstack.org/#/c/290021/ > [2] https://review.openstack.org/#/c/290023/ > > -- > > 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 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] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
Matt, As I just said in my earlier reply to you, Craig has been away for some time and I'll look into this. I don't know that we need to revert the change or take the route you propose. There may be a much simpler solution. I'll propose a change for your review. -amrith > -Original Message- > From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > Sent: Tuesday, March 08, 2016 12:11 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [trove][stable] proboscis tests randomly > failing in stable branches; bug 1538506 > > > > On 3/8/2016 10:17 AM, Matt Riedemann wrote: > > This is a call for help on resolving bug 1538506 [1] where the > > proboscis tests randomly fail on the stable branches with something > like: > > > > TypeError: create() got an unexpected keyword argument 'slave_of' > > > > Craig Vyvial has a proposed stable/kilo change [2] but it has some > > issues, at least from me as a reviewer of that change. > > > > The tests are failing the periodic-stable job daily [3]. > > > > Can we get someone to help out with this? Otherwise I'm inclined to > > say the tests should be disabled on the stable branches, but that's > > pretty drastic. > > > > Note that this is the kind of thing that breaks stable branch policy, > > which is going to be part of a review when applying for the > > stable:follows-policy tag. [4] And the stable:follows-policy tag may > > be used to determine when a stable branch for a project goes end of > > life if it's not being maintained. > > > > [1] https://bugs.launchpad.net/trove/+bug/1538506 > > [2] https://review.openstack.org/#/c/276934/ > > [3] http://goo.gl/fqf11U > > [4] > > http://governance.openstack.org/reference/tags/stable_follows-policy.h > > tml > > > > This is my solution for liberty, cap python-troveclient<2.1.0 in global- > requirements on stable/liberty [1]. > > Then there is a change to trove on stable/liberty to use the g-r version > range for python-troveclient for unit tests [2]. > > Alternatively, we could avoid the cap in stable/liberty by: > > 1. Reverting https://review.openstack.org/#/c/245738/ > 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python- > troveclient 2.2.0. > > It's getting late in the mitaka release to be messing with this though > since we're already past client freeze. > > [1] https://review.openstack.org/#/c/290021/ > [2] https://review.openstack.org/#/c/290023/ > > -- > > 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 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] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
On 3/8/2016 10:17 AM, Matt Riedemann wrote: This is a call for help on resolving bug 1538506 [1] where the proboscis tests randomly fail on the stable branches with something like: TypeError: create() got an unexpected keyword argument 'slave_of' Craig Vyvial has a proposed stable/kilo change [2] but it has some issues, at least from me as a reviewer of that change. The tests are failing the periodic-stable job daily [3]. Can we get someone to help out with this? Otherwise I'm inclined to say the tests should be disabled on the stable branches, but that's pretty drastic. Note that this is the kind of thing that breaks stable branch policy, which is going to be part of a review when applying for the stable:follows-policy tag. [4] And the stable:follows-policy tag may be used to determine when a stable branch for a project goes end of life if it's not being maintained. [1] https://bugs.launchpad.net/trove/+bug/1538506 [2] https://review.openstack.org/#/c/276934/ [3] http://goo.gl/fqf11U [4] http://governance.openstack.org/reference/tags/stable_follows-policy.html This is my solution for liberty, cap python-troveclient<2.1.0 in global-requirements on stable/liberty [1]. Then there is a change to trove on stable/liberty to use the g-r version range for python-troveclient for unit tests [2]. Alternatively, we could avoid the cap in stable/liberty by: 1. Reverting https://review.openstack.org/#/c/245738/ 2. Blacklisting python-troveclient 2.1.0 in g-r 3. Release python-troveclient 2.2.0. It's getting late in the mitaka release to be messing with this though since we're already past client freeze. [1] https://review.openstack.org/#/c/290021/ [2] https://review.openstack.org/#/c/290023/ -- 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] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506
This is a call for help on resolving bug 1538506 [1] where the proboscis tests randomly fail on the stable branches with something like: TypeError: create() got an unexpected keyword argument 'slave_of' Craig Vyvial has a proposed stable/kilo change [2] but it has some issues, at least from me as a reviewer of that change. The tests are failing the periodic-stable job daily [3]. Can we get someone to help out with this? Otherwise I'm inclined to say the tests should be disabled on the stable branches, but that's pretty drastic. Note that this is the kind of thing that breaks stable branch policy, which is going to be part of a review when applying for the stable:follows-policy tag. [4] And the stable:follows-policy tag may be used to determine when a stable branch for a project goes end of life if it's not being maintained. [1] https://bugs.launchpad.net/trove/+bug/1538506 [2] https://review.openstack.org/#/c/276934/ [3] http://goo.gl/fqf11U [4] http://governance.openstack.org/reference/tags/stable_follows-policy.html -- 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
