From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 3CCB65A0262 for ; Tue, 20 Jun 2023 16:51:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687272714; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pHpyBNED39QnMiRykFPhBIFQFmF/CuJXSiAZzw59hCM=; b=DtxmfNUVEAKOZADqKZgA3xg26evJZSYjxyZ0vmp94HEHsoMMVlJTbumTvlqPMEccrXKiLm 5vxXF3zHmCRTewmDnfpGCEkpaHWoYHapfmJvVI7/VLmvjdj2skmOA8KIMi9JS84orfZxOY dUS0grOA6aQFfykfwbxPMScnfvdkwQc= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-614-i6wDbtZRNjSy9IAmFr5mgw-1; Tue, 20 Jun 2023 10:51:07 -0400 X-MC-Unique: i6wDbtZRNjSy9IAmFr5mgw-1 Received: by mail-lf1-f71.google.com with SMTP id 2adb3069b0e04-4ecb00906d0so1700824e87.1 for ; Tue, 20 Jun 2023 07:50:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687272651; x=1689864651; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pHpyBNED39QnMiRykFPhBIFQFmF/CuJXSiAZzw59hCM=; b=A6izE6xjg+BalOzKmSJj/fV0nDgK/H4zSJtX46kZMO1xhSMcZEcX6ufjefa0b2ONx5 DRDRHk+qF4GfjHpqfKba0Ygpzk3FK4FHpXFQGjOgSbWGwOYedG7yyV3WIMiCMGDwmkt+ bMrWCm0wiirWvkDFiOGOocde6u25TV4ytMPGXO4KxhAyhRuQh8kFwiVXNDh9PyViUlTm iBjux+/jBBfsaGOyKjdunOvkQ0APfmxNbUtcCj/dl6fC18kr2U0zCaApY6kfe2GM1NEu VRwyrGyuQ+CmSVbVuG1jpX2GZ7j8/r159+40TeFnrYT04A2tPF9Kr4q8Y/4So5TDdtoS 8EwA== X-Gm-Message-State: AC+VfDyj+I+h4RWKcgZyz7Ew2RV1hTN/8u1fzXQNmg9gLyCTGRmrgrtr vwYzZsQFhVjgvWC7arSQHEAq/8G5HS/27P8nT+gtxD9mz5upeKy9GwPaVvxOZCNM+Sw9t/+8tpG ObzxzN83jP0iO X-Received: by 2002:a05:6512:b0e:b0:4e0:a426:6ddc with SMTP id w14-20020a0565120b0e00b004e0a4266ddcmr8047279lfu.0.1687272651295; Tue, 20 Jun 2023 07:50:51 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6zAZ/DGdHEx9pQYLAjUyA5Rel+NJwDV644GbDWHceHvAT+/X7rBA2wK0nDkFdZhRbQmnoaZA== X-Received: by 2002:a05:6512:b0e:b0:4e0:a426:6ddc with SMTP id w14-20020a0565120b0e00b004e0a4266ddcmr8047266lfu.0.1687272650879; Tue, 20 Jun 2023 07:50:50 -0700 (PDT) Received: from [192.168.188.25] ([80.243.52.133]) by smtp.gmail.com with ESMTPSA id m12-20020a7bcb8c000000b003f7ea771b5dsm2575342wmi.1.2023.06.20.07.50.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jun 2023 07:50:50 -0700 (PDT) Message-ID: <4e558e41-f3f9-9037-b940-49a030a561b4@redhat.com> Date: Tue, 20 Jun 2023 16:50:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.1 Subject: Re: Option parsing: Allow the same option multiple times To: Stefano Brivio , David Gibson References: <895dae7d-3e61-4ef7-829a-87966ab0bb3a@redhat.com> <20230616154306.1071c4a3@elisabeth> <20230619081631.48df2a43@elisabeth> From: Paul Holzinger In-Reply-To: <20230619081631.48df2a43@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: EL74CF6PLCONYEIIFYBTRABT5O35444K X-Message-ID-Hash: EL74CF6PLCONYEIIFYBTRABT5O35444K X-MailFrom: pholzing@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 19/06/2023 08:18, Stefano Brivio wrote: > On Mon, 19 Jun 2023 14:49:42 +1000 > David Gibson wrote: > >> 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. > Uh oh, right... and it might also apply to -g / --gateway eventually. > > On the other hand: are two semantic changes (both of which not breaking > any reasonable or expected previous usage) in a relatively short period > of time so much worse than one (we plan to change -a handling anyway)? > > I guess handling -a differently in Podman's options would still be > additional effort for Paul. In my opinion, as long as we keep man pages > updated, we should still prioritise making our lives (and the code!) > easier. > If you plan to make changes like that I agree that supporting it might result in possible breaking changes for some users. However I like to point out that the current behavior is inconsistent and only works for some options which is the reason I thought this would work in the first place, namely it works fine with `--ns-mac-addr` right now. Another option for Podman would be to discard the options from the conf file when cli options are set so it is either or. Easy to do but I think it is not so great for users as this means a user would need to type all options again if they just want to change a single one.