You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Stefan Seelmann <ma...@stefan-seelmann.de> on 2015/03/15 10:26:00 UTC

[Studio] Configuration editor doesn't preserve operational attributes

Hi,

I work on DIRSTUDIO-1016 and changing the configuration editor to
support multi-file LDIF configuration partition.

What I found with the current editor: if we open the config.ldif, make
some changes, and save it, we just rewrite the whole file and all
operational attributes (entryUUID, entryCSN) are newly created. For sake
of simplicity I'd implement saving to multi-file LDIF partition the same
way (delete the conf directory and recreate it).

But I wonder if that is ok? Is the config partition meant to be
replicated (then it may be a problem)?

Kind Regards,
Stefan

Re: [Studio] Configuration editor doesn't preserve operational attributes

Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 03/15/2015 11:05 AM, Kiran Ayyagari wrote:
> yes, as you suspected, this leads to problems in replication.
> When we decide to replicate configuration the state will be
> evaluated based on these operational attributes (entryCSN and contextCSN
> specifically)
> 
> Can we just send the mods instead of re-writing all entries?

I think so. We already have a PartitionsDiffComputer class that is used
to edit configuration of a remote server.

Howerver when editing the config we only deal with the partition
directly, there is no running server. So modifications don't go through
the interceptor chain and we'd have to take care that operational
attributes are correctly maintained (add entryUUID etc for new entries,
update modifyTimestamp etc on update).


Re: [Studio] Configuration editor doesn't preserve operational attributes

Posted by Kiran Ayyagari <ka...@apache.org>.
On Sun, Mar 15, 2015 at 5:26 PM, Stefan Seelmann <ma...@stefan-seelmann.de>
wrote:

> Hi,
>
> I work on DIRSTUDIO-1016 and changing the configuration editor to
> support multi-file LDIF configuration partition.
>
> What I found with the current editor: if we open the config.ldif, make
> some changes, and save it, we just rewrite the whole file and all
> operational attributes (entryUUID, entryCSN) are newly created. For sake
>
ah didn't know that they are being recreated, this is not good

> of simplicity I'd implement saving to multi-file LDIF partition the same
> way (delete the conf directory and recreate it).
>
> But I wonder if that is ok? Is the config partition meant to be
>
no

> replicated (then it may be a problem)?
>
yes, as you suspected, this leads to problems in replication.
When we decide to replicate configuration the state will be
evaluated based on these operational attributes (entryCSN and contextCSN
specifically)

Can we just send the mods instead of re-writing all entries?


>
> Kind Regards,
> Stefan
>



-- 
Kiran Ayyagari
http://keydap.com

Re: [Studio] Configuration editor doesn't preserve operational attributes

Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 15/03/15 10:26, Stefan Seelmann a écrit :
> Hi,
>
> I work on DIRSTUDIO-1016 and changing the configuration editor to
> support multi-file LDIF configuration partition.
>
> What I found with the current editor: if we open the config.ldif, make
> some changes, and save it, we just rewrite the whole file and all
> operational attributes (entryUUID, entryCSN) are newly created. For sake
> of simplicity I'd implement saving to multi-file LDIF partition the same
> way (delete the conf directory and recreate it).
>
> But I wonder if that is ok? Is the config partition meant to be
> replicated (then it may be a problem)?

The current implementation (ie one biug file) is problematic during
replicating just because we update all the entryCSN/entryUUID : that
means everything get replicated...

The idea of multiple files for config is to avoid having to replicate
everything, but just updating the entryCSN of the modified entries and
only those.

So with respect to this constraint, I'd say that we should be careful
not to update anything that hasn't be changed, which might require some
extra work...

Thanks !