translations, avoiding unspecified names loops for whois command
Those bugs were not breaking behavior, but they were causing variations
of results. It would not always store the same timestamps, sometimes breaking
tests
Most of the random come from regex map iteration
That way anybody can handle non-galera specific logs in a single view
tests/expected/operator_auto_ambiguous_ips_list_all_no_color has been
updated, it was out-of-sync due to 2 previous pull requests that were
made in parallel
--skip-merge can help for cases where merge won't work: node names
intentionally identical
grep -a enables to read logs even though they use binary format
It was using maps in each context, which would be merged between
contexts, then injected each time we needed a message to display.
It had a limitation on complicated operator setups: historical
information would be overriden by newer associations.
(e.g, that IP was for node0 yesterday, now it's node1, so associations
have been overwritten and incorrect)
It also introduced complexity, such as forcing to define closures too
many times, merging maps, it would be harder to debug, and every files
were starting from empty translation maps.
Moreover, iterating on maps is guaranteed to be random so it could create
hard-to-debug output variations on complex cases.
Now it is a singleton in translate package, still using maps but now it
associates an array of "units" storing the timestamp with each piece of information.
It is protected by rwmutex, because map are not threadsafe. (there's no
parallel processing for now)
No regressions, and it passes "operator_ambiguous_ips_list_all_no_color"
where the old system failed.
It nows also can be used as an easy to read source of information in
itself
It existed for non-operator setup, but was not working for operators due
to k8s logs not interpreting newlines and tabs
This operator version re-uses existing regular regex handlers directly
It must test multiple times to remove doubts.
As the tool is reading files and relying on maps, their access order are
random. It can impact some translations
When adding "ownip", it was also propagating the new IP to the old hash.
But with operators, when IP where changing hash will also change, so
linking the new IP to old hash is anachronic. It is not wrong, but
depending on the order of map merges, the newest information could have
been overriden depending on the order of events.
That situation was producing X(2*number of conflicts) versions of output for operators, with
different md5sum, which could produce false-positive regression tests
So currently some information are not linked anymore, so some IPs are
not translated even though they could, but it is a limitation of using
maps as source of truth, as they are not versioned
