concept: frozen coordinator

[AiyionPrime]

I'd like to introduce a new operating mode to the coordinator, that effectively freezes the configuration.

The goal would be an immutable configuration of places guaranteed to match the representation in a vcs.

In this mode updates to places would only be possible by editing the places file.

Dynamic update attempts of places by clients would ideally provide a warning, but not change the coordinator.

Any ideas or objections up to this point?

[jluebbe]

Loading from the places file would need a coordinator restart, which is pretty disruptive. Is that acceptable in your case?

Do you see a way to support this so that it could be evolved into a user permission check in the future?

[AiyionPrime]

A restart would be fine in my case, maybe doing that gracefully would be a good idea to be less dsruptive:

Upon a TERM signal the coordinator would not accept new connections and only completes existing ones?

---

Generally speaking, I avoid implementing permission checks, when possible, but see that would be an alternative approach to ensure no fiddling with a present places configuration.

I'm coming from a declarative standpoint though; infrastructure as code is something I've learned to value deeply.
The two concepts are not conflicting though, right?

[AiyionPrime]

Sidenote, looking at the coordinator code; I really appreciate the gRPC design :)

[AiyionPrime]

Looking at it, there's more code to inform clients about changes, than I expected.
@jluebbe Do you think a reload signal handler could be less invasive?

• load the two configurations
• diff them
• and apply differences with existing methods so that clients are informed like they are now?

[jluebbe]

Note that clients can have long-running connections to the coordinator, so rejecting new connections while waiting for existing test-runs to complete might be more disruptive than a restart.

Loading and diffing would be problematic for anyone still allowing changes from the client (so basically everyone right now).

Did you see https://github.com/labgrid-project/labgrid/blob/master/contrib/sync-places.py? If you could restrict changes via the gRPC API to the sync-places script only, then you could avoid the restart and reuse the current notifications to connected clients.

[AiyionPrime]

Note that clients can have long-running connections to the coordinator, so rejecting new connections while waiting for existing test-runs to complete might be more disruptive than a restart.

Indeed. I underestimated the fact due to our relatively small setup.
But with more participants the idea looks worse.

Loading and diffing would be problematic for anyone still allowing changes from the client (so basically everyone right now).

Well that would be something the frozen variant would take care of.
In that mode the server would not place modifications.

Did you see [syncplaces.py]?

This looks great, thanks for the hint :)
It's pretty close to the diff approach I was thinking about.

Maybe I can get away with binding the coordinator to localhost, let the sync script be a reload action for the service and have something like a gRPC reverseproxy which only replicates a subset of the verbs/calls on ::0

[AiyionPrime]

@jluebbe offtopic: Are you attending the GPN this year?

[AiyionPrime]

Do you see a way to support this so that it could be evolved into a user permission check in the future?

@jluebbe I tried to take all suggestions into account and drafted a candidate:

#1888