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 <lkris...@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.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
