[openstack-dev] [stable] Exception proposals for 2014.2.1

Flavio Percoco flavio at redhat.com
Wed Dec 3 11:24:33 UTC 2014


On 03/12/14 11:02 +0100, Thierry Carrez wrote:
>Doug Hellmann wrote:
>>
>> On Dec 2, 2014, at 5:41 PM, Alan Pevec <apevec at gmail.com> wrote:
>>
>>>>> General: cap Oslo and client library versions - sync from
>>>>> openstack/requirements stable/juno, would be good to include in
>>>>> the release.
>>>>> https://review.openstack.org/#/q/status:open+branch:stable/juno+topic:openstack/requirements,n,z
>>>>
>>>> +2,
>>>>>
>>>> let's keep all deps in sync. Those updates do not break anything
>>>> for existing users.
>>>
>>> Just spotted it, there is now proposal to revert caps in Juno:
>>>
>>> https://review.openstack.org/138546
>>>
>>> Doug, shall we stop merging caps to projects in Juno?
>>
>> Today we found that when we have caps in place that do not overlap with the versions used in master, we can’t upgrade services one at a time on a host running multiple services. We didn’t have this problem between icehouse and juno because I used the same cap values for both releases, so we didn’t trigger any problems with grenade.
>>
>> One solution is to undo the caps and then add caps when we discover issues in new versions of libraries and stable branches. Another is to require applications to work with “old” versions of libraries and degrade their feature set, so that we can keep the lower bounds overlapping.
>>
>> In retrospect, this issue with caps was obvious, but I don’t remember it being raise in the planning. As Sean pointed out on IRC today, we should have someone write a spec for changing the way we deal with requirements so we can think about it before deciding what to do.
>>
>> After the releases today, the “no more alpha versions for Oslo” ship has sailed. Removing the caps will at least let us move ahead while we figure out what to do for stable branches.
>
>Yes, looks like we need to think a bit deeper about it, and at the very
>least not ship them in the point release.
>
>+2 on the requirements revert.

I just read this and I agree.

The same thing applies for the cap planned for glance_store, which I
had already -2'd.

Cheers,
Fla

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141203/5b1888fa/attachment.pgp>


More information about the OpenStack-dev mailing list