On Mon, 16 Dec 2013, Rich Megginson wrote:
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.
No, and that's key here. Once Epoch is in place, it is forever.


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.
Ok, fine.

--
/ Alexander Bokovoy

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to