[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241028135852.2f224820@kernel.org>
Date: Mon, 28 Oct 2024 13:58:52 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Joe Damato <jdamato@...tly.com>, David Ahern <dsahern@...nel.org>,
Stephen Hemminger <stephen@...workplumber.org>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>
Subject: Re: yaml gen NL families support in iproute2?
On Tue, 22 Oct 2024 09:55:08 +0200 Paolo Abeni wrote:
> On 10/21/24 22:58, Joe Damato wrote:
> > On Thu, Oct 17, 2024 at 12:36:47PM -0600, David Ahern wrote:
> >> On 10/17/24 11:41 AM, Paolo Abeni wrote:
> >>> Hi all,
> >>>
> >>> please allow me to [re?]start this conversation.
> >>>
> >>> I think it would be very useful to bring yaml gennl families support in
> >>> iproute2, so that end-users/admins could consolidated
> >>> administration/setup in a single tool - as opposed to current status
> >>> where something is only doable with iproute2 and something with the
> >>> yml-cli tool bundled in the kernel sources.
> >>>
> >>> Code wise it could be implemented extending a bit the auto-generated
> >>> code generation to provide even text/argument to NL parsing, so that the
> >>> iproute-specific glue (and maintenance effort) could be minimal.
> >>>
> >>> WDYT?
Why integrate with legacy tooling? To avoid the Python dependency?
I was hoping for iproute2 integration a couple of years ago, but
David Ahern convinced me that it's not necessary. Apparently he
changed his mind now, but I remain convinced that packaging
YNL CLI is less effort and will ensure complete coverage with
no manual steps.
> >> I would like to see the yaml files integrated into iproute2, but I have
> >> not had time to look into doing it.
> >
> > I agree with David, but likewise have not had time to look into it.
> >
> > It would be nice to use one tool instead of a combination of
> > multiple tools, if that were at all possible.
>
> FTR I'm investigating the idea of using a tool similar to ynl-gen-rst.py
> and ynl-gen-c.py to generate the man page and the command line parsing
> code to build the NL request and glue libynl.a with an iproute2 like
> interface.
>
> Currently I'm stuck at my inferior python skills and -ENOTIME, but
> perhaps someone else is interested/willing to step in...
How do your Python skills compare to your RPM skills?
The main change we need in YNL CLI is to "search" the specs in
a "well known location" so that user can specify:
ynl --family netdev ...
or even:
ynl-netdev ...
instead of:
ynl --spec /usr/bla/bla/netdev.yaml
And make ynl in "distro mode" default to --no-schema and
--process-unknown
That's assuming that by
so that end-users/admins could consolidated administration/setup
in a single tool
you mean that you are aiming to create a single tool capable of
handling arbitrary specs. If you want to make the output
and input more "pretty" than just attrs in / attrs out -- then
indeed building on top of libynl.a makes sense.
Powered by blists - more mailing lists