[Freeipa-devel] Replication Topology design feedback

[Ludwig Krispenz]

hi,

you have to remove the server from the manged servers, 
ipa-replica-manage del would do it, but it fails in line:13 "not allowed 
on leaf entry"
This is a bug I reported today. In my tests I did use a script to delete 
a master and its services (before).
Tomas has proposed a fix, which should allow ipa-replica-manage del succeed.

What is interesting in your log is line:7, it contains a corrpted ruv, 
and we have been trying to reproduce this, but did fail so far. Could 
you provide me a full log of actvities you have don in this test scenario ?

Regards,
Ludwig

On 05/06/2015 04:47 PM, Oleg Fayans wrote:
> Hi Ludwig,
>
> I have a question. What is the proper way of removing ipa replica from
> the server that is replication-topology-aware? Standard way
> `ipa-replica-manage del` does not work anymore, since the topology is
> controlled by the plugin, but I was unable to remove it using
> topology-aware tools as well. Here is the transcript of my session:
> http://pastebin.test.redhat.com/281213
>
> Thanks in advance!
>
>
> On 05/04/2015 04:46 PM, Martin Kosek wrote:
>> Thanks for answers.
>>
>> BTW, for future, I think Oleg that it would be useful to ask this questions on
>> freeipa-devel directly as it may be helpful to other developers and we would
>> have it archived for other uses.
>>
>> On 05/04/2015 04:20 PM, Ludwig Krispenz wrote:
>>> On 04/30/2015 03:22 PM, Oleg Fayans wrote:
>>>> Hi Ludwig,
>>>>
>>>> While getting myself familiar with Replication Topology Plugin design
>>>> page I've found a number of places that need some clarifications.
>>>>
>>>> 1.
>>>>> Check at startup.
>>>>> When the directory server starts, the plugin init and start functions
>>>> are executed, they will read the domain level
>>>>> attribute and act accordingly
>>>> Could you describe how exactly should the plugin work depending on the
>>>> domain level revealed.
>>> there are only two scenarios:
>>> 1] domain_level < plugin_level:
>>> the plugin does almost nothing, reading its config and waiting for a dom level
>>> increase
>>> 2] doamin_level >= plugin_level:
>>> the plugin controls topology for managed servers, rejecting direct mods of
>>> replication agreements, transforming adding/deleting/modification of segments
>>> into corresponding actions on replication agreements
>>>> 2.
>>>>> Check for modify operation
>>>>> If an admin or tool changes the domain level the plugin detects this
>>>> change and performs initialization tasks if the
>>>>> domain level is greater than the plugin version
>>>> The same here: what exactly happens after the domain level has changed.
>>> if the domain level raises, so that teh plugin becomes active, this will happen
>>> on all servers since domain level is replicated.
>>> the plugin will read all the exisußing info inthe shared tree, read all
>>> replication configuration and match them creating missing data in both areas:
>>> cn=config and shared tree
>>>> 3. Regarding the startup delay. How can I make sure the plugin has started?
>>>> As far as I understood the Topology plugin needs to be started only
>>>> after all other plugins are started to prevent it from making a tree
>>>> changes before it is able to be replicated. The question is: how do I
>>>> check whether all other plugins are already started?
>>> the plugin should be started when the server starts, it will expose this in the
>>> root dse and you can search for it, I just updated teh design page with an example
>>>> 4. Shared configuration layout
>>>> It is written there, that the replication topology information can be
>>>> configured to be stored in the custom place of the tree. How do we do that?
>>> The configuration is in the plugin conf in cn=config. At the moment it is
>>> populated when a DS instance is created.
>>>
>>>> Most probably I''ll have some more questions once I have the branch
>>>> installed.
>>>>
>>>> Thank you!
>>>>