On 01/15/2015 05:21 AM, Nikola ─Éipanov wrote:
> On 01/15/2015 10:35 AM, Joe Gordon wrote:
> 
>> So how could we have avoided this problem? By capping stable branch
>> requirements so we only have to worry about uncapped dependencies on
>> master. Capping stable branches has been previous discussed but no
>> action has been taken. So going forward I propose we pin all
>> requirements, including transitive, on stable branches. This way the
>> release of new dependencies cannot automatically break stable branches
>> and thus break grenade on master.
>>
> 
> This is an absolute must IMHO, including transitive dependencies,
> because if they are not capped - they can cause other issues like bring
> in additional deps a stable release is not even supposed to have, among
> all the usual issues.
> 
> The problem as I understand it is that this breaks how we do upgrades
> testing in the gate, AKA "the granade job" (all in a single VM, install
> everything from pip). IMHO this is broken and needs to be fixed ASAP, if
> capping breaks it.

That's a mis understanding of the last issue, grenade handles this fine.

The capping only caused a problem because we were upgrading components
in an incorrect issue: Swift upgrading before Ceilometer, even though
Ceilometer had middleware installed in Swift. Which meant that for
almost ever we were actually running new Swift with old Ceilometer
middleware.

That was fixed here - https://review.openstack.org/#/c/142075/

The policy decision to cap stable requirements was agreed to previously
(and at summit this year), it just needs someone to implement. This also
came up in this keystoneclient thread from last week -
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html

Volunteers welcomed.

        -Sean

-- 
Sean Dague
http://dague.net

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to