[Freeipa-devel] Fedora 20 Release

[Rich Megginson]

On 12/16/2013 09:21 AM, Alexander Bokovoy wrote:
> On Mon, 16 Dec 2013, 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?
> Only if there is a crash.

I don't think there is a crash here.

>
>>
>>> 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
> slapi-nis part seems to be a double-free on plugin shutdown.
> I'll look into it tomorrow morning if Nalin will not find it earlier.
>
>
>>> https://fedorahosted.org/389/ticket/47629 (we are not sure if the 
>>> syncrepl really plays some role or not)
>>
>> How can we find out?
>>
>>>
>>> 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?
> Packaging issue -- epoch will have to be increased and maintained
> forever. It is weird but that's what it is.

Sure.  But that's a one time thing.  And, it's only for F20 - once we go 
to F21, we can remove the epoch.

> And then making sure
> disabling the plugins will happen only on downgrade, this is actually an
> RPM trigger which is something people easily get wrong.

I think it's simpler than that - if the version is 1.3.1, disable/remove 
the plugins.  If the version is 1.3.2, add/enable the plugins.  I don't 
think this will be a big deal.

>
>
>>> 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.
>>
>