<div dir="ltr">help</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 7:29 PM, <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-dev-owner@lists.openstack.org">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: The Gate is broken: all gate-tempest-devstack-* are<br>
failing (Dirk M?ller)<br>
2. Re: The Gate is broken: all gate-tempest-devstack-* are<br>
failing (John Griffith)<br>
3. Re: The Gate is broken: all gate-tempest-devstack-* are<br>
failing (Joe Gordon)<br>
4. Re: The Gate is broken: all gate-tempest-devstack-* are<br>
failing (Sean Dague)<br>
5. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Dirk M?ller)<br>
6. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Dirk M?ller)<br>
7. [Ceilometer] Meeting agenda for Thu Jul 11rd at 1500 UTC<br>
(Julien Danjou)<br>
8. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Dolph Mathews)<br>
9. Re: The Gate is broken: all gate-tempest-devstack-* are<br>
failing (John Griffith)<br>
10. Re: Work around DB in OpenStack (Oslo, Nova, Cinder, Glance)<br>
(Mark McLoughlin)<br>
11. [Cinder] Bug Squash day, thanks! (John Griffith)<br>
12. Re: Work around DB in OpenStack (Oslo, Nova, Cinder, Glance)<br>
(John Griffith)<br>
13. Re: Change in openstack/neutron[master]: Add method to get<br>
iptables traffic counters (Sylvain Afchain)<br>
14. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Sean Dague)<br>
15. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Sean Dague)<br>
16. Re: [Keystone] How to write unit tests for db methods?<br>
(Adam Young)<br>
17. Re: [Keystone] Need help writing gate tests (Adam Young)<br>
18. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Julie Pichon)<br>
19. Re: [Savanna-all] [savanna-all] merging savanna-extra<br>
elements (Ivan Berezovskiy)<br>
20. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Dan Smith)<br>
21. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (John Griffith)<br>
22. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Matthew Treinish)<br>
23. Re: The danger of capping python-*clients in core projects,<br>
and forbidding it in the future (Dirk M?ller)<br>
24. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Russell Bryant)<br>
25. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Mark McLoughlin)<br>
26. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Chris Behrens)<br>
27. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Russell Bryant)<br>
28. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (John Griffith)<br>
29. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Sean Dague)<br>
30. Re: AMQP Version upgrade plans? (William Henry)<br>
31. Re: [Savanna-all] [savanna-all] merging savanna-extra<br>
elements (Matthew Farrellee)<br>
32. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Sean Dague)<br>
33. Re: Bug #1194026 (Salvatore Orlando)<br>
34. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Thierry Carrez)<br>
35. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Thierry Carrez)<br>
36. [keystone] sqlite doesn't support migrations (Dolph Mathews)<br>
37. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Nachi Ueno)<br>
38. [Glance] Meeting Reminder (Mark Washenberger)<br>
39. SQLAlchemy-migrate needs a new maintainer (Thomas Goirand)<br>
40. [Olso]About blueprint: Separate translation domain for log<br>
messages (Ying Chun Guo)<br>
41. Re: SQLAlchemy-migrate needs a new maintainer (David Ripton)<br>
42. [Savanna-all] Blueprints for EDP components (Alexander Kuznetsov)<br>
43. Re: [Olso]About blueprint: Separate translation domain for<br>
log messages (Ben Nemec)<br>
44. Re: SQLAlchemy-migrate needs a new maintainer (Boris Pavlovic)<br>
45. [State-Management] Agenda for todays meeting at 2000 UTC<br>
(Joshua Harlow)<br>
46. Re: SQLAlchemy-migrate needs a new maintainer (Monty Taylor)<br>
47. Re: Current biggest OpenStack gate fail culprit - neutron bug<br>
#1194026 (Sean Dague)<br>
48. Re: DB team meeting Thursday 1900 UTC (David Ripton)<br>
49. Revert Pass instance host-id to Quantum using port bindings<br>
extension. (Aaron Rosen)<br>
50. Re: SQLAlchemy-migrate needs a new maintainer (Dolph Mathews)<br>
51. Re: [Nova] Criteria for compute drivers (John Garbutt)<br>
52. Re: [Neutron] Campus Network Blueprint (Filipe Manco)<br>
53. Re: SQLAlchemy-migrate needs a new maintainer (Monty Taylor)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 11 Jul 2013 14:29:30 +0200<br>
From: Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The Gate is broken: all<br>
gate-tempest-devstack-* are failing<br>
Message-ID:<br>
<CAL5wTH5NY4scYeVbp=<a href="mailto:0-20Lb2zBwtxvkgYB%2BBv0aFNSnP0US7w@mail.gmail.com">0-20Lb2zBwtxvkgYB+Bv0aFNSnP0US7w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi Sean,<br>
<br>
> Cinder uncapping python-keystoneclient will get us past this.<br>
<br>
There is a review exactly proposing that:<br>
<br>
<a href="https://review.openstack.org/#/c/36344/" target="_blank">https://review.openstack.org/#/c/36344/</a><br>
<br>
<br>
> Though I'm not<br>
> quite sure how we got to this break point in the first place.<br>
<br>
<br>
I think this is due to the django_openstack_auth breakage that let<br>
this one slip by (there was for a short amount of time a >= 0.3<br>
requirement on python-keystoneclient from somewhere).<br>
<br>
Greetings,<br>
Dirk<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 11 Jul 2013 06:48:26 -0600<br>
From: John Griffith <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The Gate is broken: all<br>
gate-tempest-devstack-* are failing<br>
Message-ID:<br>
<CA+qL3LVcdK1s7XGk_-zZ=<a href="mailto:9ScQ9jkJBHpLSH_Ge0duXVZwoTnjg@mail.gmail.com">9ScQ9jkJBHpLSH_Ge0duXVZwoTnjg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Jul 11, 2013 at 6:29 AM, Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>> wrote:<br>
<br>
> Hi Sean,<br>
><br>
> > Cinder uncapping python-keystoneclient will get us past this.<br>
><br>
> There is a review exactly proposing that:<br>
><br>
> <a href="https://review.openstack.org/#/c/36344/" target="_blank">https://review.openstack.org/#/c/36344/</a><br>
<br>
<br>
Actually for a number of reasons: <a href="https://review.openstack.org/#/c/36559/" target="_blank">https://review.openstack.org/#/c/36559/</a> is<br>
what we needed,<br>
which I gave up on last night a bit after midnight when James Blair moved it<br>
to the front of the queue and it encountered a hiccup, at which point some<br>
other<br>
core Cinder folks took over baby-sitting it and it's finally through.<br>
<br>
<br>
><br>
><br>
> > Though I'm not<br>
> > quite sure how we got to this break point in the first place.<br>
><br>
><br>
> I think this is due to the django_openstack_auth breakage that let<br>
> this one slip by (there was for a short amount of time a >= 0.3<br>
> requirement on python-keystoneclient from somewhere).<br>
><br>
<br>
Yep, although it wasn't that short of a period of time. I also raised this<br>
concern<br>
over the ML regarding common-requirements etc and had ZERO response.<br>
<br>
><br>
> Greetings,<br>
> Dirk<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/5452b06d/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/5452b06d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 11 Jul 2013 14:01:04 +0100<br>
From: Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The Gate is broken: all<br>
gate-tempest-devstack-* are failing<br>
Message-ID:<br>
<CAHXdxOeH-YRHQs0Dc=<a href="mailto:UJCm-2LCG8aaABMzYGGiftyXTiADuxNw@mail.gmail.com">UJCm-2LCG8aaABMzYGGiftyXTiADuxNw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Jul 11, 2013 at 1:48 PM, John Griffith<br>
<<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>>wrote:<br>
<br>
><br>
><br>
><br>
> On Thu, Jul 11, 2013 at 6:29 AM, Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>> wrote:<br>
><br>
>> Hi Sean,<br>
>><br>
>> > Cinder uncapping python-keystoneclient will get us past this.<br>
>><br>
>> There is a review exactly proposing that:<br>
>><br>
>> <a href="https://review.openstack.org/#/c/36344/" target="_blank">https://review.openstack.org/#/c/36344/</a><br>
><br>
><br>
> Actually for a number of reasons: <a href="https://review.openstack.org/#/c/36559/" target="_blank">https://review.openstack.org/#/c/36559/</a> is<br>
> what we needed,<br>
> which I gave up on last night a bit after midnight when James Blair moved<br>
> it<br>
> to the front of the queue and it encountered a hiccup, at which point some<br>
> other<br>
> core Cinder folks took over baby-sitting it and it's finally through.<br>
><br>
<br>
<br>
That patch took 12 hours to get through! meaning the gate was down for 12<br>
hours or so. We should be able to do better then that in the future.<br>
Only question is how?<br>
<br>
<br>
><br>
><br>
>><br>
>><br>
>> > Though I'm not<br>
>> > quite sure how we got to this break point in the first place.<br>
>><br>
>><br>
>> I think this is due to the django_openstack_auth breakage that let<br>
>> this one slip by (there was for a short amount of time a >= 0.3<br>
>> requirement on python-keystoneclient from somewhere).<br>
>><br>
><br>
> Yep, although it wasn't that short of a period of time. I also raised<br>
> this concern<br>
> over the ML regarding common-requirements etc and had ZERO response.<br>
><br>
>><br>
>> Greetings,<br>
>> Dirk<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/e102ee2a/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/e102ee2a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Thu, 11 Jul 2013 09:01:49 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] The Gate is broken: all<br>
gate-tempest-devstack-* are failing<br>
Message-ID: <<a href="mailto:51DEACBD.5050306@dague.net">51DEACBD.5050306@dague.net</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 07/11/2013 08:48 AM, John Griffith wrote:<br>
><br>
><br>
><br>
> On Thu, Jul 11, 2013 at 6:29 AM, Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a><br>
> <mailto:<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>>> wrote:<br>
><br>
> Hi Sean,<br>
><br>
> > Cinder uncapping python-keystoneclient will get us past this.<br>
><br>
> There is a review exactly proposing that:<br>
><br>
> <a href="https://review.openstack.org/#/c/36344/" target="_blank">https://review.openstack.org/#/c/36344/</a><br>
><br>
><br>
> Actually for a number of reasons:<br>
> <a href="https://review.openstack.org/#/c/36559/" target="_blank">https://review.openstack.org/#/c/36559/</a> is what we needed,<br>
> which I gave up on last night a bit after midnight when James Blair moved it<br>
> to the front of the queue and it encountered a hiccup, at which point<br>
> some other<br>
> core Cinder folks took over baby-sitting it and it's finally through.<br>
><br>
><br>
><br>
><br>
> > Though I'm not<br>
> > quite sure how we got to this break point in the first place.<br>
><br>
><br>
> I think this is due to the django_openstack_auth breakage that let<br>
> this one slip by (there was for a short amount of time a >= 0.3<br>
> requirement on python-keystoneclient from somewhere).<br>
><br>
> Yep, although it wasn't that short of a period of time. I also raised<br>
> this concern<br>
> over the ML regarding common-requirements etc and had ZERO response.<br>
<br>
I think the issue is that it came in the fire drill when we were running<br>
around getting to the bottom of the last gate fail.... sorry.<br>
<br>
I guess I thought my full uncapping strategy might supercede just a sync<br>
issue, no?<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 11 Jul 2013 15:12:27 +0200<br>
From: Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID:<br>
<CAL5wTH5SqnSEmvmrD4+bRBqnzkGj0xHHzwXECoG5r23S1GTr=<a href="mailto:Q@mail.gmail.com">Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
> Let's submit a multi-project bug on launchpad, and be serious for changing<br>
> these global requirements in following days<br>
<br>
<a href="https://bugs.launchpad.net/keystone/+bug/1200214" target="_blank">https://bugs.launchpad.net/keystone/+bug/1200214</a><br>
<br>
created.<br>
<br>
Greetings,<br>
Dirk<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Thu, 11 Jul 2013 15:25:48 +0200<br>
From: Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID:<br>
<CAL5wTH4Yx84N0iA4VDFtFQzTRBVuPMfzcSAnTCnYY_oX=<a href="mailto:dXHYQ@mail.gmail.com">dXHYQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi Thierry,<br>
<br>
> Indeed. The whole idea behind a single release channel for python client<br>
> libraries was that you should always be running the latest, as they<br>
> should drastically enforce backward compatibility.<br>
<br>
Well, backward compatibility can be tricky when it comes to test.<br>
We've for example recently had an issue where the newer keystoneclient<br>
broke mocking in tests. It is debateable if tests are part of the<br>
backward compatibility or not.<br>
<br>
See for example <a href="https://bugs.launchpad.net/horizon/+bug/1196823" target="_blank">https://bugs.launchpad.net/horizon/+bug/1196823</a><br>
<br>
This is currently also preventing me from being able to get a change<br>
on stable/grizzly past gating checks (which stumble on exactly this<br>
"regression").<br>
<br>
Greetings,<br>
Dirk<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Thu, 11 Jul 2013 15:30:30 +0200<br>
From: Julien Danjou <<a href="mailto:julien@danjou.info">julien@danjou.info</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [Ceilometer] Meeting agenda for Thu Jul 11rd<br>
at 1500 UTC<br>
Message-ID: <<a href="mailto:878v1dgr61.fsf@dex.adm.naquadah.org">878v1dgr61.fsf@dex.adm.naquadah.org</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
The Ceilometer project team holds a meeting in #openstack-meeting, see<br>
<a href="https://wiki.openstack.org/wiki/Meetings/MeteringAgenda" target="_blank">https://wiki.openstack.org/wiki/Meetings/MeteringAgenda</a> for more details.<br>
<br>
Next meeting is on Thu Jul 11rd at 1500 UTC<br>
<br>
Please add your name with the agenda item, so we know who to call on during<br>
the meeting.<br>
* Action from previous meeting<br>
* jd__ Write a terminology page in the documentation<br>
* Deprecate the "counter" term?<br>
* Review Havana-2 milestone<br>
* <a href="https://launchpad.net/ceilometer/+milestone/havana-2" target="_blank">https://launchpad.net/ceilometer/+milestone/havana-2</a><br>
* dhellmann - Tempest tests<br>
* Release python-ceilometerclient?<br>
* Open discussion<br>
<br>
If you are not able to attend or have additional topic(s) you would like<br>
to add, please update the agenda on the wiki.<br>
<br>
Cheers,<br>
--<br>
Julien Danjou<br>
# Free Software hacker # freelance consultant<br>
# <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 835 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/404cb2a2/attachment-0001.pgp" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/404cb2a2/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Thu, 11 Jul 2013 08:36:03 -0500<br>
From: Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>><br>
To: Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>>, OpenStack Development<br>
Mailing List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID:<br>
<CAC=h7gUPsiHUb2M+XivRo3cBQP7M=<a href="mailto:dGnfgFHvo69DkGXTgi%2BLg@mail.gmail.com">dGnfgFHvo69DkGXTgi+Lg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Jul 11, 2013 at 6:12 AM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>> wrote:<br>
<br>
> On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote:<br>
> > On Wednesday, July 10, 2013, Sean Dague wrote:<br>
> ><br>
> > > Yesterday in the very exciting run around to figure out why the gate<br>
> was<br>
> > > broken, we realized something interesting. Because of the way the gate<br>
> > > process pip requirements (one project at a time), on a current gate<br>
> run we<br>
> > > actually install and uninstall python-keystoneclient 4 times in a<br>
> normal<br>
> > > run, flipping back and forth from HEAD to 0.2.5.<br>
> > ><br>
> > > <a href="http://paste.openstack.org/**show/39880/" target="_blank">http://paste.openstack.org/**show/39880/</a><<br>
> <a href="http://paste.openstack.org/show/39880/" target="_blank">http://paste.openstack.org/show/39880/</a>>- shows what's going on<br>
> > ><br>
> > > The net of this means that if any of the projects specify a capped<br>
> client,<br>
> > > it has the potential for preventing that client from being tested in<br>
> the<br>
> > > gate. This is very possibly part of the reason we ended up with a<br>
> broken<br>
> > > python-keystoneclient 0.3.0 released.<br>
> ><br>
> ><br>
> > > I think we need to get strict on projects and prevent them from capping<br>
> > > their client requirements. That will also put burden on clients that<br>
> they<br>
> > > don't break backwards compatibility (which I think was a goal<br>
> regardless).<br>
> > > However there is probably going to be a bit of pain getting from where<br>
> we<br>
> > > are today, to this world.<br>
> ><br>
> ><br>
> > Thanks for investigating the underlying issue! I think the same<br>
> > policy should apply a bit further to any code we develop and consume<br>
> > ourselves as a community (oslo.config, etc). I have no doubt that's the<br>
> > standard we strive for, but it's all too easy to throw a cap into a<br>
> > requirements file and forget about it.<br>
><br>
> I don't think we've ever capped oslo.config anywhere. Got a pointer to<br>
> what triggered that concern?<br>
><br>
<br>
No no, I didn't mean to call you out... just using oslo.config as a prime<br>
example of a non-client project that should (and from my perspective: does)<br>
abide by the same policy.<br>
<br>
<br>
><br>
> We should/could be capping oslo.config like this:<br>
><br>
> oslo.config>=1.1.0,<2.0<br>
><br>
> because the API stability commitment is that we won't break the API<br>
> without bumping the release number to 2.0. I don't anticipate doing 2.0<br>
> soon/ever, so I've never pushed ahead with that capping.<br>
<br>
<br>
I think that capping on the major version number is acceptable, as long as<br>
we require major version bumps to break backwards compatibility... and<br>
don't do major version bumps on a regular basis.<br>
<br>
<br>
><br>
> Cheers,<br>
> Mark.<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
<br>
-Dolph<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/dca9493b/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/dca9493b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Thu, 11 Jul 2013 07:39:09 -0600<br>
From: John Griffith <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The Gate is broken: all<br>
gate-tempest-devstack-* are failing<br>
Message-ID:<br>
<<a href="mailto:CA%2BqL3LUktBfsJMy2enEeBkHDS2p1sCByU%2BpNovGLk3%2B1XetLkA@mail.gmail.com">CA+qL3LUktBfsJMy2enEeBkHDS2p1sCByU+pNovGLk3+1XetLkA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Jul 11, 2013 at 7:01 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
<br>
> On 07/11/2013 08:48 AM, John Griffith wrote:<br>
><br>
>><br>
>><br>
>><br>
>> On Thu, Jul 11, 2013 at 6:29 AM, Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a><br>
>> <mailto:<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>>> wrote:<br>
>><br>
>> Hi Sean,<br>
>><br>
>> > Cinder uncapping python-keystoneclient will get us past this.<br>
>><br>
>> There is a review exactly proposing that:<br>
>><br>
>> <a href="https://review.openstack.org/#**/c/36344/" target="_blank">https://review.openstack.org/#**/c/36344/</a><<a href="https://review.openstack.org/#/c/36344/" target="_blank">https://review.openstack.org/#/c/36344/</a>><br>
>><br>
>><br>
>> Actually for a number of reasons:<br>
>> <a href="https://review.openstack.org/#**/c/36559/" target="_blank">https://review.openstack.org/#**/c/36559/</a><<a href="https://review.openstack.org/#/c/36559/" target="_blank">https://review.openstack.org/#/c/36559/</a>>is what we needed,<br>
>> which I gave up on last night a bit after midnight when James Blair moved<br>
>> it<br>
>> to the front of the queue and it encountered a hiccup, at which point<br>
>> some other<br>
>> core Cinder folks took over baby-sitting it and it's finally through.<br>
>><br>
>><br>
>><br>
>><br>
>> > Though I'm not<br>
>> > quite sure how we got to this break point in the first place.<br>
>><br>
>><br>
>> I think this is due to the django_openstack_auth breakage that let<br>
>> this one slip by (there was for a short amount of time a >= 0.3<br>
>> requirement on python-keystoneclient from somewhere).<br>
>><br>
>> Yep, although it wasn't that short of a period of time. I also raised<br>
>> this concern<br>
>> over the ML regarding common-requirements etc and had ZERO response.<br>
>><br>
><br>
> I think the issue is that it came in the fire drill when we were running<br>
> around getting to the bottom of the last gate fail.... sorry.<br>
><br>
<br>
Didn't mean it in that way at all... my message my not have been clear<br>
anyway.<br>
<br>
><br>
> I guess I thought my full uncapping strategy might supercede just a sync<br>
> issue, no?<br>
<br>
<br>
To be honest and try to recap my opinion on this I don't really care at all<br>
how it's done, but:<br>
I *thought* the whole point of the common-requirements deal was to have<br>
EVERYBODY on the same page<br>
and avoid this very situation.<br>
<br>
However it turned out a number of projects were out of sync earlier this<br>
week so we headed in to a<br>
a bit of a death spiral. And the change that bumped it... I haven't looked<br>
back to figure out how<br>
exactly that made it in to begin with but I assume it was done by something<br>
like NOT using the<br>
requirements file to install the client or something? This is all I can<br>
figure because when I first<br>
noticed that things were out of sync on Monday I thought *ok, I'll just<br>
remove the upper bound on Cinder<br>
to match the other projects since we're ignoring common-requirements*.<br>
That didn't work because as it<br>
turns out we DO in fact have enforcement if you try and change your<br>
requirements file in a project and<br>
it doesn't match what's in the common file (a good thing in my opinion).<br>
<br>
So I sent the email regarding the state of things... then yesterday as<br>
everybody noticed things fell apart<br>
when the common-requirements file was updated BUT Cinder was not updated to<br>
match (makes sense right). So<br>
you think *sure, update common, no go update cinder etc*, well in theory<br>
that's great but with everything<br>
going on yesterday the average time to get a patch in was somewhere around<br>
2 hours or something and throw in<br>
our favorite gating bug of the month (bug 1194026, which now has over 125<br>
rechecks when combined with it's duplicate)<br>
and it didn't take 12 hours to get the change in, it took closer to 20<br>
hours.<br>
<br>
Obviously there's an opportunity here. Whether that's taking all of the<br>
requirements version information and having it ONLY<br>
come from the common-requirements file or uncapping or whatever everybody<br>
else wants to do I don't really care it just<br>
needs to be addressed.<br>
<br>
My proposal would be each projects requirements file is used as nothing<br>
more than a list of the packages it needs/wants,<br>
the common-requirements file is what's used to determine version to install<br>
and is where the actual install work is done,<br>
removing upper bounds could save a lot of issues as well, but I think there<br>
could be some consequences there as well.<br>
<br>
<br>
><br>
> -Sean<br>
><br>
> --<br>
> Sean Dague<br>
> <a href="http://dague.net" target="_blank">http://dague.net</a><br>
><br>
> ______________________________**_________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.**org <<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev" target="_blank">http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev</a><<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/f02c8989/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/f02c8989/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Thu, 11 Jul 2013 14:51:02 +0100<br>
From: Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>><br>
To: Boris Pavlovic <<a href="mailto:boris@pavlovic.me">boris@pavlovic.me</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Work around DB in OpenStack (Oslo, Nova,<br>
Cinder, Glance)<br>
Message-ID: <1373550662.2407.277.camel@sorcha><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On Thu, 2013-07-11 at 13:18 +0400, Boris Pavlovic wrote:<br>
> Mark, John, Nikola,<br>
><br>
><br>
> Current in oslo we would like to put only 2 functions:<br>
><br>
> 1) generic method for creating shadow table<br>
> 2) generic method that the columns are same in shadow and main table<br>
><br>
><br>
> So migration that adds shadow table could be done after all other<br>
> works, when we finish improving of db-archiving utils (that moves<br>
> deleted rows to shadow tables), to avoid problems that noticed<br>
> Nikola.<br>
><br>
><br>
> These 2 functions won't be affected and will be used in future in<br>
> cinder, glance and they are already used in Nova. So I don't see any<br>
> problem to push it into oslo at this moment.<br>
<br>
It's not clear to me that Cinder or Glance are planning to use these in<br>
the Havana cycle.<br>
<br>
>From afar, they both sound like they are part of the current Nova DB<br>
archiving strategy that we're saying needs improvement before it is<br>
adopted by other projects.<br>
<br>
Cheers,<br>
Mark.<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Thu, 11 Jul 2013 07:55:36 -0600<br>
From: John Griffith <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Cinder] Bug Squash day, thanks!<br>
Message-ID:<br>
<CA+qL3LWcjicFuMLFZygRSeLN_9jwTejvWtWv=<a href="mailto:gzKwamUqDSnqQ@mail.gmail.com">gzKwamUqDSnqQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Just wanted to thank all the folks that participated in the squash day<br>
yesterday!! We had a great turn out and had some new folks show up and<br>
pitch in which was great.<br>
<br>
We had a very successful go of it IMO, not only fixing quite a few bugs but<br>
find/fixing a number of new ones on the spot. The results are kinda murky<br>
right now due to the issues with things stuck in flight but we'll get that<br>
cleaned up today and should see a significant dent in our bug count.<br>
<br>
Thanks,<br>
John<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/90ef63fe/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/90ef63fe/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Thu, 11 Jul 2013 08:00:59 -0600<br>
From: John Griffith <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>><br>
To: Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Work around DB in OpenStack (Oslo, Nova,<br>
Cinder, Glance)<br>
Message-ID:<br>
<CA+qL3LVk=<a href="mailto:5FSHWZZH64NYieE9SEEEdsxJZrcNCsXT7R6Tb_7mA@mail.gmail.com">5FSHWZZH64NYieE9SEEEdsxJZrcNCsXT7R6Tb_7mA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Jul 11, 2013 at 7:51 AM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>> wrote:<br>
<br>
> On Thu, 2013-07-11 at 13:18 +0400, Boris Pavlovic wrote:<br>
> > Mark, John, Nikola,<br>
> ><br>
> ><br>
> > Current in oslo we would like to put only 2 functions:<br>
> ><br>
> > 1) generic method for creating shadow table<br>
> > 2) generic method that the columns are same in shadow and main table<br>
> ><br>
> ><br>
> > So migration that adds shadow table could be done after all other<br>
> > works, when we finish improving of db-archiving utils (that moves<br>
> > deleted rows to shadow tables), to avoid problems that noticed<br>
> > Nikola.<br>
> ><br>
> ><br>
> > These 2 functions won't be affected and will be used in future in<br>
> > cinder, glance and they are already used in Nova. So I don't see any<br>
> > problem to push it into oslo at this moment.<br>
><br>
> It's not clear to me that Cinder or Glance are planning to use these in<br>
> the Havana cycle.<br>
><br>
> From afar, they both sound like they are part of the current Nova DB<br>
> archiving strategy that we're saying needs improvement before it is<br>
> adopted by other projects.<br>
><br>
That seems pretty accurate regarding my viewpoint.<br>
<br>
><br>
> Cheers,<br>
> Mark.<br>
><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/b69d158d/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/b69d158d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Thu, 11 Jul 2013 16:04:48 +0200 (CEST)<br>
From: Sylvain Afchain <<a href="mailto:sylvain.afchain@enovance.com">sylvain.afchain@enovance.com</a>><br>
To: Brian Haley <<a href="mailto:brian.haley@hp.com">brian.haley@hp.com</a>><br>
Cc: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] Change in openstack/neutron[master]: Add<br>
method to get iptables traffic counters<br>
Message-ID:<br>
<<a href="mailto:655717889.296847.1373551488015.JavaMail.root@enovance.com">655717889.296847.1373551488015.JavaMail.root@enovance.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi Brian,<br>
<br>
You're right It could be easier with your approach to get and keep the traffic counters.<br>
<br>
I will add a new method to get the details of traffic counters of a chain.<br>
<a href="https://review.openstack.org/35624" target="_blank">https://review.openstack.org/35624</a><br>
<br>
Thoughts?<br>
<br>
Regards,<br>
<br>
Sylvain.<br>
<br>
----- Original Message -----<br>
From: "Sylvain Afchain" <<a href="mailto:sylvain.afchain@enovance.com">sylvain.afchain@enovance.com</a>><br>
To: "Brian Haley" <<a href="mailto:brian.haley@hp.com">brian.haley@hp.com</a>><br>
Cc: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Sent: Thursday, July 11, 2013 11:19:39 AM<br>
Subject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters<br>
<br>
Hi Brian,<br>
<br>
First thanks for the reviews and your detailed email.<br>
<br>
Second I will update the blueprint specs. as soon as possible, but for example it will look like that:<br>
<br>
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)<br>
pkts bytes target prot opt in out source destination<br>
55 245 metering-r-aef1456343 all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> /* jump to rules the label aef1456343 */<br>
55 245 metering-r-badf566782 all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a><br>
<br>
Chain metering-l-aef1456343 (1 references) /* the chain for the label aef1456343 */<br>
pkts bytes target prot opt in out source destination<br>
<br>
Chain metering-l-badf566782 (1 references) /* the chain for the label badf566782 */<br>
pkts bytes target prot opt in out source destination<br>
<br>
Chain metering-r-aef1456343 (1 references)<br>
pkts bytes target prot opt in out source destination<br>
20 100 RETURN all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> !<a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a> /* don't want to count this traffic */<br>
0 0 RETURN all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> !<a href="http://20.0.0.0/24" target="_blank">20.0.0.0/24</a> /* don't want to count this traffic */<br>
25 145 metering-l-aef1456343 all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> /* count the remaining traffic */<br>
<br>
Chain metering-r-badf566782 (1 references)<br>
pkts bytes target prot opt in out source destination<br>
0 0 metering-l-badf56678 all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://30.0.0.0/24" target="_blank">30.0.0.0/24</a> /* want to count only this */<br>
<br>
<br>
Of course the in/out interfaces will be set in order to get the ingress or the egress traffic.<br>
<br>
I agree with you I could add a single rule to the chain of the label and get the traffic of the first entry, though I found this approach less generic.<br>
I mean, to be forced to add a rule at the top of a chain to get its traffic. My approach is I don't want the counters of a specific rule but I want to count<br>
the traffic going through the chain.<br>
<br>
Thoughts?<br>
<br>
Regards,<br>
<br>
Sylvain.<br>
<br>
----- Original Message -----<br>
From: "Brian Haley" <<a href="mailto:brian.haley@hp.com">brian.haley@hp.com</a>><br>
To: "sylvain afchain" <<a href="mailto:sylvain.afchain@enovance.com">sylvain.afchain@enovance.com</a>><br>
Cc: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Sent: Thursday, July 11, 2013 2:30:24 AM<br>
Subject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters<br>
<br>
On 07/08/2013 01:10 PM, Sylvain Afchain (Code Review) wrote:<br>
> Sylvain Afchain has posted comments on this change.<br>
><br>
> Change subject: Add method to get iptables traffic counters<br>
<snip><br>
> --<br>
> To view, visit <a href="https://review.openstack.org/35624" target="_blank">https://review.openstack.org/35624</a><br>
<br>
Hi Sylvain,<br>
<br>
Instead of trying to ask questions directly in the review itself (since it will mess-up formatting) I'll just send this to you and the list since I had some questions on the traffic counter changes you've been doing.<br>
<br>
First, thanks for working on this, it's definitely something I'm interested in, and I'm trying to review all your changes.<br>
<br>
Second, do you have more than just the short description from the blueprint for how the iptables chains/rules will look like when created? I'm still a little confused with this change (above) and how it's matching chains to get packet/byte statistics. I'm thinking it can be done within a single chain so that you can do an 'iptables -L $chain' call to get just what you need, instead of parsing the entire table.<br>
<br>
For example, I did something similar in Nova (out of tree), and it used a single chain per-VM, such that you could get it's statistics with a single iptables call like:<br>
<br>
(sorry if this wraps)<br>
$ sudo iptables -t mangle -L nova-meter-output-91 -n -v -x [-Z]<br>
Chain nova-meter-output-91 (1 references)<br>
pkts bytes target prot opt in out source destination<br>
805210 247931149 all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> /* inst-91 packets transmitted total */<br>
15510 964648 all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> x.y.0.0/16<br>
21282 3075403 all -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> x.z.0.0/16<br>
[...]<br>
<br>
None of the rules in the chain has a jump target, so they simply count packets/bytes as they pass through, and the chain is called from a single location based on IP address, so in iptables-save format it looks like this:<br>
<br>
-A nova-meter-output -s $my_ip/32 -i bridge1 -j nova-meter-output-91<br>
-A nova-meter-output-91 -m comment --comment "inst-91 packets transmitted total"<br>
-A nova-meter-output-91 -d x.y.0.0/16<br>
-A nova-meter-output-91 -d x.z.0.0/16<br>
[...]<br>
<br>
Obviously with Neutron, and doing this at the router egress, things change, but I think it could still be done in a single OUTPUT chain in the filter table.<br>
<br>
Thoughts?<br>
<br>
-Brian<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Thu, 11 Jul 2013 10:12:04 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID: <<a href="mailto:51DEBD34.9020101@dague.net">51DEBD34.9020101@dague.net</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 07/11/2013 09:36 AM, Dolph Mathews wrote:<br>
><br>
> On Thu, Jul 11, 2013 at 6:12 AM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a><br>
> <mailto:<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>>> wrote:<br>
><br>
> On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote:<br>
> > On Wednesday, July 10, 2013, Sean Dague wrote:<br>
> ><br>
> > > Yesterday in the very exciting run around to figure out why the<br>
> gate was<br>
> > > broken, we realized something interesting. Because of the way<br>
> the gate<br>
> > > process pip requirements (one project at a time), on a current<br>
> gate run we<br>
> > > actually install and uninstall python-keystoneclient 4 times in<br>
> a normal<br>
> > > run, flipping back and forth from HEAD to 0.2.5.<br>
> > ><br>
> > ><br>
> <a href="http://paste.openstack.org/**show/39880/" target="_blank">http://paste.openstack.org/**show/39880/</a><<a href="http://paste.openstack.org/show/39880/" target="_blank">http://paste.openstack.org/show/39880/</a>>-<br>
> shows what's going on<br>
> > ><br>
> > > The net of this means that if any of the projects specify a<br>
> capped client,<br>
> > > it has the potential for preventing that client from being<br>
> tested in the<br>
> > > gate. This is very possibly part of the reason we ended up with<br>
> a broken<br>
> > > python-keystoneclient 0.3.0 released.<br>
> ><br>
> ><br>
> > > I think we need to get strict on projects and prevent them from<br>
> capping<br>
> > > their client requirements. That will also put burden on clients<br>
> that they<br>
> > > don't break backwards compatibility (which I think was a goal<br>
> regardless).<br>
> > > However there is probably going to be a bit of pain getting<br>
> from where we<br>
> > > are today, to this world.<br>
> ><br>
> ><br>
> > Thanks for investigating the underlying issue! I think the same<br>
> > policy should apply a bit further to any code we develop and consume<br>
> > ourselves as a community (oslo.config, etc). I have no doubt<br>
> that's the<br>
> > standard we strive for, but it's all too easy to throw a cap into a<br>
> > requirements file and forget about it.<br>
><br>
> I don't think we've ever capped oslo.config anywhere. Got a pointer to<br>
> what triggered that concern?<br>
><br>
><br>
> No no, I didn't mean to call you out... just using oslo.config as a<br>
> prime example of a non-client project that should (and from my<br>
> perspective: does) abide by the same policy.<br>
><br>
><br>
> We should/could be capping oslo.config like this:<br>
><br>
> oslo.config>=1.1.0,<2.0<br>
><br>
> because the API stability commitment is that we won't break the API<br>
> without bumping the release number to 2.0. I don't anticipate doing 2.0<br>
> soon/ever, so I've never pushed ahead with that capping.<br>
><br>
><br>
> I think that capping on the major version number is acceptable, as long<br>
> as we require major version bumps to break backwards compatibility...<br>
> and don't do major version bumps on a regular basis.<br>
<br>
The problem is, the gate has not good way to navigate this ATM. So the<br>
moment someone caps major versions of a client don't get tested.<br>
<br>
So let's go with complete uncapping for now, and only deal with the<br>
major version issue if it actually comes up.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Thu, 11 Jul 2013 10:28:20 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID: <<a href="mailto:51DEC104.1090503@dague.net">51DEC104.1090503@dague.net</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 07/11/2013 09:12 AM, Dirk M?ller wrote:<br>
>> Let's submit a multi-project bug on launchpad, and be serious for changing<br>
>> these global requirements in following days<br>
><br>
> <a href="https://bugs.launchpad.net/keystone/+bug/1200214" target="_blank">https://bugs.launchpad.net/keystone/+bug/1200214</a><br>
<br>
Great!<br>
<br>
This is the first review we need to land to make progress:<br>
<br>
<a href="https://review.openstack.org/#/c/36631/" target="_blank">https://review.openstack.org/#/c/36631/</a><br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Thu, 11 Jul 2013 10:29:27 -0400<br>
From: Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>><br>
To: Akshat Kakkar <<a href="mailto:the_akshat@yahoo.co.in">the_akshat@yahoo.co.in</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db<br>
methods?<br>
Message-ID: <<a href="mailto:51DEC147.3010304@redhat.com">51DEC147.3010304@redhat.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<br>
<br>
On 07/11/2013 05:23 AM, Akshat Kakkar wrote:<br>
><br>
> The methods of read/write/update/delete of records in the tables are<br>
> written using SQLalchemy only and no direct sql is used.<br>
><br>
> I have implemented the things on the lines of trusts only. Similar to<br>
> trusts, I am also having RESTful APIs and unit tests for them are<br>
> succesfully written. In test_backend_sql.py, it is seen that no unit<br>
> tests are defined for trusts. So, it's confusing for me to implement<br>
> the unit test for my backend sql code.<br>
<br>
Yeah, trusts themselves are pretty simple as far as REST, and they are<br>
exercised via the Token backend code as well as test_auth.py and<br>
test_v3_auth.py.<br>
<br>
Look at the tests for identity and catalog, those should be a better<br>
example to follow.<br>
<br>
<br>
><br>
> I know I am confusing the things and I apologise for that, but I am<br>
> asking because of that confusion only!<br>
><br>
> ------------------------------------------------------------------------<br>
> *From:* Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>><br>
> *To:* <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> *Sent:* Thursday, 11 July 2013 4:28 AM<br>
> *Subject:* Re: [openstack-dev] [Keystone] How to write unit tests for<br>
> db methods?<br>
><br>
> On 07/10/2013 06:56 AM, Akshat Kakkar wrote:<br>
>> I have added 2 tables to keystone.<br>
><br>
> This should be done in a migration, and should be tested using the<br>
> test_db_update.py file.<br>
><br>
>> I have methods which do the read/write/update/delete of records in<br>
>> these tables.<br>
> PLease explain. We are not doing direct sql, but rather using SQLalchemy.<br>
><br>
><br>
>> I want to write unit test for all this. These methods of mine inherit<br>
>> from keystone.common.sql and hence any call that these methods will<br>
>> make will go to the db returned by keystone.common.sql when creating<br>
>> a session. For writing a unit test this db should be a test db and<br>
>> not the production db. So, how can I have a session of test db? or is<br>
>> there altogether a different way of writing the unit test.<br>
> See test_backend_sql.py<br>
>><br>
>><br>
>> ------------------------------------------------------------------------<br>
>> *From:* Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>><br>
>> <mailto:<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>><br>
>> *To:* Akshat Kakkar <<a href="mailto:the_akshat@yahoo.co.in">the_akshat@yahoo.co.in</a>><br>
>> <mailto:<a href="mailto:the_akshat@yahoo.co.in">the_akshat@yahoo.co.in</a>>; OpenStack Development Mailing List<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>see<br>
>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> *Sent:* Tuesday, 9 July 2013 7:39 PM<br>
>> *Subject:* Re: [openstack-dev] [Keystone] How to write unit tests for<br>
>> db methods?<br>
>><br>
>> I'm assuming you're referring to testing backend drivers as opposed<br>
>> to database migrations (tests/test_sql_upgrade.py).<br>
>><br>
>> Backend agnostic tests land in tests/test_backend.py.<br>
>> Backend-specific tests, overrides, etc belong in<br>
>> tests/test_backend_sql.py, tests/test_backend_kvs.py, etc.<br>
>><br>
>> Generally, you can't assume that keystone is backed by a database,<br>
>> however, as it's entirely possible to deploy without one.<br>
>><br>
>><br>
>> On Tue, Jul 9, 2013 at 10:55 AM, Akshat Kakkar<br>
>> <<a href="mailto:the_akshat@yahoo.co.in">the_akshat@yahoo.co.in</a> <mailto:<a href="mailto:the_akshat@yahoo.co.in">the_akshat@yahoo.co.in</a>>> wrote:<br>
>><br>
>> How to write unit tests in keystone for the methods which are<br>
>> directly calling the backend db? I understand that for testing<br>
>> purpose it should be a *fake db*, but how to do that in keystone?<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>> -Dolph<br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/2b4b4654/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/2b4b4654/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Thu, 11 Jul 2013 10:33:45 -0400<br>
From: Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Keystone] Need help writing gate tests<br>
Message-ID: <<a href="mailto:51DEC249.5090100@redhat.com">51DEC249.5090100@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 07/11/2013 06:30 AM, Sean Dague wrote:<br>
> On 07/10/2013 11:01 PM, Clark Boylan wrote:<br>
>> On Wed, Jul 10, 2013 at 7:32 PM, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br>
>>> I want to write 3 new Jenkins gate tests: Run the Keystone unit tests<br>
>>> against<br>
>>><br>
>>> 1. A live LDAP server<br>
>>> 2. MySQL<br>
>>> 3. Postgresql<br>
>>><br>
>>> Right now, we know that the unit tests will fail against the live<br>
>>> DBs, so we<br>
>>> want those two to be non-voting. The Live LDAP one should be the<br>
>>> scheme as<br>
>>> set up by devstack, and should be voting (can be non-voting to start)<br>
>>><br>
>>> where do I start? Do I need to do this in<br>
>>> <a href="https://github.com/openstack-infra/config" target="_blank">https://github.com/openstack-infra/config</a> or<br>
>>> <a href="http://ci.openstack.org/devstack-gate.html" target="_blank">http://ci.openstack.org/devstack-gate.html</a>?<br>
>>><br>
>> Adding a Jenkins job typically involves two pieces of config in<br>
>> openstack-infra/config. First you need to add the job to the Jenkins<br>
>> Job Builder config so that the job gets into Jenkins. This is done in<br>
>> the files under<br>
>> modules/openstack_project/files/jenkins_job_builder/config. There are<br>
>> tons of examples in there and documentation can be found at<br>
>> <a href="http://ci.openstack.org/jjb.html" target="_blank">http://ci.openstack.org/jjb.html</a>. The other config that is needed is<br>
>> an update to the zuul layout.yaml file telling zuul when to run the<br>
>> jobs. The layout file is at<br>
>> modules/openstack_project/files/zuul/layout.yaml and documentation for<br>
>> that can be found at <a href="http://ci.openstack.org/zuul.html" target="_blank">http://ci.openstack.org/zuul.html</a>.<br>
>><br>
>> Our CentOS 6 and Ubuntu Precise slaves (used to run python 2.6 and 2.7<br>
>> unittests) have MySQL and PostgreSQL servers running on them and are<br>
>> available to the unittests. You can see how Nova makes use of these<br>
>> servers at<br>
>> <a href="https://github.com/openstack/nova/blob/master/nova/tests/db/test_migrations.py#L31" target="_blank">https://github.com/openstack/nova/blob/master/nova/tests/db/test_migrations.py#L31</a>.<br>
>> I prefer having opportunistic tests like Nova because it keeps the<br>
>> number of special tests in our system down. If this isn't possible<br>
>> because the tests don't currently pass you will probably want to add a<br>
>> new test that runs something like `tox -evenv -- #command to run tests<br>
>> against real DBs`.<br>
><br>
> It's not just nova.... cinder, glance, and ironic all do the same thing.<br>
><br>
> Chris Yeoh actually tried to get the same thing into keystone in both<br>
> G3 and H1, but it was blocked by the keystone team.<br>
<br>
No, he submitted a review request, we responded that more work was<br>
needed, and then the effort got overtaken by other things. We certainly<br>
didn't block him, as we are as interested in the result as he/you are.<br>
We are more than willing to work with him on that. We already have<br>
our own migration tests, and we were working together to get his patch<br>
and ours working in sync. Still planning on doing that.<br>
<br>
><br>
> I'd really look at trying to do what nova/cinder/glance/ironic all<br>
> already do here. If it has to land through oslo first, that's a thing<br>
> to do, however nova's been gating on mysql in unit tests since early<br>
> in Grizzly,<br>
We have Mysql and Postgres based integration tests, just not the unit<br>
tests. I recall we wanted to get Chris's stuff into Oslo, but I don't<br>
know what the state of that is.<br>
<br>
> so it's been proved out pretty well.<br>
><br>
> -Sean<br>
><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Thu, 11 Jul 2013 10:51:25 -0400 (EDT)<br>
From: Julie Pichon <<a href="mailto:jpichon@redhat.com">jpichon@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID:<br>
<<a href="mailto:1417739958.2470427.1373554285588.JavaMail.root@redhat.com">1417739958.2470427.1373554285588.JavaMail.root@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi Dirk,<br>
<br>
"Dirk M?ller" <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>> wrote:<br>
> > Indeed. The whole idea behind a single release channel for python client<br>
> > libraries was that you should always be running the latest, as they<br>
> > should drastically enforce backward compatibility.<br>
><br>
> Well, backward compatibility can be tricky when it comes to test.<br>
> We've for example recently had an issue where the newer keystoneclient<br>
> broke mocking in tests. It is debateable if tests are part of the<br>
> backward compatibility or not.<br>
><br>
> See for example <a href="https://bugs.launchpad.net/horizon/+bug/1196823" target="_blank">https://bugs.launchpad.net/horizon/+bug/1196823</a><br>
<br>
This is arguably a deficiency of mox, which (apparently?) doesn't let us mock properties automatically.<br>
<br>
> This is currently also preventing me from being able to get a change<br>
> on stable/grizzly past gating checks (which stumble on exactly this<br>
> "regression").<br>
<br>
The grizzly backport for the stubs has been merged [0] so patches should be unblocked now.<br>
<br>
Regards,<br>
<br>
Julie<br>
<br>
[0] <a href="https://review.openstack.org/#/c/35309/" target="_blank">https://review.openstack.org/#/c/35309/</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Thu, 11 Jul 2013 19:02:33 +0400<br>
From: Ivan Berezovskiy <<a href="mailto:iberezovskiy@mirantis.com">iberezovskiy@mirantis.com</a>><br>
To: Matthew Farrellee <<a href="mailto:matt@redhat.com">matt@redhat.com</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, "<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>"<br>
<<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>><br>
Subject: Re: [openstack-dev] [Savanna-all] [savanna-all] merging<br>
savanna-extra elements<br>
Message-ID:<br>
<CAK=NR9X-zFBa_MH5KUJfP+wOEgW=<a href="mailto:sn40J6dA2XZEbOFwn%2BVRUQ@mail.gmail.com">sn40J6dA2XZEbOFwn+VRUQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Matt,<br>
<br>
install.d is good place to install packages (like java and hadoop) and<br>
editing its configuration files. First scripts for Fedora was in<br>
subdirectory install.d too, but during installation I got error related to<br>
proc-trigger (input/output errors in proc-trigger). So I decided to change<br>
subdirectory.<br>
Regarding 70,80,90-... vs 11,12,13... This number is position of script<br>
that runs in it subdirectory. All scripts of elements in the same<br>
directories are sorted by number. So the values of these numbers are not<br>
important, but all numbers should be unique within each subdirectories.<br>
<br>
--<br>
Thanks, Ivan<br>
<br>
<br>
2013/7/10 Matthew Farrellee <<a href="mailto:matt@redhat.com">matt@redhat.com</a>><br>
<br>
> Ivan,<br>
><br>
> $ tree elements/hadoop/install.d<br>
> elements/hadoop/install.d<br>
> |-- 70-setup-java<br>
> |-- 80-setup-hadoop<br>
> `-- 90-setup-ssh<br>
> 0 directories, 3 files<br>
><br>
> $ tree elements/hadoop_fedora/post-**install.d<br>
> elements/hadoop_fedora/post-**install.d<br>
> |-- 11-setup-java<br>
> |-- 12-setup-hadoop<br>
> `-- 13-connection-setup<br>
> 0 directories, 3 files<br>
><br>
> I want to align these two directory structures and filenames.<br>
><br>
> install.d vs post-install.d, which is preferred?<br>
><br>
> 70,80,90-... vs 11,12,13-..., which is preferred?<br>
><br>
> Best,<br>
><br>
><br>
> matt<br>
><br>
> --<br>
> Mailing list: <a href="https://launchpad.net/~**savanna-all" target="_blank">https://launchpad.net/~**savanna-all</a><<a href="https://launchpad.net/~savanna-all" target="_blank">https://launchpad.net/~savanna-all</a>><br>
> Post to : savanna-all@lists.launchpad.**net<<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>><br>
> Unsubscribe : <a href="https://launchpad.net/~**savanna-all" target="_blank">https://launchpad.net/~**savanna-all</a><<a href="https://launchpad.net/~savanna-all" target="_blank">https://launchpad.net/~savanna-all</a>><br>
> More help : <a href="https://help.launchpad.net/**ListHelp" target="_blank">https://help.launchpad.net/**ListHelp</a><<a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/2baeef7c/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/2baeef7c/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Thu, 11 Jul 2013 08:16:26 -0700<br>
From: Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <<a href="mailto:20130711081626.2d36c727@caffeine.danplanet.com">20130711081626.2d36c727@caffeine.danplanet.com</a>><br>
Content-Type: text/plain; charset=US-ASCII<br>
<br>
> In the corner to my left, our current largest gate reset culprit<br>
> appears to be neutron bug #1194026 - weighing in with 62 rechecks<br>
> since June 24th (<a href="http://status.openstack.org/rechecks/" target="_blank">http://status.openstack.org/rechecks/</a>)<br>
<br>
So, with some of the highest rates of patch traffic we've seen over the<br>
last couple of weeks before the H2 deadline, I think this is really<br>
becoming a problem. I think merge times are through the roof as a<br>
result.<br>
<br>
Since the neutron gate is not a full tempest run, I think we should<br>
consider making a temporary change. I know that turning it into a<br>
non-voting job is not a popular solution, and I hate to even suggest<br>
it. However, it's just a subset of the tests anyway and I think the<br>
impact is currently overshadowing the potential for regression<br>
detection, given the relatively small amount of coverage. Is this<br>
something people would consider?<br>
<br>
Of course, the other option is to try to skip the offending test if<br>
we're running with neutron support, which may help. Since we don't know<br>
what the problem is and it *seems* to be an issue with resources not<br>
becoming available before a timeout (AIUI), I worry that this will just<br>
move the problem elsewhere.<br>
<br>
Thoughts?<br>
<br>
--Dan<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Thu, 11 Jul 2013 09:28:51 -0600<br>
From: John Griffith <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID:<br>
<<a href="mailto:CA%2BqL3LXR4a%2B7mSWRpRYhdTTPL7F7CJMhoYOTGMfDbqbLU2jasQ@mail.gmail.com">CA+qL3LXR4a+7mSWRpRYhdTTPL7F7CJMhoYOTGMfDbqbLU2jasQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br>
<br>
> > In the corner to my left, our current largest gate reset culprit<br>
> > appears to be neutron bug #1194026 - weighing in with 62 rechecks<br>
> > since June 24th (<a href="http://status.openstack.org/rechecks/" target="_blank">http://status.openstack.org/rechecks/</a>)<br>
><br>
> So, with some of the highest rates of patch traffic we've seen over the<br>
> last couple of weeks before the H2 deadline, I think this is really<br>
> becoming a problem. I think merge times are through the roof as a<br>
> result.<br>
><br>
> Since the neutron gate is not a full tempest run, I think we should<br>
> consider making a temporary change. I know that turning it into a<br>
> non-voting job is not a popular solution, and I hate to even suggest<br>
> it. However, it's just a subset of the tests anyway and I think the<br>
><br>
<br>
Well to be blunt, if there's not even anybody assigned to the defect and<br>
it's significantly impacting<br>
the progress of every other project. I don't know that it's such a bad<br>
idea. The process worked, it<br>
identified an issue, now it's known/understood however it's causing<br>
significant turmoil everywhere else.<br>
Are we gaining anything by having it continue to fail and do rechecks for<br>
the next week?<br>
<br>
impact is currently overshadowing the potential for regression<br>
> detection, given the relatively small amount of coverage. Is this<br>
> something people would consider?<br>
><br>
> Of course, the other option is to try to skip the offending test if<br>
> we're running with neutron support, which may help. Since we don't know<br>
> what the problem is and it *seems* to be an issue with resources not<br>
> becoming available before a timeout (AIUI), I worry that this will just<br>
> move the problem elsewhere.<br>
><br>
> Thoughts?<br>
><br>
> --Dan<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/2d342869/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/2d342869/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Thu, 11 Jul 2013 11:33:47 -0400<br>
From: Matthew Treinish <<a href="mailto:mtreinish@kortar.org">mtreinish@kortar.org</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <20130711153347.GA18488@kortar.treinish><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Thu, Jul 11, 2013 at 08:16:26AM -0700, Dan Smith wrote:<br>
> > In the corner to my left, our current largest gate reset culprit<br>
> > appears to be neutron bug #1194026 - weighing in with 62 rechecks<br>
> > since June 24th (<a href="http://status.openstack.org/rechecks/" target="_blank">http://status.openstack.org/rechecks/</a>)<br>
><br>
> So, with some of the highest rates of patch traffic we've seen over the<br>
> last couple of weeks before the H2 deadline, I think this is really<br>
> becoming a problem. I think merge times are through the roof as a<br>
> result.<br>
><br>
> Since the neutron gate is not a full tempest run, I think we should<br>
> consider making a temporary change. I know that turning it into a<br>
> non-voting job is not a popular solution, and I hate to even suggest<br>
> it. However, it's just a subset of the tests anyway and I think the<br>
> impact is currently overshadowing the potential for regression<br>
> detection, given the relatively small amount of coverage. Is this<br>
> something people would consider?<br>
<br>
I don't think this is the way to go. Even though it's limited coverage<br>
without it Neutron would have no gating integrated testing run on it at all.<br>
In my experience this will just cause more difficulty down the road when<br>
we decide to switch it back to voting. Things tend to bit rot fairly quickly.<br>
<br>
><br>
> Of course, the other option is to try to skip the offending test if<br>
> we're running with neutron support, which may help. Since we don't know<br>
> what the problem is and it *seems* to be an issue with resources not<br>
> becoming available before a timeout (AIUI), I worry that this will just<br>
> move the problem elsewhere.<br>
<br>
So if it is a single test (or set of tests) failing then this is doable. We<br>
can do this in the short term, but if it just moves the problem elsewhere then<br>
we're just in the same situation right? So what's the harm in trying this?<br>
<br>
><br>
> Thoughts?<br>
><br>
> --Dan<br>
><br>
<br>
-Matt Treinish<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Thu, 11 Jul 2013 17:35:39 +0200<br>
From: Dirk M?ller <<a href="mailto:dirk@dmllr.de">dirk@dmllr.de</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] The danger of capping python-*clients in<br>
core projects, and forbidding it in the future<br>
Message-ID:<br>
<CAL5wTH4_PmcoM0OySNT22bgxetTrdbUsC=<a href="mailto:LD0Hcd4Dn0nnHnDQ@mail.gmail.com">LD0Hcd4Dn0nnHnDQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
>> See for example <a href="https://bugs.launchpad.net/horizon/+bug/1196823" target="_blank">https://bugs.launchpad.net/horizon/+bug/1196823</a><br>
> This is arguably a deficiency of mox, which (apparently?) doesn't let us mock properties automatically.<br>
<br>
I agree, but it is just one example. other test-only issues can happen as well.<br>
<br>
Similar problem: the *client packages are not self-contained, they<br>
have pretty strict dependencies on other packages. One case I already<br>
run into was a dependency on python-requests: newer python-*client<br>
packages (rightfully) require requests >= 1.x. running those on a<br>
system that has OpenStack services from Grizzly or Folsom installed<br>
cause a conflict: there are one or two that require requests to be <<br>
1.0.<br>
<br>
When you run gating on this scenario, I think the same flipping would<br>
happen on e.g. requests as well, due to *client or the module being<br>
installed in varying order.<br>
<br>
Greetings,<br>
Dirk<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Thu, 11 Jul 2013 11:38:25 -0400<br>
From: Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <<a href="mailto:51DED171.1000500@redhat.com">51DED171.1000500@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 07/11/2013 11:28 AM, John Griffith wrote:<br>
><br>
><br>
><br>
> On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a><br>
> <mailto:<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>>> wrote:<br>
><br>
> > In the corner to my left, our current largest gate reset culprit<br>
> > appears to be neutron bug #1194026 - weighing in with 62 rechecks<br>
> > since June 24th (<a href="http://status.openstack.org/rechecks/" target="_blank">http://status.openstack.org/rechecks/</a>)<br>
><br>
> So, with some of the highest rates of patch traffic we've seen over the<br>
> last couple of weeks before the H2 deadline, I think this is really<br>
> becoming a problem. I think merge times are through the roof as a<br>
> result.<br>
><br>
> Since the neutron gate is not a full tempest run, I think we should<br>
> consider making a temporary change. I know that turning it into a<br>
> non-voting job is not a popular solution, and I hate to even suggest<br>
> it. However, it's just a subset of the tests anyway and I think the<br>
><br>
><br>
> Well to be blunt, if there's not even anybody assigned to the defect and<br>
> it's significantly impacting<br>
> the progress of every other project. I don't know that it's such a bad<br>
> idea. The process worked, it<br>
> identified an issue, now it's known/understood however it's causing<br>
> significant turmoil everywhere else.<br>
> Are we gaining anything by having it continue to fail and do rechecks<br>
> for the next week?<br>
<br>
+1 to making it non-voting until this is resolved. This is a sensitive<br>
week for gate and check times.<br>
<br>
> impact is currently overshadowing the potential for regression<br>
> detection, given the relatively small amount of coverage. Is this<br>
> something people would consider?<br>
><br>
> Of course, the other option is to try to skip the offending test if<br>
> we're running with neutron support, which may help. Since we don't know<br>
> what the problem is and it *seems* to be an issue with resources not<br>
> becoming available before a timeout (AIUI), I worry that this will just<br>
> move the problem elsewhere.<br>
<br>
Disabling a specific test would be preferred IMO, but if that's not<br>
sufficient, I'd +1 downgrading the whole thing to non-voting for now.<br>
<br>
--<br>
Russell Bryant<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Thu, 11 Jul 2013 16:46:05 +0100<br>
From: Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <1373557565.2407.285.camel@sorcha><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On Thu, 2013-07-11 at 09:28 -0600, John Griffith wrote:<br>
> On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br>
><br>
> > > In the corner to my left, our current largest gate reset culprit<br>
> > > appears to be neutron bug #1194026 - weighing in with 62 rechecks<br>
> > > since June 24th (<a href="http://status.openstack.org/rechecks/" target="_blank">http://status.openstack.org/rechecks/</a>)<br>
> ><br>
> > So, with some of the highest rates of patch traffic we've seen over the<br>
> > last couple of weeks before the H2 deadline, I think this is really<br>
> > becoming a problem. I think merge times are through the roof as a<br>
> > result.<br>
> ><br>
> > Since the neutron gate is not a full tempest run, I think we should<br>
> > consider making a temporary change. I know that turning it into a<br>
> > non-voting job is not a popular solution, and I hate to even suggest<br>
> > it. However, it's just a subset of the tests anyway and I think the<br>
> ><br>
><br>
> Well to be blunt, if there's not even anybody assigned to the defect and<br>
> it's significantly impacting<br>
> the progress of every other project. I don't know that it's such a bad<br>
> idea. The process worked, it<br>
> identified an issue, now it's known/understood however it's causing<br>
> significant turmoil everywhere else.<br>
> Are we gaining anything by having it continue to fail and do rechecks for<br>
> the next week?<br>
<br>
I feel a similar way to this as I do about regressions for which we've<br>
identified a root cause patch, even though it's a completely separate<br>
thing. In those cases, we should take decisive action to revert quickly.<br>
<br>
This is holding people up, there's level of failure is unacceptable,<br>
continuing to frustrate people is not going to get it fixed faster. In<br>
this case, we should take decisive action and make it non-voting<br>
quickly.<br>
<br>
Cheers,<br>
Mark.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Thu, 11 Jul 2013 08:46:59 -0700<br>
From: Chris Behrens <<a href="mailto:cbehrens@codestud.com">cbehrens@codestud.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <<a href="mailto:2D04BE0E-220D-4C90-B8C1-B8C6E55A0998@codestud.com">2D04BE0E-220D-4C90-B8C1-B8C6E55A0998@codestud.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
<br>
On Jul 11, 2013, at 8:28 AM, John Griffith <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>> wrote:<br>
<br>
><br>
><br>
><br>
> On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br>
> > In the corner to my left, our current largest gate reset culprit<br>
> > appears to be neutron bug #1194026 - weighing in with 62 rechecks<br>
> > since June 24th (<a href="http://status.openstack.org/rechecks/" target="_blank">http://status.openstack.org/rechecks/</a>)<br>
><br>
> So, with some of the highest rates of patch traffic we've seen over the<br>
> last couple of weeks before the H2 deadline, I think this is really<br>
> becoming a problem. I think merge times are through the roof as a<br>
> result.<br>
><br>
> Since the neutron gate is not a full tempest run, I think we should<br>
> consider making a temporary change. I know that turning it into a<br>
> non-voting job is not a popular solution, and I hate to even suggest<br>
> it. However, it's just a subset of the tests anyway and I think the<br>
><br>
> Well to be blunt, if there's not even anybody assigned to the defect and it's significantly impacting<br>
> the progress of every other project. I don't know that it's such a bad idea. The process worked, it<br>
> identified an issue, now it's known/understood however it's causing significant turmoil everywhere else.<br>
> Are we gaining anything by having it continue to fail and do rechecks for the next week?<br>
<br>
+1<br>
<br>
><br>
> impact is currently overshadowing the potential for regression<br>
> detection, given the relatively small amount of coverage. Is this<br>
> something people would consider?<br>
><br>
> Of course, the other option is to try to skip the offending test if<br>
> we're running with neutron support, which may help. Since we don't know<br>
> what the problem is and it *seems* to be an issue with resources not<br>
> becoming available before a timeout (AIUI), I worry that this will just<br>
> move the problem elsewhere.<br>
><br>
<br>
This would be a lot better if that's possible. But if not, disable the whole thing.<br>
<br>
It's definitely a huge waste of resources to run a bunch of tests that fail repeatedly and cause us to have to re-check and use even more resources. I don't really like waiting 10 hours for patches to merge.<br>
<br>
- Chris<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/31a93061/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/31a93061/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Thu, 11 Jul 2013 11:52:52 -0400<br>
From: Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <<a href="mailto:51DED4D4.4070808@redhat.com">51DED4D4.4070808@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 07/11/2013 11:46 AM, Mark McLoughlin wrote:<br>
> On Thu, 2013-07-11 at 09:28 -0600, John Griffith wrote:<br>
>> On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br>
>><br>
>>>> In the corner to my left, our current largest gate reset culprit<br>
>>>> appears to be neutron bug #1194026 - weighing in with 62 rechecks<br>
>>>> since June 24th (<a href="http://status.openstack.org/rechecks/" target="_blank">http://status.openstack.org/rechecks/</a>)<br>
>>><br>
>>> So, with some of the highest rates of patch traffic we've seen over the<br>
>>> last couple of weeks before the H2 deadline, I think this is really<br>
>>> becoming a problem. I think merge times are through the roof as a<br>
>>> result.<br>
>>><br>
>>> Since the neutron gate is not a full tempest run, I think we should<br>
>>> consider making a temporary change. I know that turning it into a<br>
>>> non-voting job is not a popular solution, and I hate to even suggest<br>
>>> it. However, it's just a subset of the tests anyway and I think the<br>
>>><br>
>><br>
>> Well to be blunt, if there's not even anybody assigned to the defect and<br>
>> it's significantly impacting<br>
>> the progress of every other project. I don't know that it's such a bad<br>
>> idea. The process worked, it<br>
>> identified an issue, now it's known/understood however it's causing<br>
>> significant turmoil everywhere else.<br>
>> Are we gaining anything by having it continue to fail and do rechecks for<br>
>> the next week?<br>
><br>
> I feel a similar way to this as I do about regressions for which we've<br>
> identified a root cause patch, even though it's a completely separate<br>
> thing. In those cases, we should take decisive action to revert quickly.<br>
><br>
> This is holding people up, there's level of failure is unacceptable,<br>
> continuing to frustrate people is not going to get it fixed faster. In<br>
> this case, we should take decisive action and make it non-voting<br>
> quickly.<br>
<br>
Change to make it non-voting proposed here:<br>
<br>
<a href="https://review.openstack.org/36685" target="_blank">https://review.openstack.org/36685</a><br>
<br>
--<br>
Russell Bryant<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Thu, 11 Jul 2013 09:53:00 -0600<br>
From: John Griffith <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID:<br>
<CA+qL3LWWLGnzwz3aCnttCM-b-Uo=<a href="mailto:0UXwycRi9KkfnTT6ec-vrA@mail.gmail.com">0UXwycRi9KkfnTT6ec-vrA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Jul 11, 2013 at 9:38 AM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
<br>
> On 07/11/2013 11:28 AM, John Griffith wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a><br>
> > <mailto:<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>>> wrote:<br>
> ><br>
> > > In the corner to my left, our current largest gate reset culprit<br>
> > > appears to be neutron bug #1194026 - weighing in with 62 rechecks<br>
> > > since June 24th (<a href="http://status.openstack.org/rechecks/" target="_blank">http://status.openstack.org/rechecks/</a>)<br>
> ><br>
> > So, with some of the highest rates of patch traffic we've seen over<br>
> the<br>
> > last couple of weeks before the H2 deadline, I think this is really<br>
> > becoming a problem. I think merge times are through the roof as a<br>
> > result.<br>
> ><br>
> > Since the neutron gate is not a full tempest run, I think we should<br>
> > consider making a temporary change. I know that turning it into a<br>
> > non-voting job is not a popular solution, and I hate to even suggest<br>
> > it. However, it's just a subset of the tests anyway and I think the<br>
> ><br>
> ><br>
> > Well to be blunt, if there's not even anybody assigned to the defect and<br>
> > it's significantly impacting<br>
> > the progress of every other project. I don't know that it's such a bad<br>
> > idea. The process worked, it<br>
> > identified an issue, now it's known/understood however it's causing<br>
> > significant turmoil everywhere else.<br>
> > Are we gaining anything by having it continue to fail and do rechecks<br>
> > for the next week?<br>
><br>
> +1 to making it non-voting until this is resolved. This is a sensitive<br>
> week for gate and check times.<br>
><br>
> > impact is currently overshadowing the potential for regression<br>
> > detection, given the relatively small amount of coverage. Is this<br>
> > something people would consider?<br>
> ><br>
> > Of course, the other option is to try to skip the offending test if<br>
> > we're running with neutron support, which may help. Since we don't<br>
> know<br>
> > what the problem is and it *seems* to be an issue with resources not<br>
> > becoming available before a timeout (AIUI), I worry that this will<br>
> just<br>
> > move the problem elsewhere.<br>
><br>
> Disabling a specific test would be preferred IMO, but if that's not<br>
> sufficient, I'd +1 downgrading the whole thing to non-voting for now.<br>
><br>
<br>
Excellent point, test_008_check_public_network_connectivity. If it's<br>
possible to log the results but not fail the gate for this I think that<br>
would be ideal, otherwise skip that test for now.<br>
<br>
><br>
> --<br>
> Russell Bryant<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/db48c7d3/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/db48c7d3/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Thu, 11 Jul 2013 11:54:20 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <<a href="mailto:51DED52C.2000003@dague.net">51DED52C.2000003@dague.net</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 07/11/2013 11:33 AM, Matthew Treinish wrote:<br>
> On Thu, Jul 11, 2013 at 08:16:26AM -0700, Dan Smith wrote:<br>
>>> In the corner to my left, our current largest gate reset culprit<br>
>>> appears to be neutron bug #1194026 - weighing in with 62 rechecks<br>
>>> since June 24th (<a href="http://status.openstack.org/rechecks/" target="_blank">http://status.openstack.org/rechecks/</a>)<br>
>><br>
>> So, with some of the highest rates of patch traffic we've seen over the<br>
>> last couple of weeks before the H2 deadline, I think this is really<br>
>> becoming a problem. I think merge times are through the roof as a<br>
>> result.<br>
>><br>
>> Since the neutron gate is not a full tempest run, I think we should<br>
>> consider making a temporary change. I know that turning it into a<br>
>> non-voting job is not a popular solution, and I hate to even suggest<br>
>> it. However, it's just a subset of the tests anyway and I think the<br>
>> impact is currently overshadowing the potential for regression<br>
>> detection, given the relatively small amount of coverage. Is this<br>
>> something people would consider?<br>
><br>
> I don't think this is the way to go. Even though it's limited coverage<br>
> without it Neutron would have no gating integrated testing run on it at all.<br>
> In my experience this will just cause more difficulty down the road when<br>
> we decide to switch it back to voting. Things tend to bit rot fairly quickly.<br>
><br>
>><br>
>> Of course, the other option is to try to skip the offending test if<br>
>> we're running with neutron support, which may help. Since we don't know<br>
>> what the problem is and it *seems* to be an issue with resources not<br>
>> becoming available before a timeout (AIUI), I worry that this will just<br>
>> move the problem elsewhere.<br>
><br>
> So if it is a single test (or set of tests) failing then this is doable. We<br>
> can do this in the short term, but if it just moves the problem elsewhere then<br>
> we're just in the same situation right? So what's the harm in trying this?<br>
<br>
Let's start with the test skip.<br>
<br>
I am however pretty frustrated that we're really not getting anyone from<br>
neutron looking at this. We're at 121 rechecks (plus I'm sure there were<br>
plenty of no bug rechecks, I've seen a couple). So 150+ gate resets<br>
because of this bug. Which is 150hrs worth of delay put into the gate.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 30<br>
Date: Thu, 11 Jul 2013 12:06:10 -0400 (EDT)<br>
From: William Henry <<a href="mailto:whenry@redhat.com">whenry@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] AMQP Version upgrade plans?<br>
Message-ID:<br>
<<a href="mailto:1294823910.2781463.1373558770878.JavaMail.root@redhat.com">1294823910.2781463.1373558770878.JavaMail.root@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
<br>
----- Original Message -----<br>
> On 07/08/2013 10:51 AM, Ted Ross wrote:<br>
> > If someone from the Qpid community were to work on integrating the new<br>
> > AMQP 1.0 technology into OpenStack, where would be the right place to<br>
> > start? Would it be to add a new transport to oslo.messaging?<br>
><br>
> I think so, yes. oslo.messaging is new, but it will deprecate the<br>
> existing 'rpc' library in oslo-incubator. All projects will need to<br>
> move to oslo.messaging, so for something new I would focus efforts there.<br>
<br>
I think that one of the important points that Ted brought up is that AMQP 1.0 doesn't have the concepts of broker artifacts like exchanges etc.<br>
<br>
A recent change I proposed to the existing impl_qpid.py which focuses more on addressing and not exchanges is a very important first step to solve several issues: a recent qpidd leak issue, transitioning to AMQP 1.0 (addressing), and possible HA solutions.<br>
<br>
This is an area I'd really like to continue to help out in. I'm back from some vacation and would like to get stuck in soon.<br>
<br>
William<br>
<br>
><br>
> --<br>
> Russell Bryant<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 31<br>
Date: Thu, 11 Jul 2013 12:09:09 -0400<br>
From: Matthew Farrellee <<a href="mailto:matt@redhat.com">matt@redhat.com</a>><br>
To: Ivan Berezovskiy <<a href="mailto:iberezovskiy@mirantis.com">iberezovskiy@mirantis.com</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, "<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>"<br>
<<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>><br>
Subject: Re: [openstack-dev] [Savanna-all] [savanna-all] merging<br>
savanna-extra elements<br>
Message-ID: <<a href="mailto:51DED8A5.80600@redhat.com">51DED8A5.80600@redhat.com</a>><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
Ivan,<br>
<br>
Ok. I've gone through and successfully built and run an image using<br>
install.d on Fedora. Let me know if you still get the error using<br>
install.d. I hope it was just a transient issue.<br>
<br>
FYI, I used DIB at f6cc6bb1.<br>
<br>
Best,<br>
<br>
<br>
matt<br>
<br>
On 07/11/2013 11:02 AM, Ivan Berezovskiy wrote:<br>
> Matt,<br>
><br>
> install.d is good place to install packages (like java and hadoop) and<br>
> editing its configuration files. First scripts for Fedora was in<br>
> subdirectory install.d too, but during installation I got error related<br>
> to proc-trigger (input/output errors in proc-trigger). So I decided to<br>
> change subdirectory.<br>
> Regarding 70,80,90-... vs 11,12,13... This number is position of script<br>
> that runs in it subdirectory. All scripts of elements in the same<br>
> directories are sorted by number. So the values of these numbers are not<br>
> important, but all numbers should be unique within each subdirectories.<br>
><br>
> --<br>
> Thanks, Ivan<br>
><br>
><br>
> 2013/7/10 Matthew Farrellee <<a href="mailto:matt@redhat.com">matt@redhat.com</a> <mailto:<a href="mailto:matt@redhat.com">matt@redhat.com</a>>><br>
><br>
> Ivan,<br>
><br>
> $ tree elements/hadoop/install.d<br>
> elements/hadoop/install.d<br>
> |-- 70-setup-java<br>
> |-- 80-setup-hadoop<br>
> `-- 90-setup-ssh<br>
> 0 directories, 3 files<br>
><br>
> $ tree elements/hadoop_fedora/post-__install.d<br>
> elements/hadoop_fedora/post-__install.d<br>
> |-- 11-setup-java<br>
> |-- 12-setup-hadoop<br>
> `-- 13-connection-setup<br>
> 0 directories, 3 files<br>
><br>
> I want to align these two directory structures and filenames.<br>
><br>
> install.d vs post-install.d, which is preferred?<br>
><br>
> 70,80,90-... vs 11,12,13-..., which is preferred?<br>
><br>
> Best,<br>
><br>
><br>
> matt<br>
><br>
> --<br>
> Mailing list: <a href="https://launchpad.net/~__savanna-all" target="_blank">https://launchpad.net/~__savanna-all</a><br>
> <<a href="https://launchpad.net/~savanna-all" target="_blank">https://launchpad.net/~savanna-all</a>><br>
> Post to : savanna-all@lists.launchpad.__net<br>
> <mailto:<a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a>><br>
> Unsubscribe : <a href="https://launchpad.net/~__savanna-all" target="_blank">https://launchpad.net/~__savanna-all</a><br>
> <<a href="https://launchpad.net/~savanna-all" target="_blank">https://launchpad.net/~savanna-all</a>><br>
> More help : <a href="https://help.launchpad.net/__ListHelp" target="_blank">https://help.launchpad.net/__ListHelp</a><br>
> <<a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a>><br>
><br>
><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 32<br>
Date: Thu, 11 Jul 2013 12:11:25 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <<a href="mailto:51DED92D.20503@dague.net">51DED92D.20503@dague.net</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 07/11/2013 11:54 AM, Sean Dague wrote:<br>
> On 07/11/2013 11:33 AM, Matthew Treinish wrote:<br>
>> On Thu, Jul 11, 2013 at 08:16:26AM -0700, Dan Smith wrote:<br>
>>>> In the corner to my left, our current largest gate reset culprit<br>
>>>> appears to be neutron bug #1194026 - weighing in with 62 rechecks<br>
>>>> since June 24th (<a href="http://status.openstack.org/rechecks/" target="_blank">http://status.openstack.org/rechecks/</a>)<br>
>>><br>
>>> So, with some of the highest rates of patch traffic we've seen over the<br>
>>> last couple of weeks before the H2 deadline, I think this is really<br>
>>> becoming a problem. I think merge times are through the roof as a<br>
>>> result.<br>
>>><br>
>>> Since the neutron gate is not a full tempest run, I think we should<br>
>>> consider making a temporary change. I know that turning it into a<br>
>>> non-voting job is not a popular solution, and I hate to even suggest<br>
>>> it. However, it's just a subset of the tests anyway and I think the<br>
>>> impact is currently overshadowing the potential for regression<br>
>>> detection, given the relatively small amount of coverage. Is this<br>
>>> something people would consider?<br>
>><br>
>> I don't think this is the way to go. Even though it's limited coverage<br>
>> without it Neutron would have no gating integrated testing run on it<br>
>> at all.<br>
>> In my experience this will just cause more difficulty down the road when<br>
>> we decide to switch it back to voting. Things tend to bit rot fairly<br>
>> quickly.<br>
>><br>
>>><br>
>>> Of course, the other option is to try to skip the offending test if<br>
>>> we're running with neutron support, which may help. Since we don't know<br>
>>> what the problem is and it *seems* to be an issue with resources not<br>
>>> becoming available before a timeout (AIUI), I worry that this will just<br>
>>> move the problem elsewhere.<br>
>><br>
>> So if it is a single test (or set of tests) failing then this is<br>
>> doable. We<br>
>> can do this in the short term, but if it just moves the problem<br>
>> elsewhere then<br>
>> we're just in the same situation right? So what's the harm in trying<br>
>> this?<br>
><br>
> Let's start with the test skip.<br>
><br>
> I am however pretty frustrated that we're really not getting anyone from<br>
> neutron looking at this. We're at 121 rechecks (plus I'm sure there were<br>
> plenty of no bug rechecks, I've seen a couple). So 150+ gate resets<br>
> because of this bug. Which is 150hrs worth of delay put into the gate.<br>
<br>
Actually, I'm revising my point of view. If we skip the test, people<br>
can't debug in the gate. if we make the job non-voting, the neutron team<br>
can submit patches up and run rechecks on them to try to reproduce the fail.<br>
<br>
So let's go non-voting here.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 33<br>
Date: Thu, 11 Jul 2013 17:05:14 +0100<br>
From: Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>><br>
To: Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>>, OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: Gary Kotton <<a href="mailto:gary.kotton@gmail.com">gary.kotton@gmail.com</a>>, Sumit Naiksatam<br>
<<a href="mailto:sumit.naiksatam@bigswitch.com">sumit.naiksatam@bigswitch.com</a>>, yong sheng gong<br>
<<a href="mailto:gongysh@unitedstack.com">gongysh@unitedstack.com</a>>, Nachi Ueno <<a href="mailto:nachi@nttmcl.com">nachi@nttmcl.com</a>>, Robert<br>
Kukura <<a href="mailto:rkukura@redhat.com">rkukura@redhat.com</a>><br>
Subject: Re: [openstack-dev] Bug #1194026<br>
Message-ID:<br>
<CAGR=<a href="mailto:i3ghvfOTwqvxP%2B7z8s4Lffc5VrgM49u9rQUYDPRVt6_9vA@mail.gmail.com">i3ghvfOTwqvxP+7z8s4Lffc5VrgM49u9rQUYDPRVt6_9vA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Adding openstack-dev to this discussion thread.<br>
Looks like the test is going to be skipped at the moment, but we probably<br>
need to consider raising the priority of this issue and assign our cores<br>
with more experience with tempest/gating on this.<br>
<br>
salvatore<br>
<br>
<br>
On 9 July 2013 22:48, Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>> wrote:<br>
<br>
> My suggestion is that the quantum exercise script be disabled for now if<br>
> that will allow the tempest test to run, since the tempest test is more<br>
> useful (it does an ssh check to ensure that the metadata service has<br>
> configured the VM). Doing so would allow useful gating while we look at<br>
> resolving the timing bug.<br>
><br>
><br>
> m.<br>
><br>
> On Jul 9, 2013, at 5:42 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
><br>
> > Hi Maru<br>
> ><br>
> > The gating test will not fail everytime. Sometimes, both of tests<br>
> > works, sometimes not.<br>
> > In this test, execise.sh works and tempest don't works.<br>
> > I'm still not sure is there any dependencies in this failure or not.<br>
> ><br>
> > So I'm assuming this is kind of timing issue..<br>
> ><br>
> > hmm this kind of bug is hard to fix..<br>
> ><br>
> ><br>
> > 2013/7/9 Maru Newby <<a href="mailto:marun@redhat.com">marun@redhat.com</a>>:<br>
> >> If there is a conflict between the exercise test and the tempest test,<br>
> does the tempest test pass if the exercise script isn't run beforehand?<br>
> >><br>
> >><br>
> >> m.<br>
> >><br>
> >> On Jul 9, 2013, at 5:20 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
> >><br>
> >>> Hi<br>
> >>><br>
> >>> I checked briefly, and it looks some timing bug of l3-agent.<br>
> >>> I added note on the bug report.<br>
> >>> <a href="https://bugs.launchpad.net/neutron/+bug/1194026" target="_blank">https://bugs.launchpad.net/neutron/+bug/1194026</a><br>
> >>><br>
> >>> 2013/7/9 Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>>:<br>
> >>>> Sean Dague singled it out as the biggest cause for gate failures, and<br>
> >>>> invited us to have a look at it.<br>
> >>>> I've raised its importance to high, but I don't have the cycles to<br>
> look at<br>
> >>>> it in the short term.<br>
> >>>> It would be really if somebody from the core team finds some time to<br>
> triage<br>
> >>>> it.<br>
> >>>><br>
> >>>> Salvatore<br>
> >><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/7529dda8/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/7529dda8/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 34<br>
Date: Thu, 11 Jul 2013 18:49:25 +0200<br>
From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <<a href="mailto:51DEE215.2080006@openstack.org">51DEE215.2080006@openstack.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
John Griffith wrote:<br>
> Well to be blunt, if there's not even anybody assigned to the defect and<br>
> it's significantly impacting<br>
> the progress of every other project. I don't know that it's such a bad<br>
> idea.<br>
<br>
There is someone assigned to it since it was raised at the release<br>
meeting. He doesn't seem to make a lot of progress though.<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 35<br>
Date: Thu, 11 Jul 2013 18:53:58 +0200<br>
From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <<a href="mailto:51DEE326.7020507@openstack.org">51DEE326.7020507@openstack.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Sean Dague wrote:<br>
> On 07/11/2013 11:54 AM, Sean Dague wrote:<br>
>> Let's start with the test skip.<br>
>><br>
>> I am however pretty frustrated that we're really not getting anyone from<br>
>> neutron looking at this. We're at 121 rechecks (plus I'm sure there were<br>
>> plenty of no bug rechecks, I've seen a couple). So 150+ gate resets<br>
>> because of this bug. Which is 150hrs worth of delay put into the gate.<br>
><br>
> Actually, I'm revising my point of view. If we skip the test, people<br>
> can't debug in the gate. if we make the job non-voting, the neutron team<br>
> can submit patches up and run rechecks on them to try to reproduce the<br>
> fail.<br>
><br>
> So let's go non-voting here.<br>
<br>
The problem with this approach is that you'll fail to notice OTHER<br>
(genuine) issues that your patch introduces, since you'll be trained to<br>
ignore that line (and not necessarily look into the details).<br>
<br>
Disabling only the flaky test sounds like a better way to go to me. Yes<br>
it makes fixing the flaky test slightly more difficult, but at least it<br>
doesn't increase the regression risk.<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 36<br>
Date: Thu, 11 Jul 2013 12:12:18 -0500<br>
From: Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [keystone] sqlite doesn't support migrations<br>
Message-ID:<br>
<CAC=<a href="mailto:h7gVxug-zHA3aCiLB1_JSGggavibQ6%2BzmZuwvnZTk2ujFbw@mail.gmail.com">h7gVxug-zHA3aCiLB1_JSGggavibQ6+zmZuwvnZTk2ujFbw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Just as a general statement, outside the scope of openstack, I don't think<br>
sqlite is intended to support schema evolution. From the sqlite docs [1]:<br>
"SQLite supports a limited subset of ALTER TABLE. [...] It is not possible<br>
to rename a column, remove a column, or add or remove constraints from a<br>
table."<br>
<br>
We've been through hell trying to support migrations on sqlite, because we<br>
test against sqlite, and because we test our migrations... on sqlite. So,<br>
we've already shot ourselves in the foot. We're clearly moving towards<br>
gating against mysql + postgresql, so in the mean time, let's limit the<br>
amount of effort we put into further support sqlite migrations until we can<br>
safely rip it out altogether.<br>
<br>
[1]: <a href="http://www.sqlite.org/lang_altertable.html" target="_blank">http://www.sqlite.org/lang_altertable.html</a><br>
<br>
-Dolph<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/6f9054f3/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/6f9054f3/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 37<br>
Date: Thu, 11 Jul 2013 10:37:56 -0700<br>
From: Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID:<br>
<CABJepwgJd-bN9qhLF=<a href="mailto:sQCV__chHCEdX%2B05FdOkEGMYmPFcF6rg@mail.gmail.com">sQCV__chHCEdX+05FdOkEGMYmPFcF6rg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi Sean<br>
<br>
Sorry for it taking long time to fixing this problem.<br>
At least, 3 neutron core dev is working on this issue, but<br>
it is kind of timing issue so we are struggling to replicate it.<br>
<br>
I'm also OK to move it for non-voting now.<br>
<br>
<br>
2013/7/11 Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>>:<br>
> Sean Dague wrote:<br>
>> On 07/11/2013 11:54 AM, Sean Dague wrote:<br>
>>> Let's start with the test skip.<br>
>>><br>
>>> I am however pretty frustrated that we're really not getting anyone from<br>
>>> neutron looking at this. We're at 121 rechecks (plus I'm sure there were<br>
>>> plenty of no bug rechecks, I've seen a couple). So 150+ gate resets<br>
>>> because of this bug. Which is 150hrs worth of delay put into the gate.<br>
>><br>
>> Actually, I'm revising my point of view. If we skip the test, people<br>
>> can't debug in the gate. if we make the job non-voting, the neutron team<br>
>> can submit patches up and run rechecks on them to try to reproduce the<br>
>> fail.<br>
>><br>
>> So let's go non-voting here.<br>
><br>
> The problem with this approach is that you'll fail to notice OTHER<br>
> (genuine) issues that your patch introduces, since you'll be trained to<br>
> ignore that line (and not necessarily look into the details).<br>
><br>
> Disabling only the flaky test sounds like a better way to go to me. Yes<br>
> it makes fixing the flaky test slightly more difficult, but at least it<br>
> doesn't increase the regression risk.<br>
><br>
> --<br>
> Thierry Carrez (ttx)<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 38<br>
Date: Thu, 11 Jul 2013 10:45:49 -0700<br>
From: Mark Washenberger <<a href="mailto:mark.washenberger@markwash.net">mark.washenberger@markwash.net</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Glance] Meeting Reminder<br>
Message-ID:<br>
<CAJyP2C8DHhr9=<a href="mailto:9hSPddxDVrorPodGciP6X77OrYQ8-XMREW9Ww@mail.gmail.com">9hSPddxDVrorPodGciP6X77OrYQ8-XMREW9Ww@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi folks,<br>
<br>
We will be having a glance team meeting in #openstack-meeting-alt at 2000<br>
UTC today. The main topic for today is figuring out what we need to do to<br>
get our last blueprints completed for the Havana 2 milestone.<br>
<br>
Please accept my apologies for the lateness of this reminder.<br>
<br>
markwash<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/2b173af4/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/2b173af4/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 39<br>
Date: Fri, 12 Jul 2013 02:18:52 +0800<br>
From: Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Cc: Jan Dittberner <<a href="mailto:jandd@debian.org">jandd@debian.org</a>><br>
Subject: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID: <<a href="mailto:51DEF70C.4070206@debian.org">51DEF70C.4070206@debian.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi,<br>
<br>
Discussing with Jan Dittberner, who is upstream for sqlalchemy-migrate,<br>
it appears that he doesn't have time to maintain it.<br>
<br>
Is the OpenStack project willing to take over? Jan is ok to hand over<br>
everything, moving to Github, give access to Pypi, etc. Below is his<br>
reply to me when I asked him.<br>
<br>
Or is the OpenStack project moving toward Alembic as well?<br>
<br>
Thoughts anyone?<br>
<br>
Thomas Goirand (zigo)<br>
<br>
On 07/12/2013 01:27 AM, Jan Dittberner wrote:<br>
> I would be very happy to hand over the maintenance of sqlalchemy-migrate to<br>
> a team that actually uses it. At the moment I take care of the Google Code<br>
> [1] project for sqlalchemy-migrate and maintain a Jenkins instance at<br>
> <a href="http://jenkins.gnuviech-server.de/" target="_blank">http://jenkins.gnuviech-server.de/</a>. I'm all in favour of moving to github,<br>
> Google Code was just choosen because it was available at the time the<br>
> project moved from the initial developer's (Evan Rosson) personal server. I<br>
> can also give access to the PyPI project page [2] to a prospective new<br>
> maintainer/team.<br>
><br>
> I wrote some sphinx documentation and improved the tests a while ago but I<br>
> have no time to maintain it properly. I switched to alembic for my small<br>
> personal projects.<br>
><br>
> [1] <a href="https://code.google.com/p/sqlalchemy-migrate/" target="_blank">https://code.google.com/p/sqlalchemy-migrate/</a><br>
> [2] <a href="https://pypi.python.org/pypi/sqlalchemy-migrate" target="_blank">https://pypi.python.org/pypi/sqlalchemy-migrate</a><br>
><br>
><br>
> Best regards<br>
> Jan<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 40<br>
Date: Fri, 12 Jul 2013 02:32:53 +0800<br>
From: Ying Chun Guo <<a href="mailto:guoyingc@cn.ibm.com">guoyingc@cn.ibm.com</a>><br>
To: "OpenStack Development Mailing List"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Olso]About blueprint: Separate translation<br>
domain for log messages<br>
Message-ID:<br>
<<a href="mailto:OF148F9D27.42A46F0A-ON48257BA5.0065BC29-48257BA5.0065F26A@cn.ibm.com">OF148F9D27.42A46F0A-ON48257BA5.0065BC29-48257BA5.0065F26A@cn.ibm.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
Hi, Olso dev team<br>
<br>
I remember there was a blueprint discussed in the Havana summit to separate<br>
translation domains.<br>
<a href="https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain" target="_blank">https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain</a><br>
<br>
I don't see any progress there.<br>
Do you have any plan to implement it?<br>
The translation team set the command line message as high priority, but log<br>
messages as low priority.<br>
So we want the domains can be separated.<br>
<br>
Regards<br>
Daisy<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/b17e178a/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/b17e178a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 41<br>
Date: Thu, 11 Jul 2013 14:40:24 -0400<br>
From: David Ripton <<a href="mailto:dripton@redhat.com">dripton@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID: <<a href="mailto:51DEFC18.1060607@redhat.com">51DEFC18.1060607@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
OpenStack is currently divided. Older projects like Nova use<br>
sqlalchemy-migrate. Some newer projects like Neutron use alembic.<br>
<br>
I'd personally like to see everything in Alembic, but migrating all the<br>
Nova scripts in a way that didn't break compatibility will be a big<br>
challenge. It's easier for projects with less to port.<br>
<br>
Another option is to take over maintaining sqlalchemy-migrate and bend<br>
it to our needs. (It's mostly okay, but the big issue for me is its use<br>
of strictly incrementing integer sequence numbers. That both causes<br>
problems when competing patches in review race for the same filename,<br>
and when we try to backport some but not all migration scripts to a<br>
stable branch.) We already apply some patches to upstream, so having a<br>
friendly maintainer who would apply patches that OpenStack needs would<br>
be helpful.<br>
<br>
This will be a topic at the DB meeting today at 1900 UTC (about 20<br>
minutes from when I send this email). So please attend if it's<br>
important to you.<br>
<br>
<br>
On 07/11/2013 02:18 PM, Thomas Goirand wrote:<br>
<br>
> Discussing with Jan Dittberner, who is upstream for sqlalchemy-migrate,<br>
> it appears that he doesn't have time to maintain it.<br>
><br>
> Is the OpenStack project willing to take over? Jan is ok to hand over<br>
> everything, moving to Github, give access to Pypi, etc. Below is his<br>
> reply to me when I asked him.<br>
><br>
> Or is the OpenStack project moving toward Alembic as well?<br>
><br>
> Thoughts anyone?<br>
><br>
> Thomas Goirand (zigo)<br>
><br>
> On 07/12/2013 01:27 AM, Jan Dittberner wrote:<br>
>> I would be very happy to hand over the maintenance of sqlalchemy-migrate to<br>
>> a team that actually uses it. At the moment I take care of the Google Code<br>
>> [1] project for sqlalchemy-migrate and maintain a Jenkins instance at<br>
>> <a href="http://jenkins.gnuviech-server.de/" target="_blank">http://jenkins.gnuviech-server.de/</a>. I'm all in favour of moving to github,<br>
>> Google Code was just choosen because it was available at the time the<br>
>> project moved from the initial developer's (Evan Rosson) personal server. I<br>
>> can also give access to the PyPI project page [2] to a prospective new<br>
>> maintainer/team.<br>
>><br>
>> I wrote some sphinx documentation and improved the tests a while ago but I<br>
>> have no time to maintain it properly. I switched to alembic for my small<br>
>> personal projects.<br>
>><br>
>> [1] <a href="https://code.google.com/p/sqlalchemy-migrate/" target="_blank">https://code.google.com/p/sqlalchemy-migrate/</a><br>
>> [2] <a href="https://pypi.python.org/pypi/sqlalchemy-migrate" target="_blank">https://pypi.python.org/pypi/sqlalchemy-migrate</a><br>
>><br>
>><br>
>> Best regards<br>
>> Jan<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
--<br>
David Ripton Red Hat <a href="mailto:dripton@redhat.com">dripton@redhat.com</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 42<br>
Date: Thu, 11 Jul 2013 22:45:57 +0400<br>
From: Alexander Kuznetsov <<a href="mailto:akuznetsov@mirantis.com">akuznetsov@mirantis.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>, <a href="mailto:savanna-all@lists.launchpad.net">savanna-all@lists.launchpad.net</a><br>
Subject: [openstack-dev] [Savanna-all] Blueprints for EDP components<br>
Message-ID:<br>
<CAA-P=7quKiBEZcR=aV=<a href="mailto:Rk_9OiNgBBKkGj1rtyovcNuaCYNtbAQ@mail.gmail.com">Rk_9OiNgBBKkGj1rtyovcNuaCYNtbAQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
Blueprints for EDP components on launchpad are added<br>
<br>
<a href="https://blueprints.launchpad.net/savanna/+spec/job-manager-components" target="_blank">https://blueprints.launchpad.net/savanna/+spec/job-manager-components</a><br>
<a href="https://blueprints.launchpad.net/savanna/+spec/data-discovery-component" target="_blank">https://blueprints.launchpad.net/savanna/+spec/data-discovery-component</a><br>
<a href="https://blueprints.launchpad.net/savanna/+spec/job-source-component" target="_blank">https://blueprints.launchpad.net/savanna/+spec/job-source-component</a><br>
<a href="https://blueprints.launchpad.net/savanna/+spec/methods-for-plugin-api-to-support-edp" target="_blank">https://blueprints.launchpad.net/savanna/+spec/methods-for-plugin-api-to-support-edp</a><br>
<br>
Each blueprint contains short component descriptions, objects model and<br>
methods, which will be implemented in this component.<br>
<br>
Your comments and suggestions are welcome.<br>
<br>
Thanks,<br>
Alexander Kuznetsov.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/3900e425/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/3900e425/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 43<br>
Date: Thu, 11 Jul 2013 13:41:19 -0500<br>
From: Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Olso]About blueprint: Separate<br>
translation domain for log messages<br>
Message-ID: <<a href="mailto:35420b1dab3e27578e80ed7ffb9799d2@home.nemebean.com">35420b1dab3e27578e80ed7ffb9799d2@home.nemebean.com</a>><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
Daisy, did you see Mark's response here:<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-July/011692.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-July/011692.html</a><br>
?<br>
<br>
-Ben<br>
<br>
On 2013-07-11 13:32, Ying Chun Guo wrote:<br>
> Hi, Olso dev team<br>
><br>
> I remember there was a blueprint discussed in the Havana summit to<br>
> separate translation domains.<br>
><br>
><br>
><br>
><br>
><br>
> s://<a href="http://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain" target="_blank">blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain</a><br>
> [1]<br>
><br>
> I don't see any progress there.<br>
> Do you have any plan to implement it?<br>
> The translation team set the command line message as high priority,<br>
> but log messages as low priority.<br>
> So we want the domains can be separated.<br>
><br>
> Regards<br>
> Daisy<br>
><br>
> Links:<br>
> ------<br>
> [1]<br>
><br>
><br>
><br>
><br>
> s://<a href="http://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain" target="_blank">blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 44<br>
Date: Thu, 11 Jul 2013 23:01:08 +0400<br>
From: Boris Pavlovic <<a href="mailto:boris@pavlovic.me">boris@pavlovic.me</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID:<br>
<<a href="mailto:CAD85om3cdUSJe5g98Kk4a4XXj3HdVUswjkN3MombizS-_KAOqw@mail.gmail.com">CAD85om3cdUSJe5g98Kk4a4XXj3HdVUswjkN3MombizS-_KAOqw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
David Ripton,<br>
<br>
Alembic is much better and I think that it is better to extend it to<br>
provide sqlite, then to use and try to improve sqlalchemy-migrate.<br>
<br>
Also we are preparing old projects (Nova, Cinder and Glance) to move from<br>
sqlalchemy-migrate to something another (e.g. alembic).<br>
If you are interested read my email in mailing list (<br>
<a href="http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg00809.html" target="_blank">http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg00809.html</a>)<br>
<br>
So as I said in mail, there is a lot of work that should be done before<br>
changing migrate engine. And there will be a bunch of work to switch to<br>
something new.<br>
Actually we are trying in moment to switch from sqlalchemy-migrate to<br>
alembic in Ceilometer.<br>
<br>
Best regards,<br>
Boris Pavlovic<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/e9eb9079/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/e9eb9079/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 45<br>
Date: Thu, 11 Jul 2013 19:07:29 +0000<br>
From: Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [State-Management] Agenda for todays meeting<br>
at 2000 UTC<br>
Message-ID: <<a href="mailto:CE04507D.40F5E%25harlowja@yahoo-inc.com">CE04507D.40F5E%harlowja@yahoo-inc.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi all,<br>
<br>
The [state-management] project team holds a weekly meeting in #openstack-meeting on thursdays, 2000 UTC. The next meeting is today!!!<br>
<br>
As usual, everyone is welcome :-)<br>
<br>
Link: <a href="https://wiki.openstack.org/wiki/Meetings/StateManagement" target="_blank">https://wiki.openstack.org/wiki/Meetings/StateManagement</a><br>
<br>
## Agenda (30-60 mins): ##<br>
<br>
- Discuss any action items from last meeting.<br>
- Discuss ongoing status of the overall effort and any needed coordination.<br>
- *Discuss when to release and how.*<br>
- Talk about progress with regards to cinder/nova/ironic/heat integration.<br>
- Discuss about any other potential new use-cases for said library.<br>
- Discuss about any other ideas, problems, issues, solutions.<br>
<br>
Any other topics are welcome :-)<br>
<br>
See you all soon!<br>
<br>
-Josh<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/801e0e83/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/801e0e83/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 46<br>
Date: Thu, 11 Jul 2013 15:12:43 -0400<br>
From: Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID: <<a href="mailto:51DF03AB.7060608@inaugust.com">51DF03AB.7060608@inaugust.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
<br>
On 07/11/2013 02:40 PM, David Ripton wrote:<br>
> OpenStack is currently divided. Older projects like Nova use<br>
> sqlalchemy-migrate. Some newer projects like Neutron use alembic.<br>
><br>
> I'd personally like to see everything in Alembic, but migrating all the<br>
> Nova scripts in a way that didn't break compatibility will be a big<br>
> challenge. It's easier for projects with less to port.<br>
><br>
> Another option is to take over maintaining sqlalchemy-migrate and bend<br>
> it to our needs. (It's mostly okay, but the big issue for me is its use<br>
> of strictly incrementing integer sequence numbers. That both causes<br>
> problems when competing patches in review race for the same filename,<br>
> and when we try to backport some but not all migration scripts to a<br>
> stable branch.) We already apply some patches to upstream, so having a<br>
> friendly maintainer who would apply patches that OpenStack needs would<br>
> be helpful.<br>
><br>
> This will be a topic at the DB meeting today at 1900 UTC (about 20<br>
> minutes from when I send this email). So please attend if it's<br>
> important to you.<br>
><br>
><br>
> On 07/11/2013 02:18 PM, Thomas Goirand wrote:<br>
><br>
>> Discussing with Jan Dittberner, who is upstream for sqlalchemy-migrate,<br>
>> it appears that he doesn't have time to maintain it.<br>
>><br>
>> Is the OpenStack project willing to take over? Jan is ok to hand over<br>
>> everything, moving to Github, give access to Pypi, etc. Below is his<br>
>> reply to me when I asked him.<br>
<br>
Hi - We discussed this in the db meeting and decided that as much as<br>
we're not thrilled with sqlalchemy-migrate (I believe boris-42 summed it<br>
up as "bad bad bad very bad things") we've got a pretty strong<br>
dependency on it right now and for the next while.<br>
<br>
SO - let's work on getting it moved into our systems and then we at<br>
least have the ability to patch/release if needed.<br>
<br>
>> Or is the OpenStack project moving toward Alembic as well?<br>
>><br>
>> Thoughts anyone?<br>
>><br>
>> Thomas Goirand (zigo)<br>
>><br>
>> On 07/12/2013 01:27 AM, Jan Dittberner wrote:<br>
>>> I would be very happy to hand over the maintenance of<br>
>>> sqlalchemy-migrate to<br>
>>> a team that actually uses it. At the moment I take care of the Google<br>
>>> Code<br>
>>> [1] project for sqlalchemy-migrate and maintain a Jenkins instance at<br>
>>> <a href="http://jenkins.gnuviech-server.de/" target="_blank">http://jenkins.gnuviech-server.de/</a>. I'm all in favour of moving to<br>
>>> github,<br>
>>> Google Code was just choosen because it was available at the time the<br>
>>> project moved from the initial developer's (Evan Rosson) personal<br>
>>> server. I<br>
>>> can also give access to the PyPI project page [2] to a prospective new<br>
>>> maintainer/team.<br>
>>><br>
>>> I wrote some sphinx documentation and improved the tests a while ago<br>
>>> but I<br>
>>> have no time to maintain it properly. I switched to alembic for my small<br>
>>> personal projects.<br>
>>><br>
>>> [1] <a href="https://code.google.com/p/sqlalchemy-migrate/" target="_blank">https://code.google.com/p/sqlalchemy-migrate/</a><br>
>>> [2] <a href="https://pypi.python.org/pypi/sqlalchemy-migrate" target="_blank">https://pypi.python.org/pypi/sqlalchemy-migrate</a><br>
>>><br>
>>><br>
>>> Best regards<br>
>>> Jan<br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 47<br>
Date: Thu, 11 Jul 2013 15:14:30 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Current biggest OpenStack gate fail<br>
culprit - neutron bug #1194026<br>
Message-ID: <<a href="mailto:51DF0416.3040102@dague.net">51DF0416.3040102@dague.net</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 07/11/2013 01:37 PM, Nachi Ueno wrote:<br>
> Hi Sean<br>
><br>
> Sorry for it taking long time to fixing this problem.<br>
> At least, 3 neutron core dev is working on this issue, but<br>
> it is kind of timing issue so we are struggling to replicate it.<br>
><br>
> I'm also OK to move it for non-voting now.<br>
<br>
Great. I think the focus really should be to ensure that Neutron is<br>
generating enough and the right logs so that we can do first fail<br>
detection in the gate.<br>
<br>
This really should be debuggable completely based on gate logs, and if<br>
not, we should increase what Neutron is printing out. For most Nova<br>
flakey fails we can get very close to the root cause based on the logs<br>
collected, which means recreating locally isn't really the path to<br>
success, but using the gate itself.<br>
<br>
If anyone needs help sifting on the gate, please just ask for it on<br>
#openstack-dev, -infra, or -qa and we'll get people sorted.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 48<br>
Date: Thu, 11 Jul 2013 16:06:25 -0400<br>
From: David Ripton <<a href="mailto:dripton@redhat.com">dripton@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] DB team meeting Thursday 1900 UTC<br>
Message-ID: <<a href="mailto:51DF1041.9060000@redhat.com">51DF1041.9060000@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 07/10/2013 03:41 PM, David Ripton wrote:<br>
> We don't have the DB team meeting every week, but we're having it this<br>
> week. Thursday at 1900 UTC in #openstack-meeting. Thanks.<br>
><br>
<br>
We had the DB meeting today. Major things discussed were<br>
sqlalchemy-migrate maintainership crisis (it sounds like OpenStack will<br>
take ownership of the unmaintained project for legacy support reasons,<br>
while trying to move things to Alembic as fast as we safely can), moving<br>
Nova DB code to Oslo (resolved by removing some db-archiving functions<br>
that not everyone likes), and a bunch of patches that we'd really like<br>
approved for Havana-2.<br>
<br>
Full log:<br>
<br>
<a href="http://eavesdrop.openstack.org/meetings/db/2013/db.2013-07-11-19.00.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/db/2013/db.2013-07-11-19.00.log.html</a><br>
<br>
Thanks.<br>
<br>
--<br>
David Ripton Red Hat <a href="mailto:dripton@redhat.com">dripton@redhat.com</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 49<br>
Date: Thu, 11 Jul 2013 13:30:40 -0700<br>
From: Aaron Rosen <<a href="mailto:arosen@nicira.com">arosen@nicira.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] Revert Pass instance host-id to Quantum using<br>
port bindings extension.<br>
Message-ID:<br>
<<a href="mailto:CANAD0X_XKTxM2Cej3QbFvZmH0G3qVig2K_9HXnf7XkgzP4J00Q@mail.gmail.com">CANAD0X_XKTxM2Cej3QbFvZmH0G3qVig2K_9HXnf7XkgzP4J00Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi,<br>
<br>
I think we should revert this patch that was added here (<br>
<a href="https://review.openstack.org/#/c/29767/" target="_blank">https://review.openstack.org/#/c/29767/</a>). What this patch does is when<br>
nova-compute calls into quantum to create the port it passes in the<br>
hostname on which the instance was booted on. The idea of the patch was<br>
that providing this information would "allow hardware device vendors<br>
management stations to allow them to segment the network in a more precise<br>
manager (for example automatically trunk the vlan on the physical switch<br>
port connected to the compute node on which the vm instance was started)."<br>
<br>
In my opinion I don't think this is the right approach. There are several<br>
other ways to get this information of where a specific port lives. For<br>
example, in the OVS plugin case the agent running on the nova-compute node<br>
can update the port in quantum to provide this information. Alternatively,<br>
quantum could query nova using the port.device_id to determine which server<br>
the instance is on.<br>
<br>
My motivation for removing this code is I now have the free cycles to work<br>
on <a href="https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port" target="_blank">https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port</a><br>
discussed here (<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html</a>) .<br>
This was about moving the quantum port creation from the nova-compute host<br>
to nova-api if a network-uuid is passed in. This will allow us to remove<br>
all the quantum logic from the nova-compute nodes and<br>
simplify orchestration.<br>
<br>
Thoughts?<br>
<br>
Best,<br>
<br>
Aaron<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/b6dae7c3/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/b6dae7c3/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 50<br>
Date: Thu, 11 Jul 2013 16:00:03 -0500<br>
From: Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID:<br>
<CAC=h7gV0kY8Bd2+pcDZwysK8-u5c_=<a href="mailto:Vaq6Z02YaDENeWpkdM8g@mail.gmail.com">Vaq6Z02YaDENeWpkdM8g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Jul 11, 2013 at 2:01 PM, Boris Pavlovic <<a href="mailto:boris@pavlovic.me">boris@pavlovic.me</a>> wrote:<br>
<br>
> David Ripton,<br>
><br>
> Alembic is much better and I think that it is better to extend it to<br>
> provide sqlite, then to use and try to improve sqlalchemy-migrate.<br>
><br>
> Also we are preparing old projects (Nova, Cinder and Glance) to move from<br>
> sqlalchemy-migrate to something another (e.g. alembic).<br>
> If you are interested read my email in mailing list (<br>
> <a href="http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg00809.html" target="_blank">http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg00809.html</a><br>
> )<br>
><br>
> So as I said in mail, there is a lot of work that should be done before<br>
> changing migrate engine. And there will be a bunch of work to switch to<br>
> something new.<br>
> Actually we are trying in moment to switch from sqlalchemy-migrate to<br>
> alembic in Ceilometer.<br>
><br>
<br>
Please share your experience making this transition with the broader<br>
community! Even with my limited exposure to alembic, it clearly provides a<br>
much better dev experience compared to sqlalchemy-migrate and would love to<br>
consider transitioning keystone in the future, if possible.<br>
<br>
<br>
><br>
> Best regards,<br>
> Boris Pavlovic<br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
<br>
<br>
--<br>
<br>
-Dolph<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/d0d002e3/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/d0d002e3/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 51<br>
Date: Thu, 11 Jul 2013 22:50:35 +0100<br>
From: John Garbutt <<a href="mailto:john@johngarbutt.com">john@johngarbutt.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Nova] Criteria for compute drivers<br>
Message-ID:<br>
<CABib2_okZqpEgbpK==<a href="mailto:KjUWNjwx6tXdb7gkh3NnCTWZ0JAFPOQQ@mail.gmail.com">KjUWNjwx6tXdb7gkh3NnCTWZ0JAFPOQQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
This seems a fair way of doing it.<br>
Gives users and developers a fair warning.<br>
<br>
If its not tested, because we will keep breaking it by accident, and<br>
thats not fair on anyone, so those drivers shouldn't be in the main<br>
tree<br>
<br>
I wonder if we should requiring a certain level of testing or unit testing?<br>
Like % coverage, or start VM, attach volume, delete VM?<br>
Either way, this seems a good step forward.<br>
<br>
John<br>
<br>
On 10 July 2013 15:33, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
> On 07/10/2013 08:05 AM, Joe Gordon wrote:<br>
>><br>
>><br>
>><br>
>> On Tue, Jul 2, 2013 at 7:38 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a><br>
>> <mailto:<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>>> wrote:<br>
>><br>
>> Greetings,<br>
>><br>
>> Nova includes various compute drivers today, but the test coverage they<br>
>> receive varies quite a bit. This is documented on the following wiki<br>
>> page. The drivers are broken up into groups A, B, and C.<br>
>><br>
>> <a href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix" target="_blank">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</a><br>
>><br>
>> We have two new compute drivers in the queue for Havana: docker [1] and<br>
>> z/vm [2]. I'd like to propose as a piece of criteria for inclusion that<br>
>> new drivers go into groups A or B.<br>
>><br>
>> Further, I would like to see *all* drivers move into groups A or B by<br>
>> the release of Icehouse. I've been told that this is already in the<br>
>> works for VMware and baremetal, at least.<br>
>><br>
>><br>
>> And if a driver doesn't go into group A or B by Icehouse? Do we put<br>
>> clear warnings in the release notes that they are 'use at your own<br>
>> risk.' Perhaps if drivers stay in C by the end of Icehouse Development<br>
>> we remove them, as we have no way of guaranteeing they work and shipping<br>
>> broken code looks bad.<br>
><br>
> Yes, removing them is what I had in mind.<br>
><br>
> --<br>
> Russell Bryant<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 52<br>
Date: Fri, 12 Jul 2013 00:19:35 +0100<br>
From: Filipe Manco <<a href="mailto:filipe.manco@gmail.com">filipe.manco@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Neutron] Campus Network Blueprint<br>
Message-ID:<br>
<CAM4=<a href="mailto:6oKiXu3rVuE3eiDh11ihVHqcUbQKCsBD%2Bc03zvKzikzbWQ@mail.gmail.com">6oKiXu3rVuE3eiDh11ihVHqcUbQKCsBD+c03zvKzikzbWQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi all,<br>
<br>
As requested in the ML2 meeting I worked out a new blueprint [1] specifying<br>
a subset of the Campus Network one eventually able to hit H3.<br>
I tried to make this blueprint the most generic I could, so I changed the<br>
concepts just a little bit. If you agree with this (even if not for H3) I<br>
will change the Campus Network BP accordingly.<br>
<br>
[1] <a href="https://blueprints.launchpad.net/neutron/+spec/ml2-external-port" target="_blank">https://blueprints.launchpad.net/neutron/+spec/ml2-external-port</a><br>
<br>
Thank you all<br>
Regards<br>
<br>
Filipe Manco<br>
<a href="http://about.me/fmanco" target="_blank">http://about.me/fmanco</a><br>
<br>
<br>
2013/7/10 Filipe Manco <<a href="mailto:filipe.manco@gmail.com">filipe.manco@gmail.com</a>><br>
<br>
> I will join you. Thanks!<br>
><br>
> Filipe Manco<br>
> <a href="http://about.me/fmanco" target="_blank">http://about.me/fmanco</a><br>
><br>
><br>
> 2013/7/10 Kyle Mestery (kmestery) <<a href="mailto:kmestery@cisco.com">kmestery@cisco.com</a>><br>
><br>
> On Jul 9, 2013, at 8:40 PM, Filipe Manco <<a href="mailto:filipe.manco@gmail.com">filipe.manco@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hi Kyle<br>
>> ><br>
>> > I already looked at the blueprints and I want to integrate my work with<br>
>> ML2, mainly because I want users to able to keep the traditional networking<br>
>> models working in parallel (and I think ML2 is the best way to do this<br>
>> comparing with the meta plugin).<br>
>> ><br>
>> > To be honest, the integration with Neutron and the ML2 was what took<br>
>> most of the time when writing the blueprint, but although I talk about it<br>
>> on the blueprint I still not sure about the best way to do it.<br>
>> ><br>
>> > About the concept of segments I don't think they fit. From what I<br>
>> understand a segment, in the context of ML2, represents part of the virtual<br>
>> network that uses some technology to connect a set of VMs, so if I delete a<br>
>> segment those VMs will loose connectivity. In the context of my blueprint a<br>
>> segment (or cSegment as I called it) represents a domain where I can create<br>
>> virtual links across a set of nodes. If I delete a cSegment that doesn't<br>
>> mean any VM will loose connectivity, what will happen is that the network<br>
>> is remapped and the traffic will cross another cSegment or another set of<br>
>> cSegments.<br>
>> ><br>
>> I think what you've mentioned here is valid, yes, and is a slight<br>
>> deviation between the way segments in ML2 work on your cSegments. It looks<br>
>> like we would need to add your new constructs into the ML2 API to achieve<br>
>> what you're looking for.<br>
>><br>
>> > Something that I would like you (or other guys from ML2) to comment is<br>
>> how to integrate new operations (beyond the ones related with the base data<br>
>> model) in the ML2 interfaces. The MechanismDriver interface supports<br>
>> operations on ports and networks, but as you can see I have new entities.<br>
>> My idea is that there should be no changes to the original interfaces,<br>
>> because this are specific to a type of network. What do you think?<br>
>> ><br>
>> I'll have a look at this tomorrow and give you more detailed feedback. If<br>
>> you want, you can join us in the ML2 meeting at 1400UTV meeting on<br>
>> #openstack-meeting and I'll save some time at the end of the meeting to<br>
>> discuss your blueprint.<br>
>><br>
>> Thanks!<br>
>> Kyle<br>
>><br>
>> > It would help me if you have the time to take a look at the blueprint<br>
>> and comment on the ML2 parts.<br>
>> ><br>
>> > Thanks for your help!<br>
>> ><br>
>> > Filipe Manco<br>
>> > <a href="http://about.me/fmanco" target="_blank">http://about.me/fmanco</a><br>
>> ><br>
>> ><br>
>> > 2013/7/9 Kyle Mestery (kmestery) <<a href="mailto:kmestery@cisco.com">kmestery@cisco.com</a>><br>
>> > On Jul 9, 2013, at 11:18 AM, Filipe Manco <<a href="mailto:filipe.manco@gmail.com">filipe.manco@gmail.com</a>><br>
>> wrote:<br>
>> > ><br>
>> > > Hi all,<br>
>> > ><br>
>> > > Just published a blueprint for some work I'm starting right now. I<br>
>> would appreciate if someone can take a look and give some comments.<br>
>> > ><br>
>> > > <a href="https://blueprints.launchpad.net/neutron/+spec/campus-network" target="_blank">https://blueprints.launchpad.net/neutron/+spec/campus-network</a><br>
>> > ><br>
>> > > Thank you<br>
>> > ><br>
>> > Hi Filipe:<br>
>> ><br>
>> > At first glance, there appears to be a lot of overlap with ML2 here.<br>
>> Have you looked at the ML2 blueprints, and the specific use case of<br>
>> multi-segment networks? The ML2 team is working hard to close ML2<br>
>> blueprints in H2/H3, perhaps some of your ideas could be incorporated here?<br>
>> ><br>
>> > Here is the ML2 Meeting page which has links to the blueprints we're<br>
>> tracking:<br>
>> ><br>
>> > <a href="https://wiki.openstack.org/wiki/Meetings/ML2" target="_blank">https://wiki.openstack.org/wiki/Meetings/ML2</a><br>
>> ><br>
>> > Thanks,<br>
>> > Kyle<br>
>> ><br>
>> > ><br>
>> > > Filipe Manco<br>
>> > > <a href="http://about.me/fmanco" target="_blank">http://about.me/fmanco</a><br>
>> > > _______________________________________________<br>
>> > > OpenStack-dev mailing list<br>
>> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/ed5489f5/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/ed5489f5/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 53<br>
Date: Thu, 11 Jul 2013 19:29:16 -0400<br>
From: Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer<br>
Message-ID: <<a href="mailto:51DF3FCC.2050902@inaugust.com">51DF3FCC.2050902@inaugust.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
<br>
<br>
On 07/11/2013 03:12 PM, Monty Taylor wrote:<br>
><br>
><br>
> On 07/11/2013 02:40 PM, David Ripton wrote:<br>
>> OpenStack is currently divided. Older projects like Nova use<br>
>> sqlalchemy-migrate. Some newer projects like Neutron use alembic.<br>
>><br>
>> I'd personally like to see everything in Alembic, but migrating all the<br>
>> Nova scripts in a way that didn't break compatibility will be a big<br>
>> challenge. It's easier for projects with less to port.<br>
>><br>
>> Another option is to take over maintaining sqlalchemy-migrate and bend<br>
>> it to our needs. (It's mostly okay, but the big issue for me is its use<br>
>> of strictly incrementing integer sequence numbers. That both causes<br>
>> problems when competing patches in review race for the same filename,<br>
>> and when we try to backport some but not all migration scripts to a<br>
>> stable branch.) We already apply some patches to upstream, so having a<br>
>> friendly maintainer who would apply patches that OpenStack needs would<br>
>> be helpful.<br>
>><br>
>> This will be a topic at the DB meeting today at 1900 UTC (about 20<br>
>> minutes from when I send this email). So please attend if it's<br>
>> important to you.<br>
>><br>
>><br>
>> On 07/11/2013 02:18 PM, Thomas Goirand wrote:<br>
>><br>
>>> Discussing with Jan Dittberner, who is upstream for sqlalchemy-migrate,<br>
>>> it appears that he doesn't have time to maintain it.<br>
>>><br>
>>> Is the OpenStack project willing to take over? Jan is ok to hand over<br>
>>> everything, moving to Github, give access to Pypi, etc. Below is his<br>
>>> reply to me when I asked him.<br>
><br>
> Hi - We discussed this in the db meeting and decided that as much as<br>
> we're not thrilled with sqlalchemy-migrate (I believe boris-42 summed it<br>
> up as "bad bad bad very bad things") we've got a pretty strong<br>
> dependency on it right now and for the next while.<br>
><br>
> SO - let's work on getting it moved into our systems and then we at<br>
> least have the ability to patch/release if needed.<br>
<br>
We've got the upstream pypi and rtfd credentials now, the project should<br>
be moved in to openstack systems soon enough. I also went through and<br>
cleaned up build and test stuff work work like our stuff works (if we're<br>
going to be maintaining it, we might as well, you know, do it how we do<br>
things)<br>
<br>
This brings us to the most important question:<br>
<br>
Who wants to be on the core team?<br>
<br>
>>> Or is the OpenStack project moving toward Alembic as well?<br>
>>><br>
>>> Thoughts anyone?<br>
>>><br>
>>> Thomas Goirand (zigo)<br>
>>><br>
>>> On 07/12/2013 01:27 AM, Jan Dittberner wrote:<br>
>>>> I would be very happy to hand over the maintenance of<br>
>>>> sqlalchemy-migrate to<br>
>>>> a team that actually uses it. At the moment I take care of the Google<br>
>>>> Code<br>
>>>> [1] project for sqlalchemy-migrate and maintain a Jenkins instance at<br>
>>>> <a href="http://jenkins.gnuviech-server.de/" target="_blank">http://jenkins.gnuviech-server.de/</a>. I'm all in favour of moving to<br>
>>>> github,<br>
>>>> Google Code was just choosen because it was available at the time the<br>
>>>> project moved from the initial developer's (Evan Rosson) personal<br>
>>>> server. I<br>
>>>> can also give access to the PyPI project page [2] to a prospective new<br>
>>>> maintainer/team.<br>
>>>><br>
>>>> I wrote some sphinx documentation and improved the tests a while ago<br>
>>>> but I<br>
>>>> have no time to maintain it properly. I switched to alembic for my small<br>
>>>> personal projects.<br>
>>>><br>
>>>> [1] <a href="https://code.google.com/p/sqlalchemy-migrate/" target="_blank">https://code.google.com/p/sqlalchemy-migrate/</a><br>
>>>> [2] <a href="https://pypi.python.org/pypi/sqlalchemy-migrate" target="_blank">https://pypi.python.org/pypi/sqlalchemy-migrate</a><br>
>>>><br>
>>>><br>
>>>> Best regards<br>
>>>> Jan<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 15, Issue 21<br>
*********************************************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Wentian Jiang<div>UnitedStack Inc.</div></div>
</div>