[Freeipa-devel] Move replication topology to the shared tree

[Dmitri Pal]

On 06/06/2014 09:03 AM, Simo Sorce wrote:
> On Fri, 2014-06-06 at 06:58 -0400, James wrote:
>> On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz <lkrispen at redhat.com> wrote:
>>> Ticket 4302 is a request for an enhancement: Move replication topology to
>>> the shared tree
>>
>> One comment to add:
>>
>> It would be particularly useful if the interface used to set the
>> topology is something sane that a single host can use to set its
>> peers. Eg:
>>
>> host1$ ipa-topology-set-peers host2
>> host2$ ipa-topology-set-peers host3
>> host3$ ipa-topology-set-peers host4
>> host4$ ipa-topology-set-peers host1 # redundant, but okay...
>>
>> This way config management could define topologies in terms of algorithms. Eg:
>>
>> Ring topology:
>> Order hostnames alphabetically.
>> Peer with host name index of self + 1
>> (Example shown above)
>>
>> Star topology:
>> Peer with every other host in list
>>
>> Pick two topology:
>> Peer with each subsequent hosts in ordered list...
>>
>> And so on...
>> If running the command changes the topology again, then that's great
>> because changing the algorithm would re-arrange the graph :)
>>
>> Hope this made sense.
> Oh it does!
>
> But I am dreaming even bigger, my aim is to end up (in the long run)
> with something like:
>
> ipa topology change --stellar host1 host2 host3 host4 host5
>
> causes topology for those 5 servers only (ignores any other connection)
> to become:
>
>          host2
>            |
> host3 - host1 - host5
>            |
>          host4
>
> So any agreement between host1 and 2,3,4,5 get wiped and replaced with
> the stellar topology. (agreements between 1,2,3,4,5 and 6,7,8,9 are not
> affected in any way and stay).
>
> And later on you'd be able to say
> ipa topology change --circular host1 host2 host3 host4
>
> and you get:
>
> host1 - host2
>    |       |
> host4 - host3
>
> Note that if you previously did the stellar thing and you only have
> these 5 servers the actual complete topology ends up being like this:
>
> host5
>    |
> host1 - host2
>    |       |
> host4 - host3
>
> As the agreement between host1 and host5 is not touched by the second
> command.
>
> But this is in the far future IMO, we'll probably start by only
> implementing:
>
> ipa topology set-peering host1 host2
> and
> ipa topology break-peering host3 host4
>
> Ie creating and breaking segments in the topology tree only between
> pairs and storing/deleting the segment object in the shared tree.
>
> The reason is that the topology plugin will allow or disallow changes
> based on whether you are breaking the graph, and it is much simpler to
> do that if you change one object at a time. To do the nifty stuff above
> we'd need some staging area where we describe all the changes and then
> have a "commit" type change that would cause the topology plugin to do
> all the calculations and move stuff around inside at once (or refuse the
> commit if the change as a whole breaks the graph).
>
> HTH,
> Simo.
>
I was thinking about the commit and staging too. I think this approach 
will be beneficial for the "rebuild from existing non replicated 
agreements" use case too.
The logic for the use case that I described in other branch of this 
discussion will be:
- Collect all info by contacting all the servers.
- Save in staging
- Analyze that topology makes sense and graph is not broken (error out 
if it is)
- Start transaction
- Put the data into the replicated tree
- Stop transaction
- Start replicating

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.