Open Stack

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.

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>