Open Stack

On 10/7/2015 6:00 PM, Robert Collins wrote:
> On 8 October 2015 at 08:38, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
>> Here's why:
>>
>> https://review.openstack.org/#/c/220622/
>>
>> That's marked as fixing an OSSA which means we'll have to backport the fix
>> in nova but it depends on a change to strutils.mask_password in oslo.utils,
>> which required a release and a minimum version bump in global-requirements.
>>
>> To backport the change in nova, we either have to:
>>
>> 1. Copy mask_password out of oslo.utils and add it to nova in the backport
>> or,
>>
>> 2. Backport the oslo.utils change to a stable branch, release it as a patch
>> release, bump minimum required version in stable g-r and then backport the
>> nova change and depend on the backported oslo.utils stable release - which
>> also makes it a dependent library version bump for any packagers/distros
>> that have already frozen libraries for their stable releases, which is kind
>> of not fun.
>>
>> So I'm thinking this is one of those things that should ultimately live in
>> oslo-incubator so it can live in the respective projects. If mask_password
>> were in oslo-incubator, we'd have just fixed and backported it there and
>> then synced to nova on master and stable branches, no dependent library
>> version bumps required.
>>
>> Plus I miss the good old days of reviewing oslo-incubator syncs...(joking of
>> course).
>
> Whats wrong with 2?  I mean, other than the work needed *because* we
> made branches of oslo.utils: something I hope we can stop doing in M
> (I have a draft spec up about this...)
>
> Libraries have security bugs too, and packagers/distros need to update
> them as well as the API servers: this is one of the reasons we have
> backpressure on libraries being admitted into our dependency chain.
>
> -Rob
>
>

The work involved isn't the problem, I was more concerned about raising 
the minimum required version of a library on stable. But I guess it can 
happen and packagers/deployers/distros can update their packages on 
stable or patch them as needed (that's probably what we'd do internally 
since we have to legally clear each package we ship ourselves and 
version bumps are generally not fun for us on stable).

-- 

Thanks,

Matt Riedemann