On Fri, Jun 16, 2023 at 11:04:00PM +0200, Stefano Brivio wrote: > On Thu, 15 Jun 2023 14:57:37 +0200 > Paul Holzinger 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