On Feb 19, 2015, at 11:52, Terry Wilson twil...@redhat.com 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
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 |
Imo, neutron has wrong usage of novaclient.
https://review.openstack.org/#/c/152907/ should fix this issue.
On Thursday, February 19, 2015, Terry Wilson twil...@redhat.com
javascript:_e(%7B%7D,'cvml','twil...@redhat.com'); wrote:
Sorry, I dropped the ball here. This is now released.
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 melwi...@gmail.com wrote:
On Feb 19, 2015, at 11:52, Terry Wilson twil...@redhat.com wrote:
Unfortunately, the new 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
On Feb 19, 2015, at 12:48, Dan Smith d...@danplanet.com 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)
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
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
- Original Message -
On Feb 19, 2015, at 11:52, Terry Wilson twil...@redhat.com wrote:
Unfortunately, the new novaclient release ended up completely breaking the
neutron gate. The v1_1 deprecation broke our (voting) pylint test:
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
On Feb 19, 2015, at 13:38, Terry Wilson twil...@redhat.com 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
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
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
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
On Mon, Feb 9, 2015 at 7:55 PM, Michael Still mi...@stillhq.com 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
On Tue, Feb 10, 2015 at 9:19 AM, Doug Hellmann d...@doughellmann.com
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
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
On Feb 6, 2015, at 8:17, Matt Riedemann mrie...@linux.vnet.ibm.com 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
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
On Feb 9, 2015, at 19:55, Michael Still mi...@stillhq.com 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
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
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 mrie...@linux.vnet.ibm.com
wrote:
We haven't done a release of python-novaclient in awhile (2.20.0 was
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
23 matches
Mail list logo