hashicorp
Rename boundary.service to [email protected]
To properly utilize the worker/controller options in systemd, the unit should be named [email protected]
This will enable systemctl start [email protected] or systemctl start [email protected]
Note this would be a breaking change to the unit as systemctl enable boundary would no longer succeed.
It's not an actual rule but usually I see instanced units when an arbitrary number of the unit might be started, e.g. web application workers or tty handlers. With Boundary, although I could in theory see this working, in ordinary usage would there ever realistically be more than a worker and a controller on a host? Since the same config can specify both worker and controller configurations but they will be handled in separate threads, effectively there's no use case (that I can think of) where multiple boundary server processes ever need to be started as systemd units.
At a minimum, if we do this we should add a DefaultInstance to the unit template so that systemctl [enable|disable] boundary@ does something useful.
The same config can specify both a controller and a worker but there are real reasons you may not want to do that -- for instance, upgrading the controller while keeping sessions alive on the worker (if you're fast enough).
FWIW I know that at least Arch separates it out into separate services by default.
The same config can specify both a controller and a worker but there are real reasons you may not want to do that -- for instance, upgrading the controller while keeping sessions alive on the worker (if you're fast enough).
True, although I think in most of the cases where you want to run separate controller/worker processes you'd want to run them on entirely separate hosts (or at least in separate containers) for a lot of the same reasons you wanted the processes separated to begin with (e.g. not having database credentials potentially accessible to the worker that don't need to be), so you still wouldn't have a need for instanced units.
I'm pretty agnostic on the change itself, it's more just that I'm wondering if the benefit of changing to instanced units (which seems somewhat marginal to me in this case) outweighs the impact of breaking the existing state of things for people, acknowledging that it's still 0.x days so if the change is to be made, now's the time to make it.