Re: yaml gen NL families support in iproute2?

[Jakub Kicinski <kuba@kernel.org>]

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.