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