On 05/28/2014 02:45 PM, Martin Kosek wrote:
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


Thanks, pushed to master: 8b7daf675e77d7a5e2de6eadb26ca3b682c0d67f

--
PetrĀ³

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

Reply via email to