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.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
