Open Stack

The Barbican Team also has a plan to release a new version of barbican client for Kilo.  The planned version is 3.1.0. [1] and it will include features landed during FFE.

Thanks,
-Douglas Mendizabal

[1] https://launchpad.net/python-barbicanclient/+milestone/3.1.0 <https://launchpad.net/python-barbicanclient/+milestone/3.1.0>

> On 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.
> 
> Thanks,
> Akihiro
> 
> 
> 2015-04-10 0:09 GMT+09:00 Thierry Carrez <thierry at openstack.org <mailto: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 <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> --
> Akihiro Motoki <amotoki at gmail.com <mailto:amotoki at gmail.com>>
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> 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/20150409/4fb5b15f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150409/4fb5b15f/attachment.pgp>