INFIX_OEM_PATH is `""` by default (i.e., not empty in `make`'s
eyes). So we called `git` with `-C ""`, which it interpreted as "from
the current directory" and thus we sourced the autogenerated build id
from _buildroot_ instead of Infix.
Therefore, make sure to strip any quotes from the OEM path before
determining the top directory.
* Use new cleanup in infamy to ensure the boot order gets restored
* Use new boot order in operational and use RPC to set boot order
to remove all SSH commands.
If a test need to clean up itself disregarding test status,
it can add an optional test-cleanup phase.
This is useful if the test in some circomstances leave the device in a
bad state. This can be used to restore the unit to its ordinary state.
Furl answers the question "is this URL serving the content I expect?"
Sometimes, we might be asking a server that in the middle of being
reconfigured, is crashing, is buggy, etc. - in which case it might RST
the connection. In that case the answer to the question is "False" and
not "BURN IT ALL DOWN!!"
The only reliable way of getting logs from the container at all times
is to let conmon be the logging agent.
Unfortunately, the k8s-file format does not handle multiline output
very well, which is something we often see on the stdout/stderr of
containers.
Therefore, add proper syslog support to conmon instead, and make sure
that podman knows enough about it to pass the information along to
conmon.
Instead of running initctl reload, which also prematurely enables
services which are not supposed to be started until we have run
through the netdag and evolved to the next generation.
Handle the original use-case of disabling zeroconf is managed by
asking finit to stop the service immediately in the exit action, and
deferring the cleanup of the service until we call `initctl reload`
after the init action of the new generation.
In ye olde confd, we basically had `50-init.ip` - and that was fine.
Then came containers, VLANs, bridges, etc.; and with it: a whole
forest of setup/teardown scripts - and it was not fine anymore.
For example: if found an init script running at 61, you would have to
grep the source tree and look at _all_ other call sites to get a sense
of what runs before and/or after it.
Therefore: create enums for the init/exit actions where the order is
explicitly stated, and use those for all interface scripts.
Clean up bridge-port config generation to align with the bridge upper
code.
- Remove lots of unnecessary guards that we model guaratees are always
met (existance of containers and leafs). This reduces indentation
depth and increases readability, IMHO.
- Split the generation into smaller pieces, each with a clear purpose.
- Try to include all edge cases around the tricky subject of PVID
migrations, with the actions running in either exit or init, as
appropriate.
TL;DR:
> New code, all bugs removed ;)
Incremental reconfiguration of bridge related settings had lots of
ordering issues.
This change tries to remedy that by:
- Introducing the concept of "snippets": Instead of having to run C
code in the correct order (which is doomed to fail since teardowns
typically need to run in reverse), collect related settings in a
snippet. Later on, we can then concatenate snippets into a larger
file in the proper order.
- Refactoring the bridge setup to take advantage of snippets. Now we
can call out to functions that _both_ generate the VLAN config _and_
sets some bridge global options, for example. This gets us out of
having to pass back settings to the main generation function.
- Ensuring that deleted objects are always removed - in the proper
order - in the exit action of the previous generation. This was
previously not true for VLANs, fix#869.
- Generating `mcd`:s config orthogonally from the bridge setup. Since
we need to keep track of _all_ bridges, figure out when VLAN uppers
exist etc., it becomes _very_ messy to generate the configuration
from the diff of a single interface. There were lots of cases here
where disabling the querier service on one bridge would disable the
whole daemon, thereby disabling the service for other bridges that
still had it enabled.
Fact: ietf-interface.c has become too unwieldy.
Therefore, split it, roughly based on the YANG structure, into
multiple files.
There is much more to do here, like cleaning up the naming (which is
all over the place), moving more system commands into dagger, etc. But
I wanted to keep this change to a strict code reshuffle.
Previously, the generation number was only increased for successful
evolutions. This led to a confusing state in /run/net where multiple
<N>-ABANDONED-<date> directories could exist, with the same value of
N.
Move to a scheme where the generation increments every time we evolve,
even if the evolution fails. If multiple consecutive evolutions fail,
we can now unabiguously determine the order in which they were
executed.
When reconfiguring the system many times (seen during regression
testing), the RAM usage of keeping all generations around starts to
add up.
A tmpfs file, no matter how small, will always consume at least one
full page (4k). So one generation of tiny setup scripts and log files
can end up locking a 1 MB (!) of memory.
Therefore: Once we're done with a generation, archive it in a
compressed tarball, which typically fits inside a single 4k
page. Limit the total number of archives to 10. This should give full
visibility into the history of a system in all normal situations,
while still allowing hammering systems with reconfig cycles in testing
scenarios.
Mattias Walström