On Fri, 2014-06-06 at 09:03 -0400, 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,
Then I like you :)

>  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
Sounds good to me.

> 
> 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).
I like this idea of the staging area. If a ticket or BZ happens, and
someone remembers, please cc me :)

Cheers!

> 
> HTH,
> Simo.
> 

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to