[389-users] replication with some attributes excluded leads to schema violation

[Petr Spacek]

On 11.1.2013 16:22, Rich Megginson wrote:
> On 01/11/2013 08:13 AM, Petr Spacek wrote:
>> On 11.1.2013 15:54, Rich Megginson wrote:
>>> On 01/11/2013 06:26 AM, Petr Spacek wrote:
>>>> Hello 389 users and developers,
>>>>
>>>> I would be very happy if somebody could give me any advice about "the right
>>>> way" to solve this problem:
>>>>
>>>> I have following objectClass in the schema:
>>>> objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class'
>>>> SUP idnsRecord STRUCTURAL MUST ( idnsName $ idnsZoneActive $ idnsSOAmName $
>>>> idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire
>>>> $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowQuery $
>>>> idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ idnsForwarders ) )
>>>>
>>>> Please note MUST attribute idnsSOAserial.
>>>>
>>>> I have two 389 servers on RHEL 6.4 with the same schema:
>>>> 389-ds-base-1.2.11.15-10.el6.x86_64
>>>>
>>>> There is multi master replication agreement between machines vm-115<->vm-042.
>>>>
>>>> Attribute idnsSOAserial is excluded from incremental replication (export
>>>> from vm-042):
>>>> cn=meTovm-115,cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
>>>>
>>>> idnsSOAserial: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn
>>>> krblastsuccessfulauth krblastfailedauth krbloginfailedcount
>>
>> The list above with proper attribute name looks like:
>>
>> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof
>> idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth
>> krbloginfailedcount
>>
>>>> nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn
>>>> krblastsuccessfulauth krblastfailedauth krbloginfailedcount
>>>>
>>>>
>>>> Now I create a new object with objectClass idnsZone on vm-042. The new
>>>> object is replicated to vm-115, but the attribute idnsSOAserial is missing -
>>>> and this fact violates the schema.
>>>>
>>>>
>>>> Is it expected behaviour?
>>>
>>> Yes.  Since idnssoaserial is excluded from incremental (I think there is a
>>> typo above - idnsSOAserial: (objectclass=*) $ EXCLUDE is not correct), it is
>>> excluded from the replicated ADD operation.
>> Heh, that is my copy & paste fail :-)
>>
>>>> What I misunderstood?
>>>
>>> Nothing?
>>>
>>>>
>>>> Which approach you recommend to application developers for dealing with such
>>>> situation?
>>>
>>> So you would like idnsSOAserial to be included for replicated ADD operations
>>> but excluded for replicated MOD operations?
>>
>> It seems like best option to me, but I'm open to any other proposal which
>> solves this problem.
>
> Why don't you want idnsSOAserial to be replicated for MOD operations?

There could potentially be a high update traffic (from more servers) and we 
want to avoid replication conflicts. I will dig design document for the 
feature using this attribute.

>> Petr^2 Spacek
>>
>>>> I don't like the approach where application have to go to *all* DS to
>>>> initialize the excluded attribute, because:
>>>> What the application should do if it's unable to connect to one of DSs?
>>>>
>>>> What if rollback is impossible? (E.g. attribute was initialized on replica1
>>>> and replica2 but the link from application to the world failed before
>>>> replica3 was initialized.)
>>>>
>>>> Would it be possible to configure DS to replicate the attribute when object
>>>> is created but not replicate further changes? It would defer all problems
>>>> above to DS replication mechanism and simplify applications :-)
>>>>
>>>> Thank you for your time!


-- 
Petr^2 Spacek