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

[Ludwig Krispenz]

On 06/06/2014 06:12 PM, Dmitri Pal wrote:
> 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
ok, so this will be handled outside of the topology plugin, a future 
step could be to define topology types and connectivity rules and have 
the topology plugin to verify this