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>
* Update README: Names of binaries have changed, CLI interface as well,
add instructions for installing tenders...
* Install an empty log
* Add assertion in albatross_log.service that the log file exists
this makes it much easier to reason about the initialization.
for production, init scripts should enforce the dependency order
for testing, provide your own if desired
//cc MagnusS
also move enable_stats and retry_connections up (before exit codes)
* Make albatrossd wait for other sockets to appear if --retry-connections is specified
* Connect to log/console before creating main socket
* Disable stats by default unless --enable stats is specified
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
- console creates the run directories (albatross albatross/fifo albatross/util)
-> log depends on console
- albatross/fifo needs special permission (albatross_daemon creates fifo there, albatross_console needs to read them)
- use /var/lib/albatross/albatross.log for the log file
- only require root in albatross_daemon, use user albatross in albatross_console and albatross_log
- defer albatross_stat for now
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.
Reynir Björnsson
