On 05/26/2014 12:48 PM, Petr Viktorin wrote: > On 05/14/2014 12:50 PM, Petr Viktorin wrote: >> On 04/30/2014 10:00 AM, thierry bordaz wrote: >>> On 04/29/2014 10:07 PM, Martin Kosek wrote: >>>> On 04/29/2014 08:17 PM, Simo Sorce wrote: >>>>> On Tue, 2014-04-29 at 20:00 +0200, Petr Viktorin wrote: >>>>>> This adds the "idnsSecInlineSigning" attribute and related option. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3801 >>>>>> >>>>>> Simo, is adding a MAY attribute to an existing objectClass okay? >>>>>> >>>>> >>>>> Not unheard of, however in the past we discovered some schema >>>>> replication issues that may have an impact, let's make sure DS team >>>>> also >>>>> agrees this is not going to cause issue. >>>>> >>>>>> From a purely functional pov a MAY attribute will not break any stored >>>>> object, so it is fine. >>>>> >>>>> Simo. >>>> >>>> Adding Thierry to the CC list to evaluate the risks, he was already >>>> involved in fixing related issue in the DS for a similar Dogtag schema >>>> extension. >>> Hello, >>> >>> When an instance in the topology contains schema extensions like new >>> MAY attribute, this extension would be propagated to all instances >>> by replication (no need to copy/merge schema files). This was the >>> purpose of https://fedorahosted.org/389/ticket/47721. So it is fine >>> to add new MAY/MUST attribute or new attribute/objectclasses. >>> >>> During a replication session, a master will check what schema >>> definitions (objectclasses/attributes) of the replica extends its >>> own schema. If such definitions exist the supplier add/replace them >>> in its schema and its user99.ldif file. In your case if a replica >>> contains a new allowed attribute (e.g. 'idnsSecInlineSigning') but >>> not the supplier then the supplier 'learns it' (during a replication >>> session it initiated) and so an entry containing that new attribute >>> can be updated on the supplier as well. >>> There is a similar mechanism, when a replica receives a schema that >>> contains new definitions, it 'learns' them. >>> >>> The fix for 47721 is introduced in 389-ds 1.3.2.17 and after. >>> It was tested with mixing 1.3.2.17 instance with legacy versions >>> (1.3.1, 1,3.0..), and the schema on both side converged to a common >>> one. This, whatever if the extensions are present on both side. >>> A limitation is that a legacy instance (not having the fix), must >>> have a replica agreements to/from an instance with the fix. >>> >>> regards >>> thierry >>> >> >> Thanks. This means the patch is good for review. >> I've just rebased it slightly. > > Another rebase in VERSION was necessary. > Still looking for a review.
This is pretty obvious change, worked fine for me. ACK! Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
