[Swan-dev] test domain interface changes

[Andrew Cagney]

There are two, related proposals.  Lets go through each carefully.

First there's <swandefault>:

On Sat, 5 Sep 2020 at 19:47, Paul Wouters <paul at nohats.ca> wrote:
>
> On Fri, 4 Sep 2020, Andrew Cagney wrote:
>
> >>>  this makes getting to the real domain and host much exier (OpenBSD
> >>> is already using swandefault when NFS mounting /testing)
> >>
> >> But then eth0 is never used in tests ?
> >
> > OpenBSD is using its dedicated <swandefault> interface to directly NFS
> > mount /testing.  It doesn't need nic.  We think it will work when
> > there are multiple instances of obsde et.al.
> >
> > I don't see why we shouldn't make this pervasive, and use <interface>0
> > so it is memorable.
>
> We removed the extra unused interfaces a few years ago that were in
> 192.1.9.0/24. Those were eth2 and could be used but never were. Except
> on nic where it can hook up to the real internet.

(Hm, what's 192.1.9.0/24?  Perhaps you ment 192.1.4.0/24 which seems unused?

Based on the XML, OpenBSD's west has:
    0: 192_1_2
    1: 192_0_1
    2: swandefault
while linux's west has:
    0: 192_0_1
    1: 192_1_2
If we really are going to shoot for the holy grail where generic tests
work with arbitrary OSs on east/west then I think well be better off
having linux and bsd sharing a single machine definition.  If nothing
else it would fix what looks like a bug in the above, but would mean
<swandefault> is present on linux systems.

This leads to the second reason for adding <swandefault>.  Currently,
for east et.al. to get access to the real world it needs to go through
hoops.  NIC needs to be up and re-configured; east's routing tables
need to be fixed, ... All secret sauce that no one can quite remember
how to get working.  Having direct access to <swandefault> NAT should
simplify all that.

> >> But we want east and west with eth0 in the same network and with eth1 not on the same network ?
> >
> > So don't enable the network.  It's one thing to have the network
> > wired, another to have it enabled.
>
> I don't see the gain of breaking 700 test cases and their output just
> for using a different interface in openbsd. Just let openbsd use a
> new named interface ?

What we're talking about here is a _natted_ bridge that multiple
instances of obsde, say, can use to simultaneously access the host.
This means the VMs do not, and cannot, have pre-assigned ethernet / ip
addresses.  And this is what <swandefault> provides.

> > east 192_0_2 192_1_2
> > nic 192_1_2 192_1_3 swandefault
> > north 192_0_3 192_1_3
> > openbsde 192_1_2 192_0_2 swandefault
> > openbsdw 192_1_2 192_0_1 swandefault
> > road 192_1_3
> > west 192_0_1 192_1_2

(this is the first time I've been able to reliably see how the
interfaces are laid out)

> > we could at least have east, west, and nic use the same interface for
> > 192_1_2, for instance:
> > 0: swandefault
> > 1: 192_1_2
> > 2: the other interface
> > 3: and more random interfaces
>
> But almost no test would use eth0. I'd rather stick to eth0 for machines
> with "one real" interface, like road and north, and eth0 and eth1 for
> west and east that have to have "two real" interfaces.

Now we get to renumbering/renaming.  If you really think eth0 should
be a real interface, then <swandefault> can go last - knowing the last
interface is always the NAT is almost as easy as knowing it is the
first.
(speaking of which, why do east and west - our most common test
exchange talk through the counter intuitive eth1 and not eth0?)

Two things to keep in mind:

- shuffling interfaces is incremental
one domain at a time (and personally I don't tend to push changes
affecting all test output without updating the output first)
- updating is transparent:
   gmake kvm-clean kvm-install kvm-test
rebuilds all the test VMs and their interfaces already