In setups like this...
CPU
eth0
|
.----0----.
| dst0sw0 |
'-1-2-3-4-'
|
.----0----.
| dst1sw0 |
'-1-2-3-4-'
...both eth0 and dst0sw0p4 are DSA ports. But the latter is _also_ a
physical port as far as devlink is concerned. As a result, it would
first be marked as "internal" and is then instantly reclassified as a
"port".
Catch this condition and stick with the initial "internal"
classification.
In addition to matching on interface names, add support for matching
on ethtool information.
Example:
{
"@ethtool:driver=st_gmac": {
"broken-mqprio": true
}
}
This would mark any interface using the "st_gmac" driver as having a
broken mqprio implementation. Whereas this:
{
"@ethtool:driver=st_gmac;bus-info:30bf0000.ethernet": {
"broken-mqprio": true
}
}
Only matches an st_gmac-backed interface at the specified location.
As matching becomes more complicated, use the shell implementation
from confd as well, to make sure that they are always in agreement.
The defconfigs for all architectures other than x86_64 has this
enabled, so align it with the rest.
This has no on-target impact, but it enables us to attach to a live VM
instance and debug it, or do offline debugging like resolving stack
trace lines from oops messages to source locations.
Some netdev drivers, e.g. the FEC found on many i.MX SoCs from NXP,
will detach from their PHYs when configured down.
This means that when confd tries to configure L1 settings for the link
before bringing it up, ethtool fails - since there is no PHY to talk
to.
For interfaces that behave this way, delay the configuration until
after NETDAG_INIT, when the interface is brought up. This is not
optimal, since we are generating needless noise for the link partner,
which is why we only fall back to it as a last resort.
Fix#951
Ideally, all drivers should behave the same. Alas, that is not the
world we live in. For quirks that we can not reliably probe for in any
other way, let products supply a JSON file that declares them.
CID 507415 from coverity was the origin for this change. As it turns
out, the unreachable MAC address generation for VXLANs was hidden by
the generic setup (netdag_gen_link_addr()) saving the day. That is
likely something we want to phase out though, so the VXLAN code should
stand on its own.
Align the GRE code while we're here, because why not? :)
Do not allow the topology matcher to setup a LAG where one link is
running at 10G while the other one runs at 1G, since the bond will
never use the 1G port as long as there the 10G link is up.
To run LAG tests on hardware, we have to make sure that the chosen
links are running at the same speed. We do not want to require a
specific link speed from the logical topology, as the real requirement
is merely that the two (or however many) links are of the _same_
speed, not any _particular_ speed.
Rather than having to complicate the topology matcher, let it take
care of the common pattern of matching requirements to provided
features, then let tests pass custom node/edge matchers for the
complicated cases.
The management of custom-phys-address was made more complicated by the
fact that physical interfaces require restoring the permanent address
when a custom setting is removed.
Simplify this by moving the restoration to the delete path, so we only
have to worry about if there is a custom mac or not during interface
setup.
Also:
- Fix some legacy naming on *_gen() functions
- Fix custom-phys-address on dummy interfaces
Fix#938
Before this change, interface dependencies were only setup when
interfaces were created. This led to problems in flows like this:
1.
configure
set interface br0
set interface br0.10
leave
2.
configure
set interface dummy0
leave
2.
configure
no interface br0
no interface br0.10
leave
Since neither br0 nor br0.10 was created in (2), no dependencies were
setup. Because of that, when the deletion scripts from generation (2)
are generated when entering (3), dagger is free to execute them in any
order. This means that it may choose to remove br0 before br0.10,
which will mean that br0.10 is already gone when we try to remove it.
Therefore, make sure that we generate the full dependency graph on
every iteration.
Also, get rid of the need to keep on-disk state for VETH pairs, and
use the name as a descriminator for which side to create/delete.
With the new iftype enum, we see that configuring an existing dummy or
gre interface types was wrongly classified as an error rather than as
a NOP.
Example, before this change, this was OK:
configure
set interface foo
set interface foo ipv4 address 10.0.0.1 prefix-length 24
leave
However, this was not:
configure
set interface foo
+leave
+configure
set interface foo ipv4 address 10.0.0.1 prefix-length 24
leave
+<KABOOM>
This has multiple advantages:
- Less chances of typos is repeated "infix-if-type:foo" strings
scattered throughout the code
- We can lean on GCC's `-Werror=switch` to make sure that iface
specific logic always handles all types (which was not always the
case - see follow-up commits)
- We can potentially create a `struct afspec_ops` in the future, which
could then be indexed by this enum
The only interfaces that would be in difs, but not in cifs, are
deleted interfaces. But these will be removed from the exit action of
the previous generation, and will never be referenced in the new
generation.
By declaring the service as manually configured, we can control it
from dagger (confd) without the indirection via a condition.
This has the benefit of mstpd being in the "stopped", rather than the
somewhat confusing "waiting", state when not running.
Fixes#890
On slow systems, we don't want test steps involving tools like scp or
ssh-keyscan to fail because the server had not come up yet.
Therefore, make sure that the server is ready to accept connections
before moving on to subsequent test steps.
Use CAPTIALIZED names for static data and collect them at the top.
Make a note about for future readers about why a test called
ssh_key_authentication suspiciously does not enable the SSH service :)
Being able to check for a TCP based service is generally useful, not
only for NETCONF. Therefore, break it out to a separate function that
allows any port to be queried.
Due to #902 (which has not been root caused at this time), podman may
indicate the existance of an interface that yanger is not able to
locate in any namespace. Therefore, make sure that we verify that the
interface was actually found before trying to create the operational
data for it.
Break up the --test parameter into either:
--capture: Write system command output to a local directory for later
consumption by...
--replay: Which can replay a previous capture
Rename --wrap-commands => --cmd-prefix
Existing tests relied on manually captured system data from various
points in Infix's history, making them hard to extend as we add new
features.
Move to a new model where we:
To update a unit test:
1. Use Infamy tests to setup a DUT in a known state
2. Use yanger's wrapper mode to capture the system state needed to
produce operational data for a set of YANG models
3. Use cli-pretty to create the expected output for a set of show
commands
When running unit tests, we can then use the captured data to verify
that yanger and cli-pretty works as expected without the need for a
running Infix system - just like before. The difference is that it is
now much easier to capture a new snapshot when the system evolves.
Ensure that all flavors of GRE tunnels can be configured. In addition
to the increased test coverage, it will also be useful as a basis for
collecting representative system state for CLI testing.
Ensure that VLANs can be configured on VLAN filtering bridges. In
addition to the increased test coverage, it will also be useful as a
basis for collecting representative system state for CLI testing.
Allow all host commands to be run with a prefix (e.g. `ssh
user@remotehost sudo`), such that yanger can be tested against the
current state of a remote system.
If a command wrapper _and_ a test directory is specified, the output
of all commands and files are recorded for use by a future test
execution.
Example:
1. Launch a `make run` instance and setup some config for which we
want to test yanger and cli-pretty
2. Capture the output of all commands needed to produce the data for
some YANG model:
`yanger -t /tmp/ifs -w "ixll -A ssh qtap1 sudo" ietf-interfaces`
3. Kill the instance (we do not need it any more)
4. Test cli-pretty using the captured state:
`yanger -t /tmp/ifs ietf-interfaces | cli-pretty show-interfaces
`
The default was set to only accept connections from localhost when
connecting via IPv6. This was not caught in testing since the
test-config accepts connections from all hosts (::).
Accept connections from all hosts in all builtin configs. Inherit
test-config's service definition from factory-config, since we want
testing to be done as close as possible to what are users are running.
The default ping(8) shipped with alpine does not support `ping <addr>
-c1`, but happily executes `ping -c1 <addr>`. Therefore, make sure
that the address is always the last argument.
Usage examples:
Run yanglint on all infix models:
ixyang check
Lint a single model:
ixyang lint infix-interfaces
Dump a tree of ietf-interfaces with all infix augments:
ixyang lint infix-interfaces ietf-interfaces -- -f tree
The yanger source grown significantly, code is disorganized, the
namespace is all over the place, etc.
Take a stab at remedying the situation by splitting out the individual
YANG models in separate Python modules, starting with ietf-system.
Rather than explicitly defining the sources, specify the package names
and let poetry figure out the details. Otherwise, subpackages are not
included, which we want to start using in yanger.
When interactively running, for exampe, yanger interactively from the
source tree, we end up with compiled files in our working tree. Make
sure to ignore these.
