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
*
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
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.
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
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,
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.
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
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
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
+1
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
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
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
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
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
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
___
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
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
%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
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
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
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
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
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
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
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
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
... 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
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
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
[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
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
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]
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
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
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
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
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 | +
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
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
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
... 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
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
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
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
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
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].
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
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]
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,
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
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.
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:
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:
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
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
101 - 156 of 156 matches
Mail list logo
