From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefano Brivio <sbrivio@redhat.com>
To: passt-dev@passt.top
Subject: Re: passt & mbuto
Date: Tue, 14 Jun 2022 03:33:13 +0200
Message-ID: <20220614033313.5a8c6600@elisabeth>
In-Reply-To: <YqK/lPx3m1PSOXny@yekko>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5698305031821089386=="

--===============5698305031821089386==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Fri, 10 Jun 2022 13:50:44 +1000
David Gibson <david(a)gibson.dropbear.id.au> wrote:

> Hi again,
> 
> I realized I wasn't quite right when I said that qrap problems where
> what was currently stopping me running the passt (not pasta) tests.  I
> did hit qrap issues somewhere, but the current stumbling block is that
> mbuto looks for udhcpc to put into the guest image, which I can't
> easily put onto my host system.
> 
> Now, in the short term, once my patch to remove usage of udhcpc from
> the passt/pasta tests is applied, we could just remove udhcpc from the
> mbuto profile as well.  However, that raises a wider scope issue:
> 
> The passt testing profile for mbuto appliances is in the mbuto tree,
> not the passt tree.  That doesn't realy make sense, since it means any
> change to what we need for the passt tests requires a synchronized
> change with mbuto.  Particularly for a pretty young and project like
> passt, that's not really tenable.  Plus, slurping an external tool
> from some random URL in the tests is just kinda ugly.

Hmm, yes, in my ideal world mbuto would be already widely distributed
and we could drop the git clone. On the other hand, that's still one
long-term goal of mine, so:

> I'm not immediately sure how best to to address this:
> 
>  * We could make mbuto take the profiles as some sort of external
>    file, so they can be provided by the user, rather than built into
>    the mbuto repository.

...I would prefer this option. Even though if you look at mbuto's git
history, the last change to the passt profile was in September last
year, so quantitatively speaking this might be more of a theoretical
problem.

Actually, mbuto already allows overriding every part of a profile with
environmental variables (this would be PROGS), but the resulting
command line wouldn't be that nice, especially for demos.

I could implement an option there which sources a shell script file
with assignments, instead. Would that make sense?

>  * We could just fork a copy of mbuto into the passt tree, making
>    local modifications for the profile, and only manually updating it
>    to match upstream mbuto changes.

Oh, you mean "vendoring"... :) this looks rather messy to me.

>  * We could use an entirely different and more established tool for
>    building our testing guest images in passt (e.g. supermin,
>    buildroot or just picking a standard distro guest image)

supermin needs packages though: it only supports Debian and Fedora at
the moment, and we would also have an issue with neper's tcp_{,c}rr and
udp_rr.

Buildroot would be somewhat slow in demos, same for a "standard" distro
image (which we would need to update and tweak before starting it, too).

-- 
Stefano


--===============5698305031821089386==--