Custom Sections or Plugins Support

[alexmipego]

One of the things (afaik) lacking with fleetctl is the ability to do more than launch units in a consistent way. For example, you need to launch a unit for your web app, reconfigure your process monitor to do log checks and prepare everything to ship logs somewhere. All those steps feel "disconnected" and things like stopping a unit without reconfiguring your health checks will cause failure alerts.

What I believe would be nice is the ability to extend fleetctl/systemd units with more meta data and to be able to take actions on those with an agnostic approach. For example:

[Unit]
Description=MyApp
[Service]
ExecStart=/usr/bin/docker run myapp
[X-Logs]
LogFile=/var/log/myapp.log
LogPattern=/var/log/myapp/*.log
[X-Health-Check]
Run=docker exec myapp /healthcheck.sh
Run=docker exec myapp /healthcheck2.sh
Frequency=1m

The X-Logs and X-Health-Check sections although not understood by systemd or fleetctl could trigger plugins/processes on hosts that registered and processed that meta-data. For example, on running myapp the host that runs the unit could also launch fleetctl-logs@myapp.service that would parse or receive and process that meta data.

All this seems almost possible but there is no way of getting the unit's meta-data out the service files...

[wuqixuan]

@alexmipego, Seems like you want a feature of dependency. Currently, fleet support "MachineOf" fleet-specific Options. It means it depend on another unit. Is this the feature what you want ? @mischief , what do you think ?

[alexmipego]

Not exactly, the purpose would be to be to define properties that configure other abstract units. For example, to use something like monit or nagios you would need to configure them with something like a health check script or ping url, right now this means reconfiguring them manually. With this, a generic solution could be in place that would handle any implementation-specific details.

Another way of thinking about this would be that you provide fleetctl as a service for your company but you dont want people messing around with "utility" services like monitors or log shippers directly.

As I said, with more or less effort this should be possible with systemd dependencies, machineOf, etc... however, you still need to create a specific unit that knows the details of your new unit before the "abstract" units can be useful (e.g. the log paths).