On 06/06/2014 06:12 PM, Dmitri Pal wrote:
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
On 06/06/2014 09:03 AM, Simo Sorce wrote:
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:
On Fri, 2014-06-06 at 06:58 -0400, James wrote:
On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz
Ticket 4302 is a request for an enhancement: Move replication
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
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
Order hostnames alphabetically.
Peer with host name index of self + 1
(Example shown above)
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)
host3 - host1 - host5
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:
host1 - host2
host4 - host3
As the agreement between host1 and host5 is not touched by the second
But this is in the far future IMO, we'll probably start by only
ipa topology set-peering host1 host2
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).
- 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
Freeipa-devel mailing list