#496 Make schema replication work at the attribute level
Closed: wontfix 3 years ago by tbordaz. Opened 11 years ago by nkinder.

The current way that schema replication works is that the entire 99user.ldif is replicated as a single unit. This means that one master can completely overwrite another masters custom schema. An example of this can be seen in the following scenario:

  • Install two DS instances (master1 and master2).
  • Add a custom objectclass to master1 named "myobjectclass1".
  • Add a custom objectclass to master2 named "myobjectclass2".
  • Set up replication between master1 and master2.
  • Add an entry to each master (NOT using the custom schema)

What will happen is that the 99user.ldif on master1 will be wiped out with the definition from 99user.ldif on master2. This happens since the last schema update wins, but all of 99user.ldif is replaced with the newer 99user.ldif.

We should change schema replication to work more like regular replication, where it is handled on the attribute/value level to avoid this chance of losing custom schema changes. We ran into loss of custom schema during IPA development due to the way Dogtag and IPA perform schema updates


A related goal for this feature would be to allow custom schema to be split into separate files. For example, a custom schema file can be represented as an "ou" in the "cn=schema" tree. Any schema changes made in that "ou" would be written into the associated schema file on disk. Other "ou" entries would map to other custom schema files. This would allow one to group their custom schema definitions by the application that needs the schema. All of the custom schema would need to be replicated, regardless of which file it is in.

I'd like to get more information about this problem. Suppose I change the code so that we don't just blindly remove existing schema, but instead only remove it if the csn is greater. What about the following case:

master1 - add schema - schema elements get CSN1 - schema is replicated to master3
master2 - add schema - schema elements get CSN2 - schema is replicated to master3

if there are any duplicates in the added schema, the definition from master2 will still replace the definition from master1 when it is replicated to master3

What if we simply did not delete any existing schema when schema is replicated? That is, doing a

mod replace attributetypes[all attributes] objectclasses[all objectclasses]

from the supplier just added missing schema or replaced differing schema, but did not delete any schema that existed only on the consumer?

Setting to FUTURE.

Comment by Thierry:
major change. May be not needed if 48031 is fixed

Metadata Update from @nkinder:
- Issue set to the milestone: FUTURE

7 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue close_status updated to: None
- Issue set to the milestone: 1.4 backlog (was: FUTURE)

3 years ago

Metadata Update from @mreynolds:
- Issue tagged with: Schema

3 years ago

Metadata Update from @mreynolds:
- Issue assigned to tbordaz

3 years ago

Since 1.3.3 (https://pagure.io/389-ds-base/issue/47490) the replication of schema definitions is done via schema learning and eventually schema push. So new attribute/objectclass definitions are propagated independently. If a server gets a schema definition that is the superset of an other server, then the schema is pushed in totality.

Closing this ticket as it is already implemented

Metadata Update from @tbordaz:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

3 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/496

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

3 years ago

Login to comment on this ticket.

Metadata