On 01/07/2015 05:35 PM, Simo Sorce wrote:
On Wed, 07 Jan 2015 17:23:08 +0100
Ludwig Krispenz <lkris...@redhat.com> wrote:
On 01/07/2015 05:13 PM, Simo Sorce wrote:
On Wed, 07 Jan 2015 17:11:53 +0100
Ludwig Krispenz <lkris...@redhat.com> wrote:
Now, with some effort this can be resolved, eg
if the server is removed, keep it internally as removed server
and for segments connecting this server trigger removal of
replication agreements or mark a the last segment, when tried
to remove, as pending and once the server is removed also
remove the corresponding repl agreements
Why should we "keep it internally" ?
If you mark the agreements as managed by setting an attribute on
them, then you will never have any issue recognizing a "managed"
agreement in cn=config, and you will also immediately find out
it is "old" as it is not backed by a segment so you will safely
remove it.
I didn't want to add new flags/fields to the replication
agreements as long as anything can be handled by the data in the
shared tree.
We have too. I think it is a must or we will find numerous corner
cases. Is there a specific reason why you do not want to add flags
to replication agreements in cn=config ?
Simo and I had a discussion on this and had agreed that the
"marking" of a replication agreement
as controlled by the plugin could be done by a naming convention on
the replication agreements.
They are originally created as "cn=meTo<remote host>,..." and would
be renamed to something like
"cn=<local host>-to-<remote host>,....." avoiding to add a new
attribute to the repl agreement schema.
Unfortunately this does not work out of the box. I only discovered
afetr implementing and testing (was not aware of before :-)
that DS does not implement modrdn operation for internal backends,
It just returns unwilling_to_perform.
And if it will be implemented the replication plugin will have to
be changed as well to catch the mordrdn to update the in memory
objects with the new name (which is used in logging).
So, if there is no objection, I will go back to the "flag"
solution.
What about simply deleting the agreement and adding it back with the
new name ?
it will stop replication and the restart it again, unnecessary
interrupting replication for some time.
Assume you have a working topology and then raise the domain level
and the plugin becomes active,
creates segments and "marks" agreements as controlled. This should
happen as smooth as
possible.
While this is true, it is also a rare operation. I do not see it as a
big deal to be honest.
However if you prefer to add a flag attribute that is fine by me too.
after thinking a bit more about it, I don't think we need the mark at
all. The
agreement would have been marked in two scenarios
- the agreement exists and the dom level is raised, so that a segment is
created from the agreement
- the dom level is set, the plugin active and a segment is addded to the
shared tree
so that a replication agreement is generated.
In all cases where an agreement is marked, there is a 1:1 corresponding
segment,
so the existence of a segment should be marking enough.
I will make the mark_agreement and check_mark as noops, so if we really
run into a
scenario where a mark would be required, it can be added in one of the
methods discussed
so far.
Simo.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
