spike: Can we configure Avahi with a static .service file?

[SyntaxColoring]

Overview

Various things on the robot have their own notion of a human-readable name. Our software does its best to keep them all in sync, but there are problems with this. This ticket is to investigate whether we can divorce our software from one of these things in particular, the Avahi service name. This would solve a couple of open bugs and make things simpler and more maintainable.

Details

Robot discovery involves the mDNS and DNS-SD network protocols. These protocols require each machine to advertise a human-readable instance name. This is apparently what Avahi calls the "service name" (which is confusing because "service name" is something entirely different in the DNS-SD spec).

Currently update-server is in charge of supplying Avahi with the service name. It keeps the Avahi service name in sync with what HTTP clients get and set at the /server/name endpoint.

This turns out to be surprisingly nuanced, and there are currently two bugs related to it:

• bug: update-server bricked after POST /server/name with input that Avahi doesn't like #9960
  • This has to do with edge cases around what input counts as valid, and how robot-server handles the case where input is invalid for the Avahi service name but valid for other things.
• bug: Robot stops advertising itself when another device has the same name #10126
  • This has to do with multiple robots on the same network having the same name. Since update-server is the thing supplying Avahi with the name, update-server is supposed to be responsible for automatically modifying the name to deconflict (such as by appending (2)), but it doesn't currently do this.

It seems like things would be quite a bit simpler if we stopped attempting to keep the Avahi service name in sync with what HTTP clients get and set at the /server/name endpoint.

Questions to answer

Can we change the robot's Avahi service name to something generic like "Opentrons OT-2", and supply this in a static Avahi .service file instead of making update-server supply it at runtime?

✅ Deconfliction

If we do this, will Avahi automatically handle deconfliction for us? e.g. if two robots are on the same network, will Avahi automatically make one them "Opentrons OT-2 (2)"?

[Tested by @SyntaxColoring] Yes, it will.

⚠️ Compatibility with discovery-client

Will this mess with discovery-client, since the mDNS/DNS-SD name will no longer match the HTTP name?

[Tested by @SyntaxColoring]:

Today, yes, I think it will mess with discovery-client.

Here's the output of the discovery-client CLI on my machine. In this test, I only have one robot on my network, and that robot is set up with a static service file.

It looks like discovery-client emits three separate events for that robot:

1. The initial mDNS discovery, with the robot's top-level name field set to the statically-configured Avahi name. health and serverHealth start out empty, as expected, because those endpoints haven't been hit yet over HTTP. addresses starts out with the robot's IP address.
2. The same thing, but with addresses nulled out. Unclear why this happens.
3. The robot now with its proper name, and full populated health, serverHealth, and addresses.

But nothing ever clears the initial robot, whose name is the statically-configured Avahi service name. So, when the Opentrons App starts up, it queries discovery-client and finds two robots: an unconnectable one with the statically-configured Avahi name, and a connectable one with the proper name.

❓ Would this feature removal be acceptable?

Does the Avahi service name show up in any network exploration tools that users are using? If it does, will anyone mind if the user-facing names become "Opentrons OT-2" instead of the name that the user set?

[SyntaxColoring]

One hacky way to test this:

1. mount -o remount,rw /

2. cat << EOF > /etc/avahi/services/testing.service
   <?xml version="1.0" standalone='no'?>
   <!DOCTYPE service-group SYSTEM "avahi-service.dtd">
   
   <service-group>
     <name>Static Service File Test</name>
     <service>
       <type>_http._tcp</type>
       <port>31950</port>
     </service>
   </service-group>
   EOF
   

3. mount -o remount,ro /
4. Check out hack(update-server): No-op when setting Avahi service name #10423 and do make -C update-server push.
5. Reboot the robot.

When you're done testing:

1. mount -o remount,rw /
2. rm /etc/avahi/services/testing.service
3. mount -o remount,ro /
4. Restore the update-server from edge (or whatever commit your robot was on prior to testing).

[SyntaxColoring]

Conclusion

Yes, it's theoretically possible to do this, but we prefer not to.

• As found above, doing this would mess with the discovery client as it's implemented today.
• Although doing this would make our back-end implementation simpler, it would make the "public" interface of the robot more complicated. Correctness would be more sensitive to devs knowing about and understanding the differences between more names.
• It would go against the DNS-SD spec's recommendation to make the instance name configurable. https://datatracker.ietf.org/doc/html/rfc6763#section-4.1.1