From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=fail (p=quarantine dis=none) header.from=redhat.com Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 9B5025A0265 for ; Wed, 28 Oct 2026 08:44:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1793173462; 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=U+5dif4cTjS/QA6FCL5i2no14FtAU+Yu4aVEVhNNzSM=; b=YgJEM8tZUrYU5WZ7umYRQ7dbHQnku90BS4X833KdgHRvRjJeSrwZckdYzRkDhBnO598LDn DBXVDTUpj+1qhIEZepZup7IQmXYGk6ebMCZzdvpbjRC/Mu3AsiHYaifvo7oXTWZVASg1aG KLANz8T1FdNIkoC1WYGwUKH12panCjE= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-564-gUmaPdCXN72HY-hCXGIUEg-1; Wed, 28 Oct 2026 03:44:21 -0400 X-MC-Unique: gUmaPdCXN72HY-hCXGIUEg-1 X-Mimecast-MFC-AGG-ID: gUmaPdCXN72HY-hCXGIUEg_1793173460 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-48e1d839ddaso374866f8f.3 for ; Wed, 28 Oct 2026 00:44:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793173460; x=1793778260; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=U+5dif4cTjS/QA6FCL5i2no14FtAU+Yu4aVEVhNNzSM=; b=Grt+JX1N93JA/x0ku+71j/tSz0KaFJwoSBuIfwoPA4ASdWhJte1v2zSzxDsTO/g/Lq mBrC/633UbVnT3Y6oEaNcQJDiZmolv3rAbfBt/DiScRN8teKUdiPG5dhMWJPfr5rtJE7 r4X9NN5ohe+t1ayC+c9t7wVgFhPbv1/27TH2VM1Z8DgNYwq4VWmzLssglJOAslO27yQy uJL9p7dzklozPqbWaKYcKlgBVi4ImRWkTSgOzahoyWeDnWrbtAq0tIhLQyKTBdWRQpAb 3TQ/R8LqIVsaCI+3+Vs0Xflpa3ZdQezjuvCsMvV75V0hGgo+JJSb68i7vxWtIa4+9nEB FkVQ== X-Forwarded-Encrypted: i=1; AKwUvBxof/eyIL03y0cAyqf4cyJaDvXR+dlORWJaA0t7ulLUWoavEeaRYTfgC55x0giHeCw9tPlJFWx2i2k=@passt.top X-Gm-Message-State: AFq9FYJ5Jz0vEo+Qn19ZEu+x5RlWMSgTZG853+A9/EeDUEL8PR1oirPV 9jW0uAmpOogqJnxEX7dfNdv+xNs4Gmq7Ztieh4MwO07HmE13keU63AK1bvdUZdT6Tl+iAtBc7iI qVeMEVpjY09BFo0XGxxBIxuRJJkqp1IJeR5+Rsc1/aBIHZdDUfjaaAFbcuxklXg== X-Gm-Gg: AYBFou2UYe5y2QaOam5Ao6cm50t1NJVxsjIQCG5P7zd+c4ancCPoqgh4rd7rN1XJIdE spafou2fLGXKuYUb7UvIMISHErVIyaFVEOdr+0pevf+Y9bmr8teXnLe3rCnj39eCZ1H2x0ccMqM 57N+s4UuIQlYa5hccYlAXWL2m/3tvAs6Eljp5RYeG5GUH6OjqdPbIUot4bjuEXGHod1wIuysg4+ vtFhwiMLg9YwngXsUeVvYoEnv739H/o/h5oMsj1bFN52uC7yEJs79nDOC5yEf5jYf6zTo6RLVH5 sDQzB/A4Lq12AD57n0Hezq7APTRh3L9z8pVj0FqL7U0sqzyoI1VInKrPenHT+sDRWJbXB5s0X2o 0xOTC1JIGy71IDx4EHoRGzRpGt0FuDtl4laMQ2GUKoPgafjE9E6h3mskzuiiUiyykD0lfIN0CKv pIqpuf1y9X X-Received: by 2002:a05:6000:2dc4:b0:48d:fdd0:6ce8 with SMTP id ffacd0b85a97d-48e5d454eeemr3791007f8f.3.1793173459916; Wed, 28 Oct 2026 00:44:19 -0700 (PDT) X-Received: by 2002:a05:6000:2dc4:b0:48d:fdd0:6ce8 with SMTP id ffacd0b85a97d-48e5d454eeemr3790949f8f.3.1793173459230; Wed, 28 Oct 2026 00:44:19 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ebcb8e0sm26071200f8f.29.2026.10.28.00.44.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Oct 2026 00:44:18 -0700 (PDT) From: Stefano Brivio To: dev@haytok.jp Subject: Re: [PATCH] Keep listening on remaining rules if one of them fails to bind Message-ID: <20261028084416.01953935@elisabeth> In-Reply-To: <6A292BDB-99B3-451E-B859-FAC3D2300221@haytok.jp> References: <20261018154225.56640-1-dev@haytok.jp> <20261025153025.600a4fe9@elisabeth> <6A292BDB-99B3-451E-B859-FAC3D2300221@haytok.jp> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Wed, 28 Oct 2026 08:44:17 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: P19j8Tw4ck3AVvLWbZaISUVeoRJ3Vv3MNBMB56uxaO8_1793173460 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: AHCTGNHPMKZTCCR66VBG3AX372A5J3I6 X-Message-ID-Hash: AHCTGNHPMKZTCCR66VBG3AX372A5J3I6 X-MailFrom: sbrivio@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: David Gibson , 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 Wed, 28 Oct 2026 02:24:40 +0900 dev@haytok.jp wrote: > Hi Stefano, > > Thanks for the detailed explanation, and for the background on the > original design! > > > We're not sure whether a rollback after 2. would work: forwarding rules > > that might have worked earlier might not work now (for example because > > host addresses changed). > > > > However, in a general case, I guess that the existing (old) rules are > > still more likely to work than not. That is, given: > > > > a. new forwarding rules don't work because of an unintended > > configuration error > > > > b. old forwarding rules wouldn't work anymore if re-applied because of > > a setup change > > > > I think a. is much more likely, so a rollback would be beneficial and > > give the user the chance to look at possible configuration errors > > without switching to a possibly unintended state. What do you think? > > I strongly agree. > > In practice, a. is far more likely. Case b. can happen depending on > what changed on the host, but that's beyond what pasta can handle, so > all we can do is report it and let the user fix the setup. > > > 1. abort on any failure of fwd_listen_init() (maintaining the current > > behaviour of fwd_listen_sync_()), and: > > > > 2. close any listening sockets (first part of fwd_listen_switch()) that > > we might have just opened > > > > 3. swap the rules again (as you can see, we already preserve the old > > rules, because we planned to complete the rollback implementation at > > some point) > > > > 4. call fwd_listen_init() on the old rules > > I agree, and that's what my work-in-progress patch does. > > > 5. make sure we report failure to the client > > Here's how I'm thinking of implementing this. Please let me know if > I got something wrong: > > - make fwd_listen_switch() return an int, distinguishing the case > where we rolled back to the old rules from the case where the > rollback failed too It needs to be able to return failure, for sure. We don't _strictly_ need to distinguish the two types of failures, because if the rollback fails, there's nothing we can do, and we can ignore that failure. On the other hand, it might be nice to report it to the user via pesto, so yes, it would probably be nice to distinguish the types of failure. By the way of fwd_listen_switch(), it could simply be called a second time to implement a rollback (the old rules are preserved in c->fwd_pending), but the error messages wouldn't match anymore. I see a few possible solutions for that: error messages could be moved the caller (perhaps my favourite option at the moment), or we could pass an 'bool rollback' argument, or move most of the logic to a separate function and introduce an intermediate caller... I'm not sure. I guess it would be better to try things out and see how they look like. > - in conf_handler(), write that result to the control socket right > after fwd_listen_switch(), before conf_close() > > - in pesto, read it after send_conf(), and if the update failed, > print that the old rules were restored and exit non-zero Both steps make sense to me. > For the content, I'd start with a status only (success / rolled back / > restore failed). fwd_sync_one() already logs which rule failed on the > pasta side, so returning that to pesto could be added later if needed. Right, yes, given that we distribute client and server together, we don't have to really plan much in advance or be particularly future-proof. We can just bump versions as needed. The day somebody else starts developing other clients (for example to embed in container engines or virtual machine managers), then we'll have to think again about this, but it's not the case for the moment. > Since this adds a message from the server, we need to bump > PESTO_PROTOCOL_VERSION to 3, and have pesto skip reading the result if > the server version is below 3. Is that OK? Definitely, yes, that's how versioning was meant to be used. > I'm planning to send 5. as a separate patch from the rollback (1. to > 4.). Right, probably easier to review. > > ...this looks reasonable to me and better than the existing behaviour, > > but it's pointless to do this if we want to finish things up and add > > the rollback for this case. > > Agreed, I'll drop this patch. > > I was already planning to implement the rollback feature, and I have a > work-in-progress patch covering steps 1. to 4. you listed. I'll send > it once it's ready. That sounds like a plan. Thanks for working on this! -- Stefano