[Swan-dev] test domain interface changes

[Andrew Cagney]

On Mon, 7 Sep 2020 at 12:09, Paul Wouters <paul at nohats.ca> wrote:
>
> On Sat, 5 Sep 2020, Andrew Cagney wrote:
>
> >> 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?
>
> No it was 192.1.9 i believe. But it was removed like two years ago along
> with the unused eth2's on most machines.

So what is, or was 192.1.4.0/24?

> > 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.
>
> The "hoop" was "fire up nic and run /testing/guestbin/nic-internet" until
> it got broken :)
>
> It was pretty simple and since every machines routes default gw through
> nic, it only requires a single custom interface on nic.

... DNS would need configuring for instance, anything else?

> > What we're talking about here is a _natted_ bridge that multiple
> > instances of obsde, say, can use to simultaneously access the host.
>
> Until now, all test cases are run in isolation. Hooking up the virtual
> networks together so in theory test cases can affect each other seems
> unwise?

I don't understand.  Each test group still uses a dedicated and
isolated network.  That hasn't changed.
The swandefault network, unless it is misconfigured, should be
isolating any attached domains - all each domain can see is the host
(we've already got nic on the swandefault network without problems?).

> > This means the VMs do not, and cannot, have pre-assigned ethernet / ip
> > addresses.  And this is what <swandefault> provides.
>
> nic's eth2 is connected to the host libvirt dhcp and you can already
> have multiple of those at once (although having "uplink" for test
> machines should really be a manual human action and not a regular
> occurance or else having internet becomes a requirement to run tests,
> which it currently is not. We even run shadow DNS for a number of
> zones to avoid needing real world internt.
>
> > 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.
>
> That would be better than being the first. Although my preference would
> still be to use nic for this and not add another network to all virtual
> machines and namespaces.

So all openbsd tests need to boot NIC and use it as a GW to route NFS
traffic.  Ewww.

> > (speaking of which, why do east and west - our most common test
> > exchange talk through the counter intuitive eth1 and not eth0?)
>
> I don't know. It goes back to the uml days. Same as why it uses
> 192.1.2. 23 and 45 and not 1 or 2 or 3.
>
> > 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
>
> I'm more concerned about keeping it managable to have kvm and namespaces
> produce the same output. Adding interfaces will just make that a little
> harder. Having something unique for just the openbsd machines seems the
> least painful now.
>
> Paul