[Freeipa-devel] Fedora 20 Release

[Petr Spacek]

On 16.12.2013 17:15, Rich Megginson wrote:
> On 12/16/2013 08:07 AM, Petr Spacek wrote:
>> Hello list,
>>
>> we have to decide what we will do with 389-ds-base package in Fedora 20.
>>
>> Currently, we know about following problems:
>>
>> Schema problems:
>>    https://fedorahosted.org/389/ticket/47631 (regression)
>
> Fixed.
>
>>
>> Referential Integrity:
>>    https://fedorahosted.org/389/ticket/47621 (new functionality)
 >
> Does it matter if new functionality is a problem?

I think that this is not a problem for now. I just copied it from Nathan's 
mail, I'm sorry for the noise!

>> https://fedorahosted.org/389/ticket/47624 (regression)
>>
>> Replication:
>>    https://fedorahosted.org/389/ticket/47632 (?)
>>
>> Stability:
>>    https://bugzilla.redhat.com/show_bug.cgi?id=1041732
>
> Fixed.  However, there is a problem with slapi-nis:
> https://bugzilla.redhat.com/show_bug.cgi?id=1043546
Alexander is looking into it.

>> https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl
>> really plays some role or not)
>
> How can we find out?

I can't find a way how to reproduce it. I have seen 3 crashes in one hour and 
then nothing for a day ...

>> One option is to fix 1.3.2.x as quickly as possible.
>>
>> Another option is to build 1.3.1.x for F20 with Epoch == 1 and release it as
>> quickly as possible.
>>
>> The problem with downgrade to 1.3.1.x is that it requires manual change in
>> dse.ldif file. You have to disable 'content synchronization' (syncrepl) and
>> 'whoami' plugins which are not in 1.3.1.x packages but were added and
>> enabled by 1.3.2.x packages.
>>
>> In our tests, the downgraded DS server starts and works after manual
>> dse.ldif correction (but be careful - we didn't test replication).
>>
>> Here is the main problem:
>> 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is not way
>> how to replace it there. It means that somebody can do F19->F20 upgrade from
>> ISO and *then* upgrade from repos will break his DS configuration (because
>> of new plugins...).
>>
>> Simo thinks that this is a reason why 'downgrade package' with 1.3.1.x
>> inevitably needs automated script which will purge two missing plugins from
>> dse.ldif.
>
> We have an upgrade/downgrade framework, it should be easy to disable/remove
> these plugins.
>
> Is that it?  Are there any other problems found attempting to downgrade 1.3.2
> to 1.3.1 in F20?

Disabling plugins should be enough, we didn't find any other problem.

>> Nathan, is it manageable before Christmas? One or either way? Is you think
>> that the downgrade is safe from data format perspective? (I mean DB format
>> upgrades etc.?)
>
> The db format in 1.3.1 and 1.3.2 is the same, so there should be no problems
> there.

Great.

-- 
Petr^2 Spacek