Free Software Efforts (2018W32)
Here’s what I’ve been up to:
Lots of Relay Search and Onionoo this week.
Fixes to the aggregated map and top relays views were made to complete changes that had happened elsewhere in the codebase but not been kept in sync here. Unfortunately there is a little too much logic in Relay Search that really should be handled by the backend which has lead to code duplication in places.
There are now experimental and outdated additional flags for relays as more specific versions of the “Not Recommended” additional flag. While the “Not Recommended” flag is based on an assertion by the directory authorities, there is logic in Onionoo to perform version number comparisons to decide if a relay is experimental or outdated. A recent CollecTor error meant that Onionoo had not been specifying recommended versions, which led all relays to be deemed as “Not Recommended”. It is now assumed that all relays run recommended versions unless specifically asserted that they do not.
Finally, Relay Search views will display the Onionoo protocol version and build revision in the footer of the page which can be useful when reporting errors or bugs.
In order to implement the new experimental and obsolete flags, those icons needed to be finished. They are finalised for now as:
Experimental and Outdated Icons
Onionoo Graph History Documents
we changed the way we configure Jackson (a JSON library for Java) in Onionoo.
This change was made to the
Document base class but what we had missed is
GraphHistory documents don’t inherit from this base class. As a
result, they were incorrectly configured.
The Onionoo protocol specifies the format for timestamps in graph history documents (for example: bandwidth, weights or clients documents) but Onionoo stopped formatting these correctly and instead starting writing integer timestamps. (See #27039)
In order to fix this, it will be necessary to rewrite the data that is currently stored on the Onionoo servers. In order to get this right the first time, I have set up a local Onionoo instance with the data directory stored in a ZFS dataset. This allows me to easily roll back changes to match the state that the actual Onionoo servers will be in in an almost zero-cost operation.
I’m still playing with using ZFS snapshots for testing like this, but I think it may become a very useful tool for checking potentially dangerous changes before we deploy.
I also attended the Metrics team meeting on Thursday afternoon.
This post was syndicated on: