[PATCH] Remove simple KCC code

[Garming Sam]

Hi,

I can definitely sympathize with being unable to debug topologies
without spending a lot of time, as will Douglas. If you actually need to
look into a particular network running the samba-kcc, --dot-file-dir
might be useful. It creates .dot graph files which you can render. For
the networks that behaved strangely, if you can run --export-ldif and
send us the results, we can possibly look into it a little further. But
probably one way or another, we do need a mode that does keep all DCs
connected.

The strange results are similar to what I expect, at least initially.
The KCC on the new DCs have decided that it must talk to those
particular DCs (and not to the one in the join). The older DCs still
have stale repsFrom, which should be eliminated after a few runs of the
new KCC running on their ends. I think there may have been a regression
with elimination of these connections within a site (not across sites)
in commit: 03e352268a80a4671b50855a977a655b095ddf18

So I would have thought that the worst case is that it remains fully
connected only within its site, not in the one DC per site scenario. It
might be worth investigating further. But I would stress that things do
take a while sometimes, which is quite like Windows from what I've seen.
I can agree that new setups are definitely more robust in terms of the
necessary requirements for the KCC. I think improving the debugging
output is a good idea to start with.


Cheers,

Garming


On 03/02/17 00:44, Stefan Metzmacher wrote:
> Hi Garming,
>
>> At the very least, I think the distinction between the old KCC and the
>> unused KCC code needs to be clear.
>>
>> These two files I believe run the full mesh:
>>
>>  source4/dsdb/kcc/kcc_service.c
>>  source4/dsdb/kcc/kcc_periodic.c 
>>
>> While the other files serve don't have any purpose (as an attempt at the
>> proper KCC algorithm in C), they should have no genuine side-effects and
>> are completely untested (and I know to be significantly incorrect, so
>> was not very useful as a reference guide for the python KCC).
> Yes, unused code should be removed.
>
>> I have no objections at all to removing the latter code, but that should
>> be done separately from the other code.
>>
>> Just to highlight what I would expect the difference between the default
>> behaviour between the old KCC and the new KCC:
>> - With a single site, you would have a double ring in the new KCC vs a
>> fully connected network
>> - With multiple sites, if they are incorrectly configured, the old KCC
>> would effectively ignore that. It also connected across sites and
>> disregards any topology, hitting firewalls and such.
>> - RODC would always stay online (however they are abusing their current
>> read-write access to the database *feature*)
>> - The new KCC probably takes longer to converge to the final
>> connectivity graph
>>
>> Where you only have a few DCs, I think the old KCC still possibly makes
>> more sense (although there's no reason why we can't do get that
>> behaviour to work in the new KCC code). But I would like to know if
>> there are any setups that actually don't work under the new KCC.
> See my previous mail to Andrew.
> I believe you that the new kcc produces good results when you setup
> a complete new domain with a configuration you want (the hub style
> topology).
>
> But I got very strange results for existing installations
> and I was not able to debug them in a few hours time.
>
> metze
>