From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 13FD541CEC;
Mon, 20 Feb 2023 14:24:27 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id A68784303F;
Mon, 20 Feb 2023 14:24:26 +0100 (CET)
Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com
[209.85.208.51]) by mails.dpdk.org (Postfix) with ESMTP id A713C40395
for <dev@dpdk.org>; Mon, 20 Feb 2023 14:24:24 +0100 (CET)
Received: by mail-ed1-f51.google.com with SMTP id o12so5067787edb.9
for <dev@dpdk.org>; Mon, 20 Feb 2023 05:24:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=pantheon-tech.20210112.gappssmtp.com; s=20210112;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=jW2TVqd4f3QYC+jzeHqjvlXI9qmsZJSucfPHSm4cUMo=;
b=YlKtYZ1FgmtrMFpR4nSn29ooGFT/mn/sV9iQ9n1q5NDZHKTEgw3ipR3WCrccfkqube
K9kD+YviMdIoXuoWZuHhJdF4SbjLByaaj2jhX2a/poMJtqTErqelBcdw9pslOzjSfvYg
mWeF20wgTQQWzz7SwA/T7hpQ/RL8M4MScR5ndXty4W9U2+iT/weHmAMqvTZusC1Rana0
4UsfhMn0C4Xm9UXgGbtEdphNJSANUBgpkn+F6V2XDcmlSdQaoL6t9CMMxTx1AVioWgIo
TqFHDIp1DmeTyP/nopiDQThis5j/e1cGGrcmRXWuMSCyauWF7oaQRxSC7jIY6KkjpJlR
A+9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=jW2TVqd4f3QYC+jzeHqjvlXI9qmsZJSucfPHSm4cUMo=;
b=RSouYUL5KUUrikcW1nIadnHTxXuF23TDFLWhHAcc9J21FHxRmsZnBoTV3xuWfnHO0o
50D3CKH2H16aMgXGxvFt0o/U6HAsGP3rc95IJcwL1LFE8fmJUOzSP0FX0FKHZm3oaANq
l2rIvp5NFjVxOHolRodRPOT+5damBG3vgOyZZef+rRB4+uH1wnNfigF+mdhbKa00zQTx
QRiAzJXC+/kMW05PqWb49NnbcFTIoyZxtcVauLzHIs4FHS71cUWRGt+JQvNFJ0VbQxXz
peyE3XiZ174uzm/ofeIGiSHK+JuWQ6WsTBZ33YvWLdgmcfj2wYlkqQ/Nr/5a3/bJ6tRx
musg==
X-Gm-Message-State: AO0yUKW55qzA5diz4MRLCqg254Gtx0vUSl+eHiyOHRqwJYmaYtCZhyVg
dpGyYnvHDMS+qULmvkGeO9TMK3km1Y5wLehnvyhJD4gGldfHLg==
X-Google-Smtp-Source: AK7set96ly4wZdJ3YslMJr+Ottq1wKMBeDZ9nqPoQX4JuHz0fPs8/RwLn4SXZsNoIyaCB2FRSt3lgHMhsSi0Ry3FlPM=
X-Received: by 2002:a50:ce53:0:b0:4ab:4bad:faa4 with SMTP id
k19-20020a50ce53000000b004ab4badfaa4mr278149edj.8.1676899464149; Mon, 20 Feb
2023 05:24:24 -0800 (PST)
MIME-Version: 1.0
References: <20230117154906.860916-1-juraj.linkes@pantheon.tech>
<20230213152846.284191-1-juraj.linkes@pantheon.tech>
<20230213152846.284191-2-juraj.linkes@pantheon.tech>
<Y++8+Ebw4mDirfRg@bricha3-MOBL.ger.corp.intel.com>
In-Reply-To: <Y++8+Ebw4mDirfRg@bricha3-MOBL.ger.corp.intel.com>
From: =?UTF-8?Q?Juraj_Linke=C5=A1?= <juraj.linkes@pantheon.tech>
Date: Mon, 20 Feb 2023 14:24:12 +0100
Message-ID: <CAOb5WZZf77+KZV4jjUtytXkO74O9gS2XYE9ee2aGwkfeUEpCfw@mail.gmail.com>
Subject: Re: [PATCH v4 01/10] dts: add node and os abstractions
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: thomas@monjalon.net, Honnappa.Nagarahalli@arm.com, ohilyard@iol.unh.edu,
lijuan.tu@intel.com, wathsala.vithanage@arm.com, probb@iol.unh.edu,
dev@dpdk.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
On Fri, Feb 17, 2023 at 6:44 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Mon, Feb 13, 2023 at 04:28:37PM +0100, Juraj Linke=C5=A1 wrote:
> > The abstraction model in DTS is as follows:
> > Node, defining and implementing methods common to and the base of SUT
> > (system under test) Node and TG (traffic generator) Node.
> > Remote Session, defining and implementing methods common to any remote
> > session implementation, such as SSH Session.
> > OSSession, defining and implementing methods common to any operating
> > system/distribution, such as Linux.
> >
> > OSSession uses a derived Remote Session and Node in turn uses a derived
> > OSSession. This split delegates OS-specific and connection-specific cod=
e
> > to specialized classes designed to handle the differences.
> >
> > The base classes implement the methods or parts of methods that are
> > common to all implementations and defines abstract methods that must be
> > implemented by derived classes.
> >
> > Part of the abstractions is the DTS test execution skeleton:
> > execution setup, build setup and then test execution.
> >
> > Signed-off-by: Juraj Linke=C5=A1 <juraj.linkes@pantheon.tech>
> > ---
> > dts/conf.yaml | 11 +-
> > dts/framework/config/__init__.py | 73 +++++++-
> > dts/framework/config/conf_yaml_schema.json | 76 +++++++-
> > dts/framework/dts.py | 162 ++++++++++++++----
> > dts/framework/exception.py | 46 ++++-
> > dts/framework/logger.py | 24 +--
> > dts/framework/remote_session/__init__.py | 30 +++-
> > dts/framework/remote_session/linux_session.py | 11 ++
> > dts/framework/remote_session/os_session.py | 46 +++++
> > dts/framework/remote_session/posix_session.py | 12 ++
> > .../remote_session/remote/__init__.py | 16 ++
> > .../{ =3D> remote}/remote_session.py | 41 +++--
> > .../{ =3D> remote}/ssh_session.py | 20 +--
> > dts/framework/settings.py | 15 +-
> > dts/framework/testbed_model/__init__.py | 10 +-
> > dts/framework/testbed_model/node.py | 104 ++++++++---
> > dts/framework/testbed_model/sut_node.py | 13 ++
> > 17 files changed, 591 insertions(+), 119 deletions(-)
> > create mode 100644 dts/framework/remote_session/linux_session.py
> > create mode 100644 dts/framework/remote_session/os_session.py
> > create mode 100644 dts/framework/remote_session/posix_session.py
> > create mode 100644 dts/framework/remote_session/remote/__init__.py
> > rename dts/framework/remote_session/{ =3D> remote}/remote_session.py (=
61%)
> > rename dts/framework/remote_session/{ =3D> remote}/ssh_session.py (91%=
)
> > create mode 100644 dts/framework/testbed_model/sut_node.py
> >
> <snip>
>
> > +
> > +def _exit_dts() -> None:
> > + """
> > + Process all errors and exit with the proper exit code.
> > + """
> > + if errors and dts_logger:
> > + dts_logger.debug("Summary of errors:")
> > + for error in errors:
> > + dts_logger.debug(repr(error))
>
> This is nice to have at the end. However, what I think is a definite
> niceer-to-have here, is the actual commands which produced the errors. In=
my
> case, the summary just reports:
>
> 2023/02/17 16:59:59 - dts_runner - DEBUG - ValueError("invalid literal fo=
r int() with base 10: '\\x1b[?2004l\\r\\r\\n0'")
>
> What is really missing and I had to hunt for, was what command produced t=
he
> invalid literal. Perhaps that's the responsibility of the error message t=
o
> include the details, but either way it would be great to get!
>
Yes, it should be in the error message. It's not there because this is
a corner case in code that will be replaced shortly.
> /Bruce