ip tuntap show lists all tuntap devices and ignores the rest of the
arguments, annoyingly. It will always return with exit code 0.
We do not detect if the interface is a bridge.
* Use systemd socket activation
* Pass a new command line argument --systemd-socket-activation to the daemons if running on Linux
* Install .socket files
* Systemd services depend on their sockets
* Implement sd_listen_fds in OCaml
* Set FD_CLOEXEC in sd_listen_fds
* README: add comment about socket paths
* Linux systemd scripts: Rename albatross_stat -> albatross_stats
The info subcommands for {unikernel,block,policy} never error
Before, running the commands block, info or policy when no block
devices, unikernels or policies respectively were set up the command
would report an error and give the user a dangerous-looking WARNING
saying the command failed:
$ albatross-client-local block
albatross-client-local: [WARNING] host [vm: ]: command failed block: not found
Now instead the commands will report success with a message stating
there are no objects.
Co-authored-by: Hannes Mehnert <hannes@mehnert.org>
regression introduced in dfd22be62b
(which prepared dumping to a file, and restart-on-failure)
this is not desired from a bandwidth point of view, if it is
considered to be a useful feature, there should be a separate
command for it
it used to only contain service, and used the same string for the bridge. This
is not flexible enough to run off-the-shelf unikernels (configured for bridge
"service" and "management" on multi-homed servers). The old behaviour is the
new default (i.e. "--net=service" creates and attaches a tap device to bridge
"service", and passes "--net:service=tapYY" to the solo5 tender). But it is more
flexible now: "--net=service:other-bridge" will create a tap device attached to
"other-bridge" and pass "--net:service=tapYY" to the tender. This way, there's
no need to match bridge names on the actual server with network device names of
the unikernels.
NB: this is (mostly) backwards-compatible: the on-disk data structures are
versioned (and the version is bumped with this PR), an old albatross client can
send "create" commands to a new server. But a new client will get a parse error
from an old server - which is fine taking into consideration the deployment
base.
checks (platform-dependent) all required executables
Vmm_unix.prepare/exec execute solo5-{spt/hvt} depending on the image type
(solo5-elftool figures that out), use jsonm to parse output
Vmm_unix: use ip on linux, no longer ifconfig
Reynir Björnsson
