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

[Karsten Loesing <karsten@xxxxxxxxxxxxxx>]

On 8/12/13 10:51 AM, Damian Johnson wrote:
>> The kludge is that checks and website don't share code, not that there's
>> a website.  The idea of the typical use case is that people receive a
>> warning via email or IRC and then go to the website to learn more details.
> 
> I disagree. This repository contains two very distinct applications:
> 
> * monitors for issues with the votes
> * a website that renders the present content of the votes

If someone's only interested in a presentation of vote contents, then
DocTor shouldn't be their tool.  If vote contents are interesting to
anyone, we should add them to Onionoo and have some Onionoo client
present them.  This is not what I have in mind for DocTor.

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

(Also note that you only mention votes above.  But DocTor also looks at
problems with serving consensuses, e.g., connection problems when
downloading the consensus, or serving outdated consensuses.)

> The use cases for each are associated, but bundling them together
> makes about as much sense as lumping vidalia and tor within the same
> repository.

That's not really true.  What you don't see right now is that problems
with the consensus or votes would be highlighted in the website output.
 For example, if either gabelmoo or mori1 or tor26 is missing a certain
recommended version, that line will be printed in red.  So, there's a
close relation between status notifications and the website, just not in
the code.

> Personally I'm a big fan of these monitors, but less so the website. I
> don't think it's especially useful (precious few people have cause to
> find a side-by-side comparison of vote attributes to be interesting,
> and fewer still would opt for this over reading the documents). But
> that said, it's not overly much code. I might toy with Hyde to
> generate the site after finishing the monitors but no promises. That
> part is not something I would want to own for the long term, though.

Well, maybe let's step back then and find a solution that you're happy
to own for the long term.  Once your tool is online, I'm planning to
shut down the current consensus-health checker including the website
output, so your tool should contain all the information that people need
to fix problems in the consensus.

In my view, writing the results of a DocTor run to a website and
highlighting problems in red was the easiest way to provide directory
authority operators with all information they need.  I could also
imagine adding additional information about warnings to the bottom of
status notification emails.  So, warnings on top and then one paragraph
for each warning requiring additional information.  Or maybe there are
other ways to provide this additional information.

We should also include Sebastian and Peter in this discussion, because
they cared about consensus-health output in the past and may have more
suggestions.  Cc'ed them.

Thanks,
Karsten

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev