Re: [openstack-dev] [nova] release request for python-novaclient
On Feb 19, 2015, at 13:38, Terry Wilson wrote: > We've currently just disabled the pylint gate tests, and I've posted a patch > for neutron to resolve the issue. Looks like there was a similar patch > already up for review as well, though it only catches one of our uses of > novaclient. There's still a bit of an issue that there is no version-neutral > way to import the 'contrib' stuff like there is for 'client'. So: > > from novaclient.v1_1.contrib import server_external_events > > has to become > > from novaclient.v2.contrib import server_external_events > > which doesn't work on previous versions of novaclient. It's possible to hack > around it using importutils, but it's pretty ugly. Thanks, Terry. I'm glad you brought up the lack of version-neutral way to import 'contrib' modules. That's something we'll look to improve. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ 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] release request for python-novaclient
Neutron should not depend on versioning implementation in novaclient. There is get_contrib_module function in https://review.openstack.org/#/c/152569/9/novaclient/client.py , which should help to renounce the use of direct import of versioning stuff of novaclient, but now, imo, we should use workaround like https://review.openstack.org/#/c/152907/ On Fri, Feb 20, 2015 at 12:38 AM, Terry Wilson wrote: > > > - Original Message - > > On Feb 19, 2015, at 11:52, Terry Wilson wrote: > > > > > Unfortunately, the new novaclient release ended up completely breaking > the > > > neutron gate. The v1_1 deprecation broke our (voting) pylint test: > > > https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console > > > > > > 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m > > > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > > > (no-name-in-module) > > > 2015-02-19 18:37:06.932 | No name 'contrib' in module > > > 'novaclient.v1_1'(no-name-in-module) > > > 2015-02-19 18:37:06.932 | Module > neutron.plugins.cisco.l3.service_vm_lib > > > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > > > (no-name-in-module) > > > > Hi Terry, > > > > Sorry to hear about this. I looked into this and the problem is pylint > can't > > parse the backward-compatibility we have for the v1_1 deprecation: > > > > > https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm > > > > The actual code should work but pylint static checking will fail to > follow > > it. So far, the options I see to handle it are to either patch > > s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific > pylint > > check that's failing (if it's not too broad). > > > > Do you find either of these options acceptable, or have another idea? > > We've currently just disabled the pylint gate tests, and I've posted a > patch for neutron to resolve the issue. Looks like there was a similar > patch already up for review as well, though it only catches one of our uses > of novaclient. There's still a bit of an issue that there is no > version-neutral way to import the 'contrib' stuff like there is for > 'client'. So: > > from novaclient.v1_1.contrib import server_external_events > > has to become > > from novaclient.v2.contrib import server_external_events > > which doesn't work on previous versions of novaclient. It's possible to > hack around it using importutils, but it's pretty ugly. > > Terry > > __ > 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] release request for python-novaclient
- Original Message - > On Feb 19, 2015, at 11:52, Terry Wilson wrote: > > > Unfortunately, the new novaclient release ended up completely breaking the > > neutron gate. The v1_1 deprecation broke our (voting) pylint test: > > https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console > > > > 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m > > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > > (no-name-in-module) > > 2015-02-19 18:37:06.932 | No name 'contrib' in module > > 'novaclient.v1_1'(no-name-in-module) > > 2015-02-19 18:37:06.932 | Module neutron.plugins.cisco.l3.service_vm_lib > > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > > (no-name-in-module) > > Hi Terry, > > Sorry to hear about this. I looked into this and the problem is pylint can't > parse the backward-compatibility we have for the v1_1 deprecation: > > https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm > > The actual code should work but pylint static checking will fail to follow > it. So far, the options I see to handle it are to either patch > s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific pylint > check that's failing (if it's not too broad). > > Do you find either of these options acceptable, or have another idea? We've currently just disabled the pylint gate tests, and I've posted a patch for neutron to resolve the issue. Looks like there was a similar patch already up for review as well, though it only catches one of our uses of novaclient. There's still a bit of an issue that there is no version-neutral way to import the 'contrib' stuff like there is for 'client'. So: from novaclient.v1_1.contrib import server_external_events has to become from novaclient.v2.contrib import server_external_events which doesn't work on previous versions of novaclient. It's possible to hack around it using importutils, but it's pretty ugly. Terry __ 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] release request for python-novaclient
On Feb 19, 2015, at 12:48, Dan Smith wrote: > Either convince neutron pylint not to care, or just convert the > uses in neutron to v2. In pylint, E0611 is the check which could be disabled to ignore this case. http://pylint-messages.wikidot.com/messages:e0611 melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ 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] release request for python-novaclient
> I can do another release if needed once we've landed a fix, although > it sounds like this can be fixed in neutron? It's just pylint being silly, from the sound of it. I don't think there is anything we need to do in novaclient, since the transition adapter works. Either convince neutron pylint not to care, or just convert the uses in neutron to v2. --Dan signature.asc Description: OpenPGP digital 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] release request for python-novaclient
I can do another release if needed once we've landed a fix, although it sounds like this can be fixed in neutron? Michael On Fri, Feb 20, 2015 at 7:33 AM, melanie witt wrote: > On Feb 19, 2015, at 11:52, Terry Wilson wrote: > >> Unfortunately, the new novaclient release ended up completely breaking the >> neutron gate. The v1_1 deprecation broke our (voting) pylint test: >> https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console >> >> 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova [0m >> 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' ( >> no-name-in-module) >> 2015-02-19 18:37:06.932 | No name 'contrib' in module 'novaclient.v1_1' >> (no-name-in-module ) >> 2015-02-19 18:37:06.932 | Module neutron.plugins.cisco.l3.service_vm_lib >> 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' ( >> no-name-in-module ) > > Hi Terry, > > Sorry to hear about this. I looked into this and the problem is pylint can't > parse the backward-compatibility we have for the v1_1 deprecation: > > https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm > > The actual code should work but pylint static checking will fail to follow > it. So far, the options I see to handle it are to either patch > s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific pylint > check that's failing (if it's not too broad). > > Do you find either of these options acceptable, or have another idea? > > Thanks, > melanie (melwitt) > > > > > > __ > 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 > -- Rackspace Australia __ 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] release request for python-novaclient
On Feb 19, 2015, at 11:52, Terry Wilson wrote: > Unfortunately, the new novaclient release ended up completely breaking the > neutron gate. The v1_1 deprecation broke our (voting) pylint test: > https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console > > 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > (no-name-in-module) > 2015-02-19 18:37:06.932 | No name 'contrib' in module > 'novaclient.v1_1'(no-name-in-module) > 2015-02-19 18:37:06.932 | Module neutron.plugins.cisco.l3.service_vm_lib > 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' > (no-name-in-module) Hi Terry, Sorry to hear about this. I looked into this and the problem is pylint can't parse the backward-compatibility we have for the v1_1 deprecation: https://review.openstack.org/#/c/149006/13/novaclient/v1_1/__init__.py,cm The actual code should work but pylint static checking will fail to follow it. So far, the options I see to handle it are to either patch s/novaclient.v1_1/novaclient.v2/ in neutron or suppress the specific pylint check that's failing (if it's not too broad). Do you find either of these options acceptable, or have another idea? Thanks, melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ 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] release request for python-novaclient
> Sorry, I dropped the ball here. This is now released. Unfortunately, the new novaclient release ended up completely breaking the neutron gate. The v1_1 deprecation broke our (voting) pylint test: https://jenkins04.openstack.org/job/gate-neutron-pylint/1383/console 2015-02-19 18:37:06.932 | Module neutron.notifiers.nova[0m 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' (no-name-in-module) 2015-02-19 18:37:06.932 | No name 'contrib' in module 'novaclient.v1_1'(no-name-in-module) 2015-02-19 18:37:06.932 | Module neutron.plugins.cisco.l3.service_vm_lib 2015-02-19 18:37:06.932 | No name 'client' in module 'novaclient.v1_1' (no-name-in-module) Terry __ 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] release request for python-novaclient
Sorry, I dropped the ball here. This is now released. As promised last week in the nova meeting I've checked the docs on the wiki for releases (https://wiki.openstack.org/wiki/Nova/Client_Release_Process) and fixed some small errors. I'll look at adding John Garbutt and Matt Riedemann to the novaclient release group now. Michael On Fri, Feb 20, 2015 at 2:12 AM, Matt Riedemann wrote: > > > On 2/12/2015 6:55 PM, Michael Still wrote: >> >> This was discussed in the nova meeting this morning. In that meeting >> we declared ourselves unwedged and ready to do a release, and I said >> I'd do that today. >> >> On reflection, I want to recant just a little -- I think its a bad >> idea for me to do a release on a Friday. So, I'll do this early next >> week instead. >> >> Michael >> >> On Wed, Feb 11, 2015 at 8:51 AM, Joe Gordon wrote: >>> >>> >>> >>> On Mon, Feb 9, 2015 at 7:55 PM, Michael Still wrote: The previous policy is that we do a release "when requested" or when a critical bug fix merges. I don't see any critical fixes awaiting release, but I am not opposed to a release. The reason I didn't do this yesterday is that Joe wanted some time to pin the stable requirements, which I believe he is still working on. Let's give him some time unless this is urgent. >>> >>> So to move this forward, lets just pin novaclient on stable branches. so >>> the >>> longer term pin all the reqs isn't blocking this. >>> >>> Icehouse already has a cap, so we just need to wait for the juno cap to >>> land: >>> >>> https://review.openstack.org/154680 >>> >>> Michael On Tue, Feb 10, 2015 at 2:45 PM, melanie witt wrote: > > On Feb 6, 2015, at 8:17, Matt Riedemann > wrote: > >> We haven't done a release of python-novaclient in awhile (2.20.0 was >> released on 2014-9-20 before the Juno release). >> >> It looks like there are some important feature adds and bug fixes on >> master so we should do a release, specifically to pick up the change >> for >> keystone v3 support [1]. >> >> So can this be done now or should this wait until closer to the Kilo >> release (library releases are cheap so I don't see why we'd wait). > > > Thanks for bringing this up -- there are indeed a lot of important > features and fixes on master. > > I agree we should do a release as soon as possible, and I don't think > there's any reason to wait until closer to Kilo. > > melanie (melwitt) > > > > > > > > __ > 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 > -- Rackspace Australia __ 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 >>> >> >> >> > > This was ready to go as of Monday. Can we really only have the PTL do this > release? As far as I know, any core on python-novaclient should be able to > do this if they have a GPG key to launchpad, then they just need to push the > tagged release per [1]. There is some launchpad bug cleanup and blueprint > stuff to handle which is done in scripts somewhere [2], so maybe that's what > holds this up? > > [1] http://docs.openstack.org/infra/manual/drivers.html#tagging-a-release > [2] https://wiki.openstack.org/wiki/ReleaseTeam/How_To_Release > > -- > > 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 -- Rackspace Australia __ 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] release request for python-novaclient
Matt Riedemann wrote: > This was ready to go as of Monday. Can we really only have the PTL do > this release? As far as I know, any core on python-novaclient should be > able to do this if they have a GPG key to launchpad, then they just need > to push the tagged release per [1]. The way python-novaclient is set up in gerrit, only nova-release can push tags: https://review.openstack.org/#/admin/projects/openstack/python-novaclient,access Current membership is: https://review.openstack.org/#/admin/groups/147,members -- Thierry Carrez (ttx) __ 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] release request for python-novaclient
On 2/12/2015 6:55 PM, Michael Still wrote: This was discussed in the nova meeting this morning. In that meeting we declared ourselves unwedged and ready to do a release, and I said I'd do that today. On reflection, I want to recant just a little -- I think its a bad idea for me to do a release on a Friday. So, I'll do this early next week instead. Michael On Wed, Feb 11, 2015 at 8:51 AM, Joe Gordon wrote: On Mon, Feb 9, 2015 at 7:55 PM, Michael Still wrote: The previous policy is that we do a release "when requested" or when a critical bug fix merges. I don't see any critical fixes awaiting release, but I am not opposed to a release. The reason I didn't do this yesterday is that Joe wanted some time to pin the stable requirements, which I believe he is still working on. Let's give him some time unless this is urgent. So to move this forward, lets just pin novaclient on stable branches. so the longer term pin all the reqs isn't blocking this. Icehouse already has a cap, so we just need to wait for the juno cap to land: https://review.openstack.org/154680 Michael On Tue, Feb 10, 2015 at 2:45 PM, melanie witt wrote: On Feb 6, 2015, at 8:17, Matt Riedemann wrote: We haven't done a release of python-novaclient in awhile (2.20.0 was released on 2014-9-20 before the Juno release). It looks like there are some important feature adds and bug fixes on master so we should do a release, specifically to pick up the change for keystone v3 support [1]. So can this be done now or should this wait until closer to the Kilo release (library releases are cheap so I don't see why we'd wait). Thanks for bringing this up -- there are indeed a lot of important features and fixes on master. I agree we should do a release as soon as possible, and I don't think there's any reason to wait until closer to Kilo. melanie (melwitt) __ 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 -- Rackspace Australia __ 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 This was ready to go as of Monday. Can we really only have the PTL do this release? As far as I know, any core on python-novaclient should be able to do this if they have a GPG key to launchpad, then they just need to push the tagged release per [1]. There is some launchpad bug cleanup and blueprint stuff to handle which is done in scripts somewhere [2], so maybe that's what holds this up? [1] http://docs.openstack.org/infra/manual/drivers.html#tagging-a-release [2] https://wiki.openstack.org/wiki/ReleaseTeam/How_To_Release -- 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] release request for python-novaclient
This was discussed in the nova meeting this morning. In that meeting we declared ourselves unwedged and ready to do a release, and I said I'd do that today. On reflection, I want to recant just a little -- I think its a bad idea for me to do a release on a Friday. So, I'll do this early next week instead. Michael On Wed, Feb 11, 2015 at 8:51 AM, Joe Gordon wrote: > > > On Mon, Feb 9, 2015 at 7:55 PM, Michael Still wrote: >> >> The previous policy is that we do a release "when requested" or when a >> critical bug fix merges. I don't see any critical fixes awaiting >> release, but I am not opposed to a release. >> >> The reason I didn't do this yesterday is that Joe wanted some time to >> pin the stable requirements, which I believe he is still working on. >> Let's give him some time unless this is urgent. >> > > So to move this forward, lets just pin novaclient on stable branches. so the > longer term pin all the reqs isn't blocking this. > > Icehouse already has a cap, so we just need to wait for the juno cap to > land: > > https://review.openstack.org/154680 > > >> >> Michael >> >> On Tue, Feb 10, 2015 at 2:45 PM, melanie witt wrote: >> > On Feb 6, 2015, at 8:17, Matt Riedemann >> > wrote: >> > >> >> We haven't done a release of python-novaclient in awhile (2.20.0 was >> >> released on 2014-9-20 before the Juno release). >> >> >> >> It looks like there are some important feature adds and bug fixes on >> >> master so we should do a release, specifically to pick up the change for >> >> keystone v3 support [1]. >> >> >> >> So can this be done now or should this wait until closer to the Kilo >> >> release (library releases are cheap so I don't see why we'd wait). >> > >> > Thanks for bringing this up -- there are indeed a lot of important >> > features and fixes on master. >> > >> > I agree we should do a release as soon as possible, and I don't think >> > there's any reason to wait until closer to Kilo. >> > >> > melanie (melwitt) >> > >> > >> > >> > >> > >> > >> > __ >> > 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 >> > >> >> >> >> -- >> Rackspace Australia >> >> __ >> 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 > -- Rackspace Australia __ 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] release request for python-novaclient
On Mon, Feb 9, 2015 at 7:55 PM, Michael Still wrote: > The previous policy is that we do a release "when requested" or when a > critical bug fix merges. I don't see any critical fixes awaiting > release, but I am not opposed to a release. > > The reason I didn't do this yesterday is that Joe wanted some time to > pin the stable requirements, which I believe he is still working on. > Let's give him some time unless this is urgent. > > So to move this forward, lets just pin novaclient on stable branches. so the longer term pin all the reqs isn't blocking this. Icehouse already has a cap, so we just need to wait for the juno cap to land: https://review.openstack.org/154680 > Michael > > On Tue, Feb 10, 2015 at 2:45 PM, melanie witt wrote: > > On Feb 6, 2015, at 8:17, Matt Riedemann > wrote: > > > >> We haven't done a release of python-novaclient in awhile (2.20.0 was > released on 2014-9-20 before the Juno release). > >> > >> It looks like there are some important feature adds and bug fixes on > master so we should do a release, specifically to pick up the change for > keystone v3 support [1]. > >> > >> So can this be done now or should this wait until closer to the Kilo > release (library releases are cheap so I don't see why we'd wait). > > > > Thanks for bringing this up -- there are indeed a lot of important > features and fixes on master. > > > > I agree we should do a release as soon as possible, and I don't think > there's any reason to wait until closer to Kilo. > > > > melanie (melwitt) > > > > > > > > > > > > > __ > > 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 > > > > > > -- > Rackspace Australia > > __ > 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] release request for python-novaclient
On Tue, Feb 10, 2015 at 9:19 AM, Doug Hellmann wrote: > > > On Tue, Feb 10, 2015, at 07:25 AM, Sean Dague wrote: > > On 02/09/2015 10:55 PM, Michael Still wrote: > > > The previous policy is that we do a release "when requested" or when a > > > critical bug fix merges. I don't see any critical fixes awaiting > > > release, but I am not opposed to a release. > > > > > > The reason I didn't do this yesterday is that Joe wanted some time to > > > pin the stable requirements, which I believe he is still working on. > > > Let's give him some time unless this is urgent. > > > > Going forward I'd suggest that we set a goal to do a monthly nova-client > > release to get fixes out into the wild in a more regular cadence. Would > > be nice to not have this just land as a big bang release at the end of a > > cycle. > > We review the changes in Oslo libraries weekly. Is there any reason not > to do the same with client libs? Given the automation in place for > creating releases, I think the whole process (including release notes) > is down to just a few minutes now. The tagging script is in the > openstack-infra/release-tools repository and I'd be happy to put the > release notes script there, too, if others want to use it. > > ++, I'd love to see that script land there Doug! And I agree, doing this releases is fairly straightforward now, so perhaps they should occur with a more regular cadence. Thanks, Kyle > Doug > > > > > -Sean > > > > > > > > Michael > > > > > > On Tue, Feb 10, 2015 at 2:45 PM, melanie witt > wrote: > > >> On Feb 6, 2015, at 8:17, Matt Riedemann > wrote: > > >> > > >>> We haven't done a release of python-novaclient in awhile (2.20.0 was > released on 2014-9-20 before the Juno release). > > >>> > > >>> It looks like there are some important feature adds and bug fixes on > master so we should do a release, specifically to pick up the change for > keystone v3 support [1]. > > >>> > > >>> So can this be done now or should this wait until closer to the Kilo > release (library releases are cheap so I don't see why we'd wait). > > >> > > >> Thanks for bringing this up -- there are indeed a lot of important > features and fixes on master. > > >> > > >> I agree we should do a release as soon as possible, and I don't think > there's any reason to wait until closer to Kilo. > > >> > > >> melanie (melwitt) > > >> > > >> > > >> > > >> > > >> > > >> > __ > > >> 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 > > >> > > > > > > > > > > > > > > > -- > > 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] release request for python-novaclient
On Tue, Feb 10, 2015, at 07:25 AM, Sean Dague wrote: > On 02/09/2015 10:55 PM, Michael Still wrote: > > The previous policy is that we do a release "when requested" or when a > > critical bug fix merges. I don't see any critical fixes awaiting > > release, but I am not opposed to a release. > > > > The reason I didn't do this yesterday is that Joe wanted some time to > > pin the stable requirements, which I believe he is still working on. > > Let's give him some time unless this is urgent. > > Going forward I'd suggest that we set a goal to do a monthly nova-client > release to get fixes out into the wild in a more regular cadence. Would > be nice to not have this just land as a big bang release at the end of a > cycle. We review the changes in Oslo libraries weekly. Is there any reason not to do the same with client libs? Given the automation in place for creating releases, I think the whole process (including release notes) is down to just a few minutes now. The tagging script is in the openstack-infra/release-tools repository and I'd be happy to put the release notes script there, too, if others want to use it. Doug > > -Sean > > > > > Michael > > > > On Tue, Feb 10, 2015 at 2:45 PM, melanie witt wrote: > >> On Feb 6, 2015, at 8:17, Matt Riedemann wrote: > >> > >>> We haven't done a release of python-novaclient in awhile (2.20.0 was > >>> released on 2014-9-20 before the Juno release). > >>> > >>> It looks like there are some important feature adds and bug fixes on > >>> master so we should do a release, specifically to pick up the change for > >>> keystone v3 support [1]. > >>> > >>> So can this be done now or should this wait until closer to the Kilo > >>> release (library releases are cheap so I don't see why we'd wait). > >> > >> Thanks for bringing this up -- there are indeed a lot of important > >> features and fixes on master. > >> > >> I agree we should do a release as soon as possible, and I don't think > >> there's any reason to wait until closer to Kilo. > >> > >> melanie (melwitt) > >> > >> > >> > >> > >> > >> __ > >> 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 > >> > > > > > > > > > -- > 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] release request for python-novaclient
On 02/09/2015 10:55 PM, Michael Still wrote: > The previous policy is that we do a release "when requested" or when a > critical bug fix merges. I don't see any critical fixes awaiting > release, but I am not opposed to a release. > > The reason I didn't do this yesterday is that Joe wanted some time to > pin the stable requirements, which I believe he is still working on. > Let's give him some time unless this is urgent. Going forward I'd suggest that we set a goal to do a monthly nova-client release to get fixes out into the wild in a more regular cadence. Would be nice to not have this just land as a big bang release at the end of a cycle. -Sean > > Michael > > On Tue, Feb 10, 2015 at 2:45 PM, melanie witt wrote: >> On Feb 6, 2015, at 8:17, Matt Riedemann wrote: >> >>> We haven't done a release of python-novaclient in awhile (2.20.0 was >>> released on 2014-9-20 before the Juno release). >>> >>> It looks like there are some important feature adds and bug fixes on master >>> so we should do a release, specifically to pick up the change for keystone >>> v3 support [1]. >>> >>> So can this be done now or should this wait until closer to the Kilo >>> release (library releases are cheap so I don't see why we'd wait). >> >> Thanks for bringing this up -- there are indeed a lot of important features >> and fixes on master. >> >> I agree we should do a release as soon as possible, and I don't think >> there's any reason to wait until closer to Kilo. >> >> melanie (melwitt) >> >> >> >> >> >> __ >> 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 >> > > > -- 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] release request for python-novaclient
On 2/9/2015 9:55 PM, Michael Still wrote: The previous policy is that we do a release "when requested" or when a critical bug fix merges. I don't see any critical fixes awaiting release, but I am not opposed to a release. The reason I didn't do this yesterday is that Joe wanted some time to pin the stable requirements, which I believe he is still working on. Let's give him some time unless this is urgent. Michael On Tue, Feb 10, 2015 at 2:45 PM, melanie witt wrote: On Feb 6, 2015, at 8:17, Matt Riedemann wrote: We haven't done a release of python-novaclient in awhile (2.20.0 was released on 2014-9-20 before the Juno release). It looks like there are some important feature adds and bug fixes on master so we should do a release, specifically to pick up the change for keystone v3 support [1]. So can this be done now or should this wait until closer to the Kilo release (library releases are cheap so I don't see why we'd wait). Thanks for bringing this up -- there are indeed a lot of important features and fixes on master. I agree we should do a release as soon as possible, and I don't think there's any reason to wait until closer to Kilo. melanie (melwitt) __ 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 Yeah we need to hold off to cap requirements on stable first, which is currently blocked by stable being busted in other ways [1]. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-February/056353.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
Re: [openstack-dev] [nova] release request for python-novaclient
On Feb 9, 2015, at 19:55, Michael Still wrote: > The previous policy is that we do a release "when requested" or when a > critical bug fix merges. I don't see any critical fixes awaiting > release, but I am not opposed to a release. That's right. I think the keystone v3 support is important and worth putting out there. > The reason I didn't do this yesterday is that Joe wanted some time to > pin the stable requirements, which I believe he is still working on. > Let's give him some time unless this is urgent. Yes, of course. I should have been clearer. I meant after that's done, we should do a release. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ 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] release request for python-novaclient
The previous policy is that we do a release "when requested" or when a critical bug fix merges. I don't see any critical fixes awaiting release, but I am not opposed to a release. The reason I didn't do this yesterday is that Joe wanted some time to pin the stable requirements, which I believe he is still working on. Let's give him some time unless this is urgent. Michael On Tue, Feb 10, 2015 at 2:45 PM, melanie witt wrote: > On Feb 6, 2015, at 8:17, Matt Riedemann wrote: > >> We haven't done a release of python-novaclient in awhile (2.20.0 was >> released on 2014-9-20 before the Juno release). >> >> It looks like there are some important feature adds and bug fixes on master >> so we should do a release, specifically to pick up the change for keystone >> v3 support [1]. >> >> So can this be done now or should this wait until closer to the Kilo release >> (library releases are cheap so I don't see why we'd wait). > > Thanks for bringing this up -- there are indeed a lot of important features > and fixes on master. > > I agree we should do a release as soon as possible, and I don't think there's > any reason to wait until closer to Kilo. > > melanie (melwitt) > > > > > > __ > 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 > -- Rackspace Australia __ 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] release request for python-novaclient
On Feb 6, 2015, at 8:17, Matt Riedemann wrote: > We haven't done a release of python-novaclient in awhile (2.20.0 was released > on 2014-9-20 before the Juno release). > > It looks like there are some important feature adds and bug fixes on master > so we should do a release, specifically to pick up the change for keystone v3 > support [1]. > > So can this be done now or should this wait until closer to the Kilo release > (library releases are cheap so I don't see why we'd wait). Thanks for bringing this up -- there are indeed a lot of important features and fixes on master. I agree we should do a release as soon as possible, and I don't think there's any reason to wait until closer to Kilo. melanie (melwitt) signature.asc Description: Message signed with OpenPGP using GPGMail __ 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] release request for python-novaclient
Before releasing a new python-novaclient we should make sure novaclient is capped on stable branches so we don't break the world yet again. On Fri, Feb 6, 2015 at 8:17 AM, Matt Riedemann wrote: > We haven't done a release of python-novaclient in awhile (2.20.0 was > released on 2014-9-20 before the Juno release). > > It looks like there are some important feature adds and bug fixes on > master so we should do a release, specifically to pick up the change for > keystone v3 support [1]. > > So can this be done now or should this wait until closer to the Kilo > release (library releases are cheap so I don't see why we'd wait). > > [1] https://review.openstack.org/#/c/105900/ > > -- > > 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
