From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Mon, 20 Feb 2023 14:24:24 +0100 (CET) Received: by mail-ed1-f51.google.com with SMTP id o12so5067787edb.9 for ; 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> In-Reply-To: From: =?UTF-8?Q?Juraj_Linke=C5=A1?= Date: Mon, 20 Feb 2023 14:24:12 +0100 Message-ID: Subject: Re: [PATCH v4 01/10] dts: add node and os abstractions To: Bruce Richardson 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Feb 17, 2023 at 6:44 PM Bruce Richardson 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 > > --- > > 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 > > > > > > + > > +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