Re: [tor-dev] Using Stem's descriptor fetching module to replace the Java consensus-health checker

[Damian Johnson <atagar@xxxxxxxxxxxxxx>]

> I'm only interested in providing directory authority operators with the
> information they need to fix problems with the voting process.

Hi Karsten. I'm going to focus on the monitors for now and come back
to discussion of a website after Sebastian and Peter have a chance to
respond. That said, we totally agree on this point - the goal of this
project is solely to help detect and resolve issues with authorities
and consensus generation. If the website is vital to that then great
(I still think it should be its own repository, but it's then
definitely worth keeping). However, if we can do just as well by
including additional information in the warnings then that would be
even more maintainable in the long term.

My thoughts on this are probably best explained by a tangent. For
years I've run a sybil checker called consensusTracker.py [1]. This
checker did a bit more than just watch for sybil attacks. It also
generated a pretty html report of the wax and wane in relay counts
over the week among other things.

While these bells and whistles were pretty, no one cared about them
and rightfully so. The sole purpose of a sybil checker is to provide
us a notification saying "Oi! Potential problem here, recent relay
additions are...".

The html report, while pretty, was both useless and made the code far,
far more complicated than it needed to be. Finally I replaced that 601
line script with a far simpler 116 line counterpart that does just
what we want and nothing more [2]. The monitor is now more reliable,
maintainable, and can easily be updated in the future when necessary
(something I couldn't do with the mess that was the previous script).

The lesson that I learned from this was "Start with the ending goal of
a project and code toward that. Anything else will just result in
feature creep." This isn't to necessarily say the DocTor website is
unnecessary (only the site's intended audience like Peter can tell us
that), but I definitely think we should figure out what he needs
before resolving to keep it.

Cheers! -Damian

[1] https://gitweb.torproject.org/atagar/tor-utils.git/blob/e537044:/consensusTracker.py
[2] https://gitweb.torproject.org/atagar/tor-utils.git/commitdiff/9b7de30
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev