Re: [openstack-dev] stable/havana jobs failing due to keystone bug 1357652

2014-08-17 Thread Alan Pevec
2014-08-17 18:30 GMT+02:00 Nathan Kinder nkin...@redhat.com: This requirement change was backported for stable/icehouse: https://review.openstack.org/#/c/112337/ It seems like the right thing to do is to propose a similar change for stable/havana instead of reverting the keystoneclient

Re: [openstack-dev] [Openstack-stable-maint] [all][oslo] official recommendations to handle oslo-incubator sync requests

2014-08-21 Thread Alan Pevec
2. For stable branches, the process is a bit different. For those branches, we don't generally want to introduce changes that are not related to specific issues in a project. So in case of backports, we tend to do per-patch consideration when synchronizing from incubator. I'd call this

Re: [openstack-dev] [Openstack-stable-maint] [Neutron][stable] How to backport database schema fixes

2014-08-29 Thread Alan Pevec
It seems that currently it's hard to backport any database schema fix to Neutron [1] which uses alembic to manage db schema version. Nova has the same issue before and a workaround is to put some placeholder files before each release. So first do we allow db schema fixes to be backport to

[openstack-dev] [all] Stable Havana 2013.2.4 preparation

2014-09-05 Thread Alan Pevec
Hi all, as planned[1] stable-maint team is going to prepare the final stable Havana release 2013.2.4, now that Juno-3 was released. Proposed release date is Sep 18, with the code freeze on stable/havana branches week before on Sep 11. Stable-maint members: please review open backports [2] taking

Re: [openstack-dev] Please do *NOT* use vendorized versions of anything (here: glanceclient using requests.packages.urllib3)

2014-09-18 Thread Alan Pevec
2014-09-17 17:15 GMT+02:00 Thomas Goirand z...@debian.org: File bla/tests/test_ssl.py, line 19, in module from requests.packages.urllib3 import poolmanager ImportError: No module named packages.urllib3 This is in tests only, in runtime code there is conditional import of vendorized

Re: [openstack-dev] [Openstack-dev] [Nova] Updated Feature in Next Havana release 2013.2.2

2014-01-23 Thread Alan Pevec
2014/1/21 cosmos cosmos cosmos0...@gmail.com: But now i am wondering about start/stop and shelve/unshelve function. Because the function on boot from image(creates a new volume) is not working. That's not enough information, have you tried to find in Launchpad bug(s) which would match the

Re: [openstack-dev] [nova] [stable] stevedore 0.14

2014-01-28 Thread Alan Pevec
2014-01-27 Doug Hellmann doug.hellm...@dreamhost.com: I have just released a new version of stevedore, 0.14, which includes a change to stop checking version numbers of dependencies for plugins. This should eliminate one class of problems we've seen where we get conflicting requirements to

Re: [openstack-dev] [nova] [stable] stevedore 0.14

2014-01-28 Thread Alan Pevec
... or fix the tests on stable/* ? That would be: https://review.openstack.org/#/q/I5063c652c705fd512f90ff3897a4c590f7ba7c02,n,z and is already proposed for Havana. Sean, please submit it for stable/grizzly too. Thanks, Alan ___ OpenStack-dev mailing

Re: [openstack-dev] [Openstack-stable-maint] Stable gate status?

2014-02-04 Thread Alan Pevec
2014-02-04 Mark McClain mmccl...@yahoo-inc.com: On Feb 3, 2014, at 8:27 PM, Alan Pevec ape...@gmail.com wrote: Hi Sean and Anita, what is your opinion about the state of stable/havana gate? If you think it's not stable enough to return back patches which were pulled out, I'd have

Re: [openstack-dev] [Openstack-stable-maint] Stable gate status?

2014-02-04 Thread Alan Pevec
2014-02-04 Doug Hellmann doug.hellm...@dreamhost.com: Do we have a list of those somewhere? Pulled out where following Neutron patches (IMHO all innocent for gate breaking): https://review.openstack.org/62206 https://review.openstack.org/67214 https://review.openstack.org/70232 I'm

Re: [openstack-dev] [Openstack-stable-maint] Stable gate status?

2014-02-11 Thread Alan Pevec
Hi Mark and Anita, could we declare stable/havana neutron gate jobs good enough at this point? There are still random failures as this no-op change shows https://review.openstack.org/72576 but I don't think they're stable/havana specific. Do we have a list of those somewhere? Pulled out where

Re: [openstack-dev] [neutron] [stable/havana] cherry backport, multiple external networks, passing tests

2014-02-12 Thread Alan Pevec
2014-02-12 10:48 GMT+01:00 Miguel Angel Ajo Pelayo mangel...@redhat.com: Could any core developer check/approve this if it does look good? https://review.openstack.org/#/c/68601/ I'd like to get it in for the new stable/havana release if it's possible. I'm afraid it's too late for

Re: [openstack-dev] [Openstack-stable-maint] Stable gate status?

2014-02-18 Thread Alan Pevec
2014-02-11 16:14 GMT+01:00 Anita Kuno: On 02/11/2014 04:57 AM, Alan Pevec wrote: Hi Mark and Anita, could we declare stable/havana neutron gate jobs good enough at this point? There are still random failures as this no-op change shows https://review.openstack.org/72576 but I don't think

Re: [openstack-dev] [All] Fixed recent gate issues

2014-02-18 Thread Alan Pevec
Hi John, thanks for the summary. I've noticed one more fall out from swiftclient update in Grenade jobs running on stable/havana changes e.g. http://logs.openstack.org/02/73402/1/check/check-grenade-dsvm/a5650ac/console.html ... 2014-02-18 13:00:02.103 | Test Swift 2014-02-18 13:00:02.103 | +

Re: [openstack-dev] [All] Fixed recent gate issues

2014-02-19 Thread Alan Pevec
Yeah it's pip weirdness where things falls apart because of version cap. It's basically installing bin/swift from 1.9 when it sees the version requirement but it leaves everything in python-swiftclient namespace from master. So I've actually been looking at this since late yesterday the

Re: [openstack-dev] [Openstack-stable-maint] Stable gate status?

2014-02-20 Thread Alan Pevec
2014-02-20 8:57 GMT+01:00 Miguel Angel Ajo Pelayo mangel...@redhat.com: I rebased the https://review.openstack.org/#/c/72576/ no-op change. And it failed in check-tempest-dsvm-neutron-pg with bug 1254890 - Timed out waiting for thing ... to become ACTIVE while previous check on Feb 17 failed in

Re: [openstack-dev] [swift]stable/havana Jenkins failed

2014-02-20 Thread Alan Pevec
I notice that we have changed from swiftclient import Connection, HTTPException to from swiftclient import Connection, RequestException at 2014-02-14, I don't know is it relational. I have reported a bug for this: https://bugs.launchpad.net/swift/+bug/1281886 Bug is a duplicate of

Re: [openstack-dev] [All] Fixed recent gate issues

2014-02-24 Thread Alan Pevec
2014-02-23 10:52 GMT+01:00 Gary Kotton gkot...@vmware.com: It looks like this does not solve the issue. Yeah https://review.openstack.org/74451 doesn't solve the issue completely, we have SKIP_EXERCISES=boot_from_volume,bundle,client-env,euca,swift,client-args but failure is now in Grenade's

Re: [openstack-dev] [All] Fixed recent gate issues

2014-02-24 Thread Alan Pevec
https://review.openstack.org/74451 doesn't solve the issue completely, we have SKIP_EXERCISES=boot_from_volume,bundle,client-env,euca,swift,client-args but failure is now in Grenade's Javelin script: + swift upload javelin /etc/hosts ...(same Traceback)... [ERROR]

Re: [openstack-dev] Help a poor Nova Grizzy Backport Bug Fix

2014-02-25 Thread Alan Pevec
Hi Michael, 2014-02-25 5:07 GMT+01:00 Michael Davies mich...@the-davies.net: I have a Nova Grizzly backport bug[1] in review[2] that has been hanging around for 4 months waiting for one more +2 from a stable team person. thanks for the backport! BTW stable team list is openstack-stable-maint

Re: [openstack-dev] Help a poor Nova Grizzy Backport Bug Fix

2014-02-25 Thread Alan Pevec
[2] https://review.openstack.org/#/c/54460/ I've sent it to check queue, it should fail due to Boto issue above. It also failed due to pyopenssl 0.14 update pulling a new dep which fails to build in Grizzly devstack, should be fixed by https://review.openstack.org/76189 Cheers, Alan

Re: [openstack-dev] [Openstack-stable-maint] Stable/grizzly

2013-10-10 Thread Alan Pevec
2013/10/10 Sean Dague s...@dague.net: Hmph. So boto changed their connection function signatures to have a 3rd argument, and put it second, and nothing has defaults. So isn't that a boto bug? Not sure what their backward-compatibility statement is but it is silly to break API just like that[1]

Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps

2013-11-27 Thread Alan Pevec
2013/11/27 Sean Dague s...@dague.net: The problem is you can't really support both iso8601 was dormant for years, and the revived version isn't compatible with the old version. So supporting both means basically forking iso8601 and maintaining you own version of it monkey patched in your own

[openstack-dev] stable/havana 2013.2.1 freeze tomorrow

2013-12-04 Thread Alan Pevec
Hi, first stable/havana release 2013.2.1 is scheduled[1] to be released next week on December 12th, so freeze on stable/havana goes into effect tomorrow EOD, one week before the release. Everybody is welcome to help review proposed changes[2] taking into account criteria for stable fixes[3].

Re: [openstack-dev] stable/havana 2013.2.1 freeze tomorrow

2013-12-06 Thread Alan Pevec
2013/12/4 Alan Pevec ape...@gmail.com: first stable/havana release 2013.2.1 is scheduled[1] to be released next week on December 12th, so freeze on stable/havana goes into effect tomorrow EOD, one week before the release. We're behind with reviewing so we'll be doing soft-freeze today: stable

Re: [openstack-dev] stable/havana 2013.2.1 freeze tomorrow

2013-12-07 Thread Alan Pevec
2013/12/6 Alan Pevec ape...@gmail.com: 2013/12/4 Alan Pevec ape...@gmail.com: first stable/havana release 2013.2.1 is scheduled[1] to be released next week on December 12th, so freeze on stable/havana goes into effect tomorrow EOD, one week before the release. We're behind with reviewing so

[openstack-dev] Call for testing: 2013.2.1 candidate tarballs

2013-12-08 Thread Alan Pevec
Hi, We are scheduled to publish Nova, Keystone, Glance, Neutron, Cinder, Horizon, Heat and Ceilometer 2013.2.1 stable Havana releases on Thursday Dec 12. The list of issues fixed so far can be seen here: https://launchpad.net/nova/+milestone/2013.2.1

Re: [openstack-dev] [Openstack-stable-maint] Preparing for 2014.1.2 -- branches freeze Aug 7

2014-08-02 Thread Alan Pevec
... above relates only to freeze exceptions for critical issues which must be raised and discussed on openstack-stable-maint release. Hopefully there won't be any. openstack-stable-maint _list_ ___ OpenStack-dev mailing list

Re: [openstack-dev] keystone

2014-06-02 Thread Alan Pevec
After restarting keystone with the following command, $service openstack-keystone restart it is giving a message Aborting wait for keystone to start. Could you please help on what the problem could be? This is not an appropriate topic for the development mailing list, please open a question

Re: [openstack-dev] [all] icehouse failure rates are somewhat catastrophic - who is actually maintaining it?

2014-10-02 Thread Alan Pevec
The original idea was that these stable branches would be maintained by the distros, and that is clearly not happening if you look at the code review Stable branches are maintained by the _upstream_ stable-maint team[1] where most members might be from (two) distros but please note that all

Re: [openstack-dev] [all] icehouse failure rates are somewhat catastrophic - who is actually maintaining it?

2014-10-02 Thread Alan Pevec
I'm on retry #7 of modifying the tox.ini file in devstack. Which review# is that so I can have a look? Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-stable-maint] Stable check of openstack/glance failed

2014-10-15 Thread Alan Pevec
2014-10-15 11:24 GMT+02:00 Ihar Hrachyshka ihrac...@redhat.com: I've reported a bug for the failure [1], marked it as Critical and nominated for Juno and Icehouse. I guess that's all we need to do to pay attention of glance developers to the failure, right? Thanks Ihar, we have few Glance

[openstack-dev] [cinder] [barbican] Stable check of openstack/cinder failed

2014-11-01 Thread Alan Pevec
Hi, cinder juno tests are failing after new barbicanclient release - periodic-cinder-python26-juno http://logs.openstack.org/periodic-stable/periodic-cinder-python26-juno/d660c21 : FAILURE in 11m 37s - periodic-cinder-python27-juno

Re: [openstack-dev] Cross distribution talks on Friday

2014-11-01 Thread Alan Pevec
%install export OSLO_PACKAGE_VERSION=%{version} %{__python} setup.py install -O1 --skip-build --root %{buildroot} Then everything should be ok and PBR will become your friend. Still not my friend because I don't want a _build_ tool as runtime dependency :) e.g. you don't ship make(1) to run

[openstack-dev] [stable] Re: [Openstack-stable-maint] Stable check of openstack/glance failed

2014-11-11 Thread Alan Pevec
2014-11-11 7:26 GMT+01:00 jenk...@openstack.org: - periodic-glance-python26-juno http://logs.openstack.org/periodic-stable/periodic-glance-python26-juno/d0ea683 : FAILURE in 21m 09s - periodic-glance-python27-juno

[openstack-dev] [stable] Fwd: New config options, no default change

2014-11-11 Thread Alan Pevec
Hi Dave, I'm forwarding your message to openstack-stable-maint, that list has been made read-only as decided on release management meetup on Friday Nov 7 2014, see under * Stable branches in https://etherpad.openstack.org/p/kilo-infrastructure-summit-topics I have set explicit Reply-To: header to

Re: [openstack-dev] [stable] Re: [Openstack-stable-maint] Stable check of openstack/glance failed

2014-11-11 Thread Alan Pevec
https://bugs.launchpad.net/glance/+bug/1391437 and marked it as Critical. ok, so current issue is a bug for both master and stable/juno but I'd still like glance_store backward compatibility be clarified by the Glance team. Cheers, Alan ___

Re: [openstack-dev] [stable] New config options, no default change

2014-11-11 Thread Alan Pevec
New config options may not change behavior (if default value preserves behavior), they still make documentation more incomplete (doc, books, and/or blogposts about Juno won't mention that option). That's why we definitely need such changes described clearly in stable release notes. I also lean

[openstack-dev] [stable] openstack-stable-maint list has been made read-only

2014-11-13 Thread Alan Pevec
2014-11-11 11:01 GMT+01:00 Alan Pevec ape...@gmail.com: ... All stable maintenance related discussion should happen on openstack-dev with [stable] tag in the subject. openstack-stable-maint list is now configured to discard posts from non-members and reject all posts from members

Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

2014-11-16 Thread Alan Pevec
2014-11-15 23:06 GMT+01:00 Robert Collins robe...@robertcollins.net: We did find a further issue, which was due to the use of setUpClass in tempest (a thing that testtools has never supported per se - its always been a happy accident that it worked). I've hopefully fixed that in 1.3.0 and

Re: [openstack-dev] [all] testtools 1.2.0 release breaks the world

2014-11-17 Thread Alan Pevec
We don't support 2.6 any more in OpenStack. If we decide to pin testtools on stable/*, we could just let this be. We still support 2.6 on the python clients and oslo libraries - but indeed not for trove itself with master. What Andreas said, also testtools claims testtools gives you the very

Re: [openstack-dev] [stable] Proposal to add Dave Walker back to stable-maint-core

2014-11-27 Thread Alan Pevec
+1 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable] New config options, no default change

2014-12-02 Thread Alan Pevec
What is the text that should be included in the commit messages to make sure that it is picked up for release notes? I'm not sure anyone tracks commit messages to create release notes. Let's use existing DocImpact tag, I'll add check for this in the release scripts. But I prefer if you could

Re: [openstack-dev] [stable] Re: [neutron] the hostname regex pattern fix also changed behaviour :(

2014-12-02 Thread Alan Pevec
With the change, will existing instances work as before? Yes, this cuts straight to the heart of the matter: What's the purpose of these validation checks? Specifically, if someone is using an invalid hostname that passed the previous check but doesn't pass an improved/updated check,

[openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-02 Thread Alan Pevec
Hi all, here are exception proposal I have collected when preparing for the 2014.2.1 release, stable-maint members please have a look! General: cap Oslo and client library versions - sync from openstack/requirements stable/juno, would be good to include in the release.

Re: [openstack-dev] [stable] New config options, no default change

2014-12-02 Thread Alan Pevec
Will the bugs created by this end up in the openstack-manuals project (which I don't think is the right place for them in this case) or has it been set up to create them somewhere else (or not at all) when the commits are against the stable branches? Docs team, how do you handle DocImpact

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-02 Thread Alan Pevec
General: cap Oslo and client library versions - sync from openstack/requirements stable/juno, would be good to include in the release. https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z +2, let's keep all deps in sync. Those updates do not

Re: [openstack-dev] [OpenStack-docs] [stable] New config options, no default change

2014-12-02 Thread Alan Pevec
In this case we're referring to how we handle DocImpact for specific branches of a project (say stable/juno of Nova, for example). I don't think we'd want to change the DocImpact handling for the entire project to go somewhere other than openstack-manuals. As far as I know the current setup

[openstack-dev] stable/grizzly 2013.1.3 approaching WAS Re: No Project release status meeting tomorrow

2013-07-23 Thread Alan Pevec
Hi Thierry, we'll be skipping the release status meeting tomorrow at 21:00 UTC I wanted to remind at that meeting about the next stable/grizzly release 2013.1.3, meeting next week would too late so I'll piggy back here. Proposed freeze is Aug 1st and release Aug 8th. Milestone 2013.1.3 has

[openstack-dev] Call for testing: 2013.1.3 candidate tarballs

2013-08-05 Thread Alan Pevec
Hi all, We are scheduled to publish Nova, Keystone, Glance, Networking, Cinder and Horizon 2013.1.3 releases on Thursday Aug 8. Ceilometer and Heat were incubating in Grizzly so they're not covered by the stable branch policy but Ceilometer and Heat teams are preparing 2013.1.3 releases on their

Re: [openstack-dev] Gate issues - what you can do to help

2013-09-28 Thread Alan Pevec
1) Please *do not* Approve or Reverify stable/* patches. The pyparsing requirements conflict with neutron client from earlier in the week is still not resolved on stable/*. Also there's an issue with quantumclient and Nova stable/grizzly:

Re: [openstack-dev] Gate issues - what you can do to help

2013-10-01 Thread Alan Pevec
1) Please *do not* Approve or Reverify stable/* patches. The pyparsing requirements conflict with neutron client from earlier in the week is still not resolved on stable/*. Also there's an issue with quantumclient and Nova stable/grizzly:

Re: [openstack-dev] Gate issues - what you can do to help

2013-10-02 Thread Alan Pevec
Hi, quantumclient is now fixed for stable/grizzly but there are issues with check-tempest-devstack-vm-neutron job where devstack install is dying in the middle of create_quantum_initial_network() without trace e.g.

Re: [openstack-dev] Gate issues - what you can do to help

2013-10-03 Thread Alan Pevec
2013/10/3 Gary Kotton gkot...@vmware.com: Please see https://review.openstack.org/#/c/49483/ That's s/quantum/neutron/ on stable - I'm confused why is that, it should have been quantum everywhere in Grizzly. Could you please expand your reasoning in the commit message? It also doesn't help,

Re: [openstack-dev] Gate issues - what you can do to help

2013-10-03 Thread Alan Pevec
The problems occur when the when the the following line is invoked: https://github.com/openstack-dev/devstack/blob/stable/grizzly/lib/quantum#L302 But that line is reached only in case baremetal is enabled which isn't the case in gate, is it? Cheers, Alan

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-03 Thread Alan Pevec
2014-12-02 17:15 GMT+01:00 Jay S. Bryant jsbry...@electronicjungle.net: Cinder https://review.openstack.org/137537 - small change and limited to the VMWare driver +1 I think this is fine to make an exception for. one more Cinder exception proposal was added in StableJuno etherpad *

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-03 Thread Alan Pevec
Horizon standing-after-freeze translation update, coming on Dec 3 This is now posted https://review.openstack.org/138798 David, Matthias, I'd appreciate one of you to have a quick look before approving. Cheers, Alan ___ OpenStack-dev mailing list

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-03 Thread Alan Pevec
Neutron https://review.openstack.org/136294 - default SNAT, see review for details, I cannot distil 1liner :) -1: I would rather fix the doc to match behavior, than change behavior to match the doc and lose people that were relying on it. Consensus is not to merge this and keep behavior.

Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

2014-12-04 Thread Alan Pevec
2014-12-03 22:10 GMT+01:00 Ben Nemec openst...@nemebean.com: On 12/03/2014 02:45 PM, Sean Dague wrote: So this - https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586 was clearly a violation of our 1 cycle for deprecation of config options. I think that

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-04 Thread Alan Pevec
I'd like to request another exception for Neutron to avoid introducing regression in hostname validation for DNS nameservers: https://review.openstack.org/#/c/139061/ Nice solution for this regression, I think it's worthy last-minute exception. Should VMT also send this officially to the

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-04 Thread Alan Pevec
2014-12-04 23:00 GMT+01:00 Jay S. Bryant jsbry...@electronicjungle.net: Finally was able to get the master version through the gate and cherry-picked it here: https://review.openstack.org/#/c/139194/ That one has made it through the check. So, if it isn't too late, it could use a +2/+A.

Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

2014-12-04 Thread Alan Pevec
Filed as https://bugs.launchpad.net/oslo.messaging/+bug/1399085 Since this is blocking stable/juno I've pushed partial revert of Revert Cap Oslo and client library versions https://review.openstack.org/138963 as a quickfix before the 2014.2.1 release today. We'll of course need to revisit

[openstack-dev] [stable] Re: Stable check of openstack/cinder failed

2014-12-06 Thread Alan Pevec
2014-12-06 7:14 GMT+01:00 A mailing list for the OpenStack Stable Branch test reports. openstack-stable-ma...@lists.openstack.org: Build failed. - periodic-cinder-python26-icehouse http://logs.openstack.org/periodic-stable/periodic-cinder-python26-icehouse/d19db38 : FAILURE in 6m 50s -

Re: [openstack-dev] Do all OpenStack daemons support sd_notify?

2014-12-16 Thread Alan Pevec
2014-12-15 17:00 GMT+01:00 Clint Byrum cl...@fewbar.com: Excerpts from Ihar Hrachyshka's message of 2014-12-15 07:21:04 -0800: I guess Type=notify is supposed to be used with daemons that use Service class from oslo-incubator that provides systemd notification mechanism, or call to

Re: [openstack-dev] django-openstack-auth and stable/icehouse

2015-02-04 Thread Alan Pevec
Dependencies in requirements.txt do not seem to be used in stable/icehouse gate jobs, recent pip freeze in stable/icehouse shows: ... oslo.config==1.6.0 # git sha 99e530e django-openstack-auth==1.1.9 # git sha 2079383 It's because of this: 2015-01-27 19:33:44.152 | Collecting

Re: [openstack-dev] django-openstack-auth and stable/icehouse

2015-02-04 Thread Alan Pevec
Bumping minimal oslo.config version due to the issue in django-openstack-auth seems like a wrong way to do it. Dependencies in requirements.txt do not seem to be used in stable/icehouse gate jobs, recent pip freeze in stable/icehouse shows: ... oslo.config==1.6.0 # git sha 99e530e

[openstack-dev] [stable] Stable check of openstack/nova failed - EnvironmentError: mysql_config not found

2015-01-19 Thread Alan Pevec
- periodic-nova-docs-icehouse http://logs.openstack.org/periodic-stableperiodic-nova-docs-icehouse/a3d88ed/ : FAILURE in 1m 15s Same symptom as https://bugs.launchpad.net/openstack-ci/+bug/1336161 which is marked as Fix released, could infra team check if all images are alright? This showed

Re: [openstack-dev] [neutron] New version of python-neutronclient release: 2.3.11

2015-02-20 Thread Alan Pevec
https://review.openstack.org/#/c/157535/ Do you know where it ends ? We could set up Depends lines on those requirements stable/* reviews and line them up so that they are ready to merge when openstackclient is fixed in devstack. Alternative workaround is https://review.openstack.org/157654

Re: [openstack-dev] [neutron] New version of python-neutronclient release: 2.3.11

2015-02-20 Thread Alan Pevec
(I believe the version cap for icehouse 2.4 is expected to a policy like this). Yes, that assumed Semantic Versioning (semver.org) which 2.3.11 broke. Cheers, Alan __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Nova] Requirements.txt and optional requirements

2015-01-30 Thread Alan Pevec
- Remove this requirement, no optional entries in requirements.txt, a 'deployer' has to know what dependencies the components he wants to use have Keystone is documenting its optional dependencies in test-requirements.txt look for # Optional ... comments in

Re: [openstack-dev] [stable] juno is fubar in the gate

2015-02-09 Thread Alan Pevec
Tracking etherpad: https://etherpad.openstack.org/p/wedged-stable-gate-feb-2015 BTW there is a tracking etherpad updated by https://wiki.openstack.org/wiki/StableBranch#Stable_branch_champions https://etherpad.openstack.org/p/stable-tracker linked in

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

2015-02-12 Thread Alan Pevec
I think there's a place for private conversation (eg. discussing a security issue that corresponds to a CVE... CVE's are a special exception and I'd even argue on the need of private conversations there. Discussing CVEs in private came up few times but I'm not sure IRC is secure enough for

Re: [openstack-dev] [stable] Proposal to add Flavio Percoco to stable-maint-core

2015-01-07 Thread Alan Pevec
+2 Flavio knows stable branch policies very well and will be a good addition to the cross-projects stable team. Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

[openstack-dev] [stable] Icehouse 2014.1.4 freeze exceptions

2015-03-11 Thread Alan Pevec
Hi, next Icehouse stable point release 2014.1.4 has been slipping last few weeks due to various gate issues, see Recently closed section in https://etherpad.openstack.org/p/stable-tracker for details. Branch looks good enough now to push the release tomorrow (Thursdays are traditional release

Re: [openstack-dev] [all] Testtools 1.7.0 may error if you installed it before reading this email

2015-03-11 Thread Alan Pevec
So, we can work around this in devstack, but it seems like there is a more fundamental bug here that setup project isn't following dependencies. Dep chain was: testtools (from zake=0.1-tooz=0.12,=0.3-ceilometer==2014.2.3.dev2) Unneeded _runtime_ dependency on testtools was removed in

Re: [openstack-dev] [all] Testtools 1.7.0 may error if you installed it before reading this email

2015-03-10 Thread Alan Pevec
The wheel has been removed from PyPI and anyone installing testtools 1.7.0 now will install from source which works fine. On stable/icehouse devstack fails[*] with pkg_resources.VersionConflict: (unittest2 0.5.1 (/usr/lib/python2.7/dist-packages), Requirement.parse('unittest2=1.0.0')) when

Re: [openstack-dev] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2015-03-27 Thread Alan Pevec
I'm working on removing mox in favor of mox3 to reduce a bit our dependency. Then mox3 should be imported to openstack namespace as suggested by Chuck in Dec 2013. Looks like last known source repository is https://github.com/emonty/pymox with last commit from Aug 2013 or did it move somewhere

Re: [openstack-dev] [swift] swift memory usage in centos7 devstack jobs

2015-03-27 Thread Alan Pevec
I'll spend a bit more time on this -- I haven't determined if it's centos or swift specific yet -- but in the mean-time, beware of recent pyOpenSSL But how come that same recent pyOpenSSL doesn't consume more memory on Ubuntu? Alan

[openstack-dev] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2015-03-26 Thread Alan Pevec
blast from the past... 2013-12-04 19:17 GMT+01:00 Chuck Short chuck.sh...@canonical.com: On Wed, Dec 4, 2013 at 11:16 AM, Nikola ─Éipanov ndipa...@redhat.com wrote: ... 1) Figure out what is the deal with mox3 and decide if owning it will really be less trouble than porting nova. To be hones -

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

2015-01-30 Thread Alan Pevec
2015-01-29 19:31 GMT+01:00 Joe Gordon joe.gord...@gmail.com: That means clients need overlapping dependencies with the stable branches. I don't think this is a reasonable requirement, and am not sure what we gain from it. Capping all Oslo and clients on stable/juno was reverted[1] due to

Re: [openstack-dev] ERROR: openstackclient.shell Exception raised: python-keystoneclient 1.4.0

2015-04-27 Thread Alan Pevec
This is a problem of dependency resolution rather than an issue of keystoneclient specifically. You can see that glanceclient has a cap on keystoneclient that the installed version doesn't meet. python-keystoneclient=1.1.0,1.4.0 is requirement on python-glanceclient stable/kilo branch, while

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-05 Thread Alan Pevec
If the downsteam consumer has their own extra patches ontop of the stable branch, then it seems D is even less useful than A. It is not - downstream (speaking for RDO) I would keep Version: 2015.1.N where N is stable patch# so that we have a common reference point with other distros. Our

Re: [openstack-dev] Targeting icehouse-eol?

2015-06-04 Thread Alan Pevec
The only open question I have is if we need to do an Icehouse point release prior to the tag and dropping the branch, but I don't think that's happened in the past with branch end of life - the eol tag basically serves as the placeholder to the last 'release'. I don't think we need to do a

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-07 Thread Alan Pevec
2015-06-06 19:08 GMT+02:00 Ian Cordasco ian.corda...@rackspace.com: Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid SemVer (http://semver.org/) Right, so semver compatible versioning on stable/kilo would be 2015.1.N but PBR doesn't support that. If we want to be pedantic

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-07 Thread Alan Pevec
and *Plan D* would be to start doing automatic per-project micro-versions on each commit: e.g. 2015.1.N where N is increased on each commit. How do you gpg sign these tags? I hope the solution isn't to store a key in infra without a passphrase. Plan D doesn't include git tags, 2015.1.N

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-07 Thread Alan Pevec
How do you check if project X in version n works with project Y in version m, using this non-scheduled point release free for all model? That was an illusion of point releases, as Thierry said there wasn't significantly more testing and I don't remember any testing reports during stable freeze

Re: [openstack-dev] Targeting icehouse-eol?

2015-06-16 Thread Alan Pevec
let's release this last one (codename: Farewell ?) point release. I can do this next week after we finish pending reviews. Remaining stable/icehouse reviews[1] have -2 or -1 except https://review.openstack.org/176019 which I've asked neutron-stable-maint to review. Matt, anything else before we

[openstack-dev] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs

2015-06-17 Thread Alan Pevec
Hi all, We are scheduled to publish 2014.1.5, last Icehouse point release, on Thurs June 18th for Ceilometer, Cinder, Glance, Heat, Horizon, Keystone, Neutron, Nova and Trove. The list of issues fixed can be seen here: https://launchpad.net/ceilometer/+milestone/2014.1.5

Re: [openstack-dev] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs

2015-06-17 Thread Alan Pevec
http://tarballs.openstack.org/glance/heat-stable-icehouse.tar.gz copy-paste fail, this should be: http://tarballs.openstack.org/glance/glance-stable-icehouse.tar.gz __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-15 Thread Alan Pevec
The only issue is having a correct version number. Swift could well iterate after 20151, for example doing 20151.1 then 20151.2, etc. Swift never had coordinated YEAR.N versions, https://wiki.openstack.org/wiki/Swift/version_map and they never released a version from their stable/* branches.

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-05-31 Thread Alan Pevec
2015-05-29 18:30 GMT+02:00 Jeremy Stanley fu...@yuggoth.org: On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote: This is generally my opinion as-well, I always hoped that *every* commit would be considered a release rather than an arbitrary tagged date. [...] If we switch away from

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-01 Thread Alan Pevec
You will get different checksums with tar and/or gzip, you can check the extracted files and they should be the same. Yes, content is the same, it's just difference in timestamps of folders and generated files (ChangeLog, egg-info etc). I would like to see signed commits in the 'official'

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-01 Thread Alan Pevec
One issue is how would we provide source tarballs, statically hosting tarballs for each and every micro version is not realistic, also those wouldn't be signed. Sorry, but why isn't it realistic, and why wouldn't they be signed? I thought storage requirements to generate tarball for each

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-01 Thread Alan Pevec
*Plan C* would be to just let projects tag stable point releases from time to time. That would solve all the original stated problems. And that would solve objections 2 and 3, which I think are the most valid ones. and *Plan D* would be to start doing automatic per-project micro-versions on

Re: [openstack-dev] [puppet] [infra] issues with beaker/centos7 job

2015-07-02 Thread Alan Pevec
2015-07-02 5:00 GMT+02:00 Ian Wienand iwien...@redhat.com: So I looked into this with Gilles, and that error is a red-herring (it's just saying the rdo repos don't create the presto/deltarpm stuff); yep the real issue is when python-requests fails to install [1] a bit later due to [2]

Re: [openstack-dev] [puppet] [infra] issues with beaker/centos7 job

2015-07-02 Thread Alan Pevec
I could not reproduce on a clean centos7, so I'd like to grab nodepool image to have a closer look After having a closer look, I see that image has requests 2.7 installed from pypi which overwrites python-requests RPM installation and wreaks havoc when trying to upgrade RPM. I'm not sure why

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

2015-08-17 Thread Alan Pevec
The only alternative seems to be to have on-demand stable-branch tagging. The main drawbacks of that option are that consumers of the stable branch are unnecessarily limited to specific tagged commits, and depend on various project teams to remember to push them. As Doug suggested, stable

Re: [openstack-dev] [swift] swift memory usage in centos7 devstack jobs

2015-08-16 Thread Alan Pevec
2) Should this also be sent to centos-devel folks so that they don't upgrade/update the pyopenssl in their distro repos until the issue is resolved ? I think let's give the upstream issues a little while to play-out, then we decide our next steps around use of the library based on that

Re: [openstack-dev] [horizon] [stable] Freeze exception

2015-07-29 Thread Alan Pevec
I would like to request for a freeze exception for the this bug: https://bugs.launchpad.net/horizon/+bug/1474618 This is the patch: https://review.openstack.org/#/c/206184/ Too late for 2015.1.1, tags (except neutron) have been pushed but certainly fine to merge to stable/kilo. Cheers, Alan

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

2015-07-29 Thread Alan Pevec
I think pushing them up earlier would indeed make it easier for folk. Indeed, but it's too late now. But its not as good as using post-versioniing :) Agreed, after 2015.1.2 version bumps are merged, I'll propose version= line removals on stable branches so this situation doesn't happen again.

  1   2   >