Re: [Freeipa-devel] Update: Re: Fedora 20 Release

2013-12-17 Thread Petr Spacek

On 17.12.2013 17:40, Alexander Bokovoy wrote:

On Tue, 17 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)
  https://fedorahosted.org/389/ticket/47624 (regression)

Fixed.


Replication:
  https://fedorahosted.org/389/ticket/47632 (?)


Cannot reproduce.  Closed as WORKSFORME.



Stability:
  https://bugzilla.redhat.com/show_bug.cgi?id=1041732

Fixed.

https://fedorahosted.org/389/ticket/47629 (we are not sure if the syncrepl
really plays some role or not)


We are still trying to determine the cause, and if this is related to the
use of syncrepl.  If it turns out to be related to syncrepl, I would like to
release 1.3.2.9 in F20, and just disable the use of syncrepl in 389 clients.

Is everyone ok with this?

It works for me.


Fine for me. Once you get update out, we can issue FreeIPA update that
requires new 389-ds-base and slapi-nis (slapi-nis was already released
so we cannot combine all three packages in the same update).


I'm not sure that we need/want to release a freeipa package with new requires. 
Users just need to upgrade all packages as usual.
(Note that users will not get the new freeipa package with new requires 
until they run yum upgrade anyway, so I don't see a big value in new release.)


--
Petr^2 Spacek

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


Re: [Freeipa-devel] Update: Re: Fedora 20 Release

2013-12-17 Thread Mark Reynolds


On 12/17/2013 11:35 AM, 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)
   https://fedorahosted.org/389/ticket/47624 (regression)

Fixed.


Replication:
   https://fedorahosted.org/389/ticket/47632 (?)


Cannot reproduce.  Closed as WORKSFORME.



Stability:
   https://bugzilla.redhat.com/show_bug.cgi?id=1041732

Fixed.
https://fedorahosted.org/389/ticket/47629 (we are not sure if the 
syncrepl really plays some role or not)


We are still trying to determine the cause, and if this is related to 
the use of syncrepl.  If it turns out to be related to syncrepl, I 
would like to release 1.3.2.9 in F20, and just disable the use of 
syncrepl in 389 clients.


Is everyone ok with this?

Rich I found a crash in 1.3.2 and 1.3.1.  This should go into 1.3.2.9(or 
a 1.3.2.10).


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.


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






--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreyno...@redhat.com

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


Re: [Freeipa-devel] Update: Re: Fedora 20 Release

2013-12-17 Thread Rich Megginson

On 12/17/2013 11:19 AM, Mark Reynolds wrote:


On 12/17/2013 11:35 AM, 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)
   https://fedorahosted.org/389/ticket/47624 (regression)

Fixed.


Replication:
   https://fedorahosted.org/389/ticket/47632 (?)


Cannot reproduce.  Closed as WORKSFORME.



Stability:
   https://bugzilla.redhat.com/show_bug.cgi?id=1041732

Fixed.
https://fedorahosted.org/389/ticket/47629 (we are not sure if the 
syncrepl really plays some role or not)


We are still trying to determine the cause, and if this is related to 
the use of syncrepl.  If it turns out to be related to syncrepl, I 
would like to release 1.3.2.9 in F20, and just disable the use of 
syncrepl in 389 clients.


Is everyone ok with this?

Rich I found a crash in 1.3.2 and 1.3.1.  This should go into 
1.3.2.9(or a 1.3.2.10).


Ok.



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.


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








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


Re: [Freeipa-devel] Update: Re: Fedora 20 Release

2013-12-17 Thread Rich Megginson

On 12/17/2013 11:23 AM, Rich Megginson wrote:

On 12/17/2013 11:19 AM, Mark Reynolds wrote:


On 12/17/2013 11:35 AM, 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)
   https://fedorahosted.org/389/ticket/47624 (regression)

Fixed.


Replication:
   https://fedorahosted.org/389/ticket/47632 (?)


Cannot reproduce.  Closed as WORKSFORME.



Stability:
   https://bugzilla.redhat.com/show_bug.cgi?id=1041732

Fixed.
https://fedorahosted.org/389/ticket/47629 (we are not sure if the 
syncrepl really plays some role or not)


We are still trying to determine the cause, and if this is related 
to the use of syncrepl.  If it turns out to be related to syncrepl, 
I would like to release 1.3.2.9 in F20, and just disable the use of 
syncrepl in 389 clients.


Is everyone ok with this?

Rich I found a crash in 1.3.2 and 1.3.1.  This should go into 
1.3.2.9(or a 1.3.2.10).


Ok.


389-ds-base-1.3.2.9 is now in Fedora 20 updates testing.  Please test 
and give karma.  This release fixes everything except 
https://fedorahosted.org/389/ticket/47629 random crash in 
send_ldap_search_entry_ext(), which, in my testing, appears to be 
related to syncrepl, and therefore imo should not hold up the release of 
1.3.2.9 into Fedora 20.







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.


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








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


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