Re: Option parsing: Allow the same option multiple times

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]

On Fri, Jun 16, 2023 at 11:04:00PM +0200, Stefano Brivio wrote:
> On Thu, 15 Jun 2023 14:57:37 +0200
> Paul Holzinger <pholzing@redhat.com> wrote:
> 
> > Hi all,
> > 
> > following up on a quick discussion with Stefano on IRC.
> > 
> > passt/pasta currently rejects most (not all) options when specified 
> > multiple times, i.e. pasta -I eth0 -I eth1 ... fails. I think it makes 
> > more sense to just use the last one instead.
> > 
> > My use case: In podman I added a new containers.conf option[1] which 
> > allows users to set default pasta cli options. However users can also 
> > add options on the podman cli with podman run --net=pasta:... For me it 
> > would make the most sense to just append those to the config options and 
> > then let pasta deal with it. This allows some form of overwrite 
> > mechanism, i.e. by default I may have "-I" , "eth0" in containers.conf 
> > but for one specific container I want to use a different interface name 
> > and set --net=pasta:-I,eth1 on the cli. Then podman should just hand "-I 
> > eth0 -I eth1" to pasta and then pasta picks the last one.
> > 
> > If we keep the current behavior it means I am forced to parse the 
> > options in podman and dedup them which is hard to maintain as podman 
> > would need to keep up with pasta upstream.
> 
> I had to do something similar in libpod/networking_pasta_linux.go,
> which, if you change this, could also be simplified a bit.
> 
> > I am willing to send a patch to change this so please let me know if 
> > anyone would object to that.
> 
> For the record, as I mentioned on IRC, I think it makes sense.
> 
> Maybe it's less "correct" as a behaviour, and it would make it a bit
> harder for users to spot (unlikely) mistakes on the command line, but
> making integrations simpler probably outweighs this.
> 
> I don't have a good idea for sentences like "This option can be
> specified zero (for defaults) to two times (once for IPv4, once for IPv6)."
> that are currently in the man page... maybe we could switch from
> "This option can be specified" to "This option specifies one to two..."
> and similar.

So, I'm actually a bit hesitant about applying this treatment (allow
multiple, last one wins) to -a specifically.  The reason being that we
have draft plans to allow multiple addresses within the guest/ns.
That might logically lead to allowing arbitrary numbers of -a options
in future, where *all* the addresses apply.  If we'd previously
allowed multiple options, but only the last one applies, that might be
a breaking semantic change.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]