Automate process from reporting bad relays to resolving them as much as possible

Currently we still have some manual steps in the process of badexiting relays between incoming reports and actual pushs to the dirauth-conf repo. We should eliminate those as good as we can.

added GeorgKoppen202002 actualpoints::2 component::metrics/consensus health network-health network-health-roadmap-2020Q1 owner::gk points::3 priority::medium resolution::fixed reviewer::dgoulet severity::normal status::closed type::defect labels

Trac:
Cc: metrics-team to N/A

Okay, I think I am done here. At least we should have a good starting point now dealing with the majority of rejection cases. A patch is up for review in my bug_33182_v2 (https://dip.torproject.org/gk/helper-scripts/commit/22e354490abc97e260fb1dd1334212ce6a2aeae5). I've used and refined the script during the last couple of bad relay incidents.

I decided to move the script we use for dealing with bad relays into the helper-scripts repo for at least two reasons:

1. It's nothing that has to be sekrit and rather makes it transparent what we do when we reject/remove relays
2. It can use all the helpers in the helper-scripts repo (in particular all the stem helper infrastructure already built there). Thus, we don't need to reinvent the wheel or start using git submodule, or doing something else which would make things overly complicated.

dgoulet: with the spirit of that repo and the recent license additions to all of your other scripts, I decided to use the same copyright/license combo for the badconf-entry.py one. I know the original script as under the GPL2, so doing what I did hinges on you being okay with that. If you feel that's not cool, please speak up, that's fine. I'll make the necessary changes. (We are still discussing as a project how to deal with treating code we write while working and how to license/copyright that one. We are not done here yet, which makes it a bit hard to find an easily applicable solution)

Trac:
Reviewer: N/A to dgoulet
Status: assigned to needs_review
Actualpoints: N/A to 2

No problem, consider these scripts totally 100% free license so you can put in BSD, GPL, whatever you want as long as it remains open :).

The day Metrics gets a REST API, querying it will be much nicer than waiting to download all documents :).

This works good! I've tested it with a good and invalid fingerprint.

Later iteration could push the automation to the git commit <...> && git push level with some confirmation before you do but for now, this is great.

Trac:
Status: needs_review to merge_ready

Replying to dgoulet:

No problem, consider these scripts totally 100% free license so you can put in BSD, GPL, whatever you want as long as it remains open :).

The day Metrics gets a REST API, querying it will be much nicer than waiting to download all documents :).

This works good! I've tested it with a good and invalid fingerprint.

Later iteration could push the automation to the git commit <...> && git push level with some confirmation before you do but for now, this is great.

Thanks. Yes, I've thought about that next step and moar automation but felt what we have right now would be a good improvement and something to build upon. I definitely wanted to get a better feeling and more testing for the current script before automating the (signed) commit and push part, but, yes this is worthwhile to do.

I heard our old gitlab woes are gone. \o/ So, I'll start from now on filing issues there so we can better test a full gitlab workflow (and move away from Trac asap). That means once one of the new woes is solved (#33584 (moved)). ;)

Either way, I merged the commit to master (commit 22e354490abc97e260fb1dd1334212ce6a2aeae5). We are done here.

Trac:
Status: merge_ready to closed
Resolution: N/A to fixed

closed

changed time estimate to 24h

added 16h of time spent