Open Stack

On Thu, Apr 9, 2015 at 11:23 AM, Akihiro Motoki <amotoki at gmail.com> wrote:

> Neutron team has a plan to release a new version of neutornclient for Kilo.
> We waited the new release until all granted FFE patches land,
> and now we are almost ready to go. (waiting one patch in the gate)
>
> The planned new version is 2.4.0. It is because neutronclient uses 2.3.x
> version
> for a long time (including Kilo) and we would like to have a room for
> bug fixing for Juno release.
> So we would like to propose the following for Kilo:
>
>   python-neutronclient >=2.4.0 <2.5.0
>
> I am in the same page with Kyle.
> I hope this plan is acceptable.
>
> Can we request a requirements FFE for the following patch [1]? This will
set Liberty up to use the 2.5.x series for python-neutronclient, per what
Akihiro and I have planned. The Juno patch should hopefully merge soon [2],
which caps Juno to something appropriate as well.

Thanks
Kyle

[1] https://review.openstack.org/#/c/172149/
[2] https://review.openstack.org/#/c/172150/


> Thanks,
> Akihiro
>
>
> 2015-04-10 0:09 GMT+09:00 Thierry Carrez <thierry at openstack.org>:
> > Doug Hellmann wrote:
> >> Excerpts from Dean Troyer's message of 2015-04-08 09:42:31 -0500:
> >>> On Wed, Apr 8, 2015 at 8:55 AM, Thierry Carrez <thierry at openstack.org>
> >>> wrote:
> >>>
> >>>> The question is, how should we proceed there ? This is new procedure,
> so
> >>>> I'm a bit unclear on the best way forward and would like to pick our
> >>>> collective brain. Should we just push requirements cap for all
> OpenStack
> >>>> libs and create stable branches from the last tagged release
> everywhere
> >>>> ? What about other libraries ? Should we push a cap there too ? Should
> >>>> we just ignore the whole thing for the Kilo release for all non-Oslo
> stuff
> >>>> ?
> >>>
> >>> Provided that represents the code being used for testing at this
> point, and
> >>> I believe it does, this seems like a sensible default action.  Next
> cycle
> >>> we can make a bit more noise about when this default action will occur,
> >>> probably pick one of the other existing dates late in the cycle such
> as RC
> >>> or string freeze or whatever. (Maybe that already happened and I can't
> >>> remember?)
> >>
> >> I had hoped to have the spec approved in time to cut releases around
> >> the time Oslo did (1 week before feature freeze for applications,
> >> to allow us to merge the requirements cap before applications
> >> generate their RC1). At this point, I agree that we should go with
> >> the most recently tagged versions where possible. It sounds like
> >> we have a couple of libs that need releases, and we should evaluate
> >> those on a case-by-case basis, defaulting to not updating the stable
> >> requirements unless absolutely necessary.
> >
> > OK, here is a plan, let me know if it makes sense.
> >
> > If necessary:
> > Cinder releases python-cinderclient 1.1.2
> > Designate releases python-designateclient 1.1.2
> > Horizon releases django_openstack_auth 1.2.0
> > Ironic releases python-ironicclient 0.5.1
> >
> > Then we cap in requirements stable/kilo branch (once it's cut, when all
> > RC1s are done):
> >
> > python-barbicanclient >=3.0.1 <3.1.0
> > python-ceilometerclient >=1.0.13 <1.1.0
> > python-cinderclient >=1.1.0 <1.2.0
> > python-designateclient >=1.0.0 <1.2.0
> > python-heatclient >=0.3.0 <0.5.0
> > python-glanceclient >=0.15.0 <0.18.0
> > python-ironicclient >=0.2.1 <0.6.0
> > python-keystoneclient >=1.1.0 <1.4.0
> > python-neutronclient >=2.3.11 <2.4.0
> > python-novaclient >=2.22.0 <2.24.0
> > python-saharaclient >=0.8.0 <0.9.0
> > python-swiftclient >=2.2.0 <2.5.0
> > python-troveclient >=1.0.7 <1.1.0
> > glance_store >=0.3.0 <0.5.0
> > keystonemiddleware >=1.5.0 <1.6.0
> > pycadf >=0.8.0 <0.9.0
> > django_openstack_auth>=1.1.7,!=1.1.8 <1.3.0
> >
> > As discussed we'll add openstackclient while we are at it:
> >
> > python-openstackclient>=1.0.0,<1.1.0
> >
> > That should trickle down to multiple syncs in multiple projects, which
> > we'd merge in a RC2. Next time we'll do it all the same time Oslo did
> > it, to avoid creating unnecessary respins (live and learn).
> >
> > Anything I missed ?
> >
> > Bonus question: will the openstack proposal bot actually propose
> > stable/kilo g-r changes to proposed/kilo branches ?
> >
> > --
> > Thierry Carrez (ttx)
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Akihiro Motoki <amotoki at gmail.com>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150409/93d71ebf/attachment.html>