Message-ID: <46b77837-2f87-44aa-a6f2-e61919591659@redhat.com>
Date: Tue, 29 Oct 2024 10:29:15 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
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 10/28/24 21:58, Jakub Kicinski wrote:
> 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?

My guestimate is that the majority of the end users would prefer a
single tool (or at least a consistent 'look & feel') and they are
already accustomed to iproute and it's command line.

>>>> 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

Thanks for the hints.

I think that packaging the ynl tool is an orthogonal activity WRT the
goal/discussion here.

> 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.

My understanding is that a similar/consistent command line and man page
based documentation will preferable for the end-user - say to configure
ip addresses and configure tx shaping on a given device.

i.e. libynl would be a good starting point, but IMHO ideally it should
include a few bells and whistles alike ifindex <> interface name
conversion, explicit 'required arguments' list, etc...

Cheers,

Paolo

Powered by blists - more mailing lists