From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=SGXy3mXC; dkim-atps=neutral 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 6AE405A0778 for ; Fri, 16 Jan 2026 04:24:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768533852; 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=CA+JHo1hSbCufZ7/QR/EmmXQGM9RYHp0LpNFVEOQn+w=; b=SGXy3mXCdIhdaQXjZPkcYUWcLvX6fI2K77NK80ZDx1A8buN9TTaE9hsuQsCN+TigOA5usQ WMF9jYJs6GR9HhdzftxmZlkzgcDG9V8Glk9+KNkvzINcgo6wyPxn0B9oqZdOp7iXJcYE7y SZbi4EyFI+TJxlUDsfvYWd3hCINQdWw= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-160-yrXW2YBfPRWD2Zv-m8XN7g-1; Thu, 15 Jan 2026 22:24:10 -0500 X-MC-Unique: yrXW2YBfPRWD2Zv-m8XN7g-1 X-Mimecast-MFC-AGG-ID: yrXW2YBfPRWD2Zv-m8XN7g_1768533849 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4801c105717so11141555e9.0 for ; Thu, 15 Jan 2026 19:24:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768533849; x=1769138649; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CA+JHo1hSbCufZ7/QR/EmmXQGM9RYHp0LpNFVEOQn+w=; b=O5B1oMkDdbpA10+SmIXXA2SRj3QSYTNclr4h0Gj2icVYKkVG9honjW3Mj4pCRURRJG vQeo3exCwMxSomlSMzZb9pHYEm1z6ZIcMbTJN/jrj9paRn1ZztBUbbzCNvZRvnalkQK8 oEeYL/a9cFYK01xbpkljNxM1rvj3zT1oXZAzvfRRem2KBjLNlKX2YKwdx0qZntnbqaeV kmeKjtj1e+/RyFlfE6gC6Zbr4sd0srbaGWPhkzaI1vxOt8CDo/uIf3KwFK0pZpLbM5VM cGVuzqxAZI8r2Ix4MVSfl+VkOkzb9Vs0iDT+eBOPNcGY+ouzP1Iv8PZqjqmktHjoH9ia m/GA== X-Gm-Message-State: AOJu0Yz+nJN2enYGQZ0z32fGG5wtjwAcSwiP+1VSYp9NHu8icHd0AoVS J6VnATmud4bG+1WofqtGM0YCIxyabFWUMme1br2OaBqyun3HRZqRflB8al6uU5gtqJSQucdDhm3 0ob9mT6U1HiE1AHIP4LcaNlsZJm4SCPcR1az3lWoTSZI6ay409NcxjA== X-Gm-Gg: AY/fxX5r2Av15gzMWUoEunQ5tcjSUUlKjX5CQxp4AfUtLyvt7kxhWPOXnPLOdpqPvLK KU+EJS1Fuei91qHFPh/a8uzPyOiMANVDF5Q+MFedkErMLp09bECMHS7kKWcrEWcMJbUxjCMvmKd sQDIepxSdSg26o5hOWi3WtKeiXhYgbSEmyVK9vYIG0CfhQKsObA3k3rlxiizJaMM2IKIReg68rv PQGWtbb+SQMSrWsjZD4Ekw+cEpsea/WJqvSbNuwE5h0Jo4C+cLp+0fD+Sgn+swlBVvNlYaMzkGR 5n6+VU5NKK/+IVUCAkXqC+LIKQY9ZHZSJTvzRUay4zLl1Icf6m2kb1hhp5R/5NVyBq4L0TR3O9H 0tFw8XwqmoHOh/9NXn5BGVzvkXVPfDmWBUMMI5Q== X-Received: by 2002:a05:600c:8816:b0:479:1ac2:f9b8 with SMTP id 5b1f17b1804b1-4801e334379mr14336905e9.21.1768533849267; Thu, 15 Jan 2026 19:24:09 -0800 (PST) X-Received: by 2002:a05:600c:8816:b0:479:1ac2:f9b8 with SMTP id 5b1f17b1804b1-4801e334379mr14336815e9.21.1768533848873; Thu, 15 Jan 2026 19:24:08 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e879537sm19795545e9.5.2026.01.15.19.24.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jan 2026 19:24:08 -0800 (PST) Date: Fri, 16 Jan 2026 04:24:01 +0100 From: Stefano Brivio To: Jon Maloy Subject: Re: PASST/PASST Dynamic Networking Features Message-ID: <20260116042401.41adec0d@elisabeth> In-Reply-To: <686640a9-f760-44a0-ad75-3b9ad20af265@redhat.com> References: <686640a9-f760-44a0-ad75-3b9ad20af265@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 1OvO_r26SFf5bCew2ecTeQ5J5-lq9C2RijrEZlQ8YlE_1768533849 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: N24TMV7OI75IW4HKSVAHP2ZSK6SELMXJ X-Message-ID-Hash: N24TMV7OI75IW4HKSVAHP2ZSK6SELMXJ 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: passt-dev@passt.top, David Gibson 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: Hi, Sorry, it took me a while, but I finally found some hours to review this in detail. On the other hand, I have to say the input wasn't in a format that's very digestible for me (or anything we had vaguely agreed upon). Here are some comments: On Fri, 5 Dec 2025 15:55:04 -0500 Jon Maloy wrote: > Hi all, > Before going further with the implementation, I spent some time to > understand the contents and implications of the various bugs/texts we > have in this area. > > I then tried, to the best of my ability, to compile them into user > stories, which I think might be a good format for our users to > evaluate this. I'm not sure if it's a good format because you can't realistically ask users who reported feature requests almost three years ago, and which we already worked on defining in detail, to now go through a generic list of user stories which is conflating many different aspects and features. That is, I think we are already a couple of steps past that. Besides, my personal take about user stories is that they're great for people who like/need to talk about software development (they add a lot of text! And bullet points! And pretence of modernity!) but I have yet to see any proven benefit for programmers or actual users. This is a matter of taste, indeed, but still... it's a lot of text that's not actually descriptive. "As a container application developer, I want [...]" is longer than "Containers:" but not more descriptive. For example: https://bugs.passt.top/show_bug.cgi?id=47 already has everything we need: use cases and details of what needs to be implemented. Now it's in the same document before a use case stating: As a host user, I want to connect to container services from the host, so that I can access applications running in containers. but that's already supported (since 2021), and it doesn't have much to do with multiple addresses, or with a netlink monitor that reacts on address/route changes, etc. Given all this, https://bugs.passt.top/show_bug.cgi?id=47 and https://pad.passt.top/p/MultipleAddresses still look like a more usable starting point to me. > https://pad.passt.top/p/NetlinkMonitor > > Please have a look and give feedback! I saw that David started reviewing it, and seemingly gave up at some point. I did something similar (I just threw away my notes) because after a couple of points I started asking myself what the scope is ("Dynamic Networking Features" sounds rather broad) and if it's actually productive that I comment point by point. I would rather propose this: if you have questions about specific details of features you listed there (and that you want to take care of for whatever reason), please ask. Other than that, I would stick to the name of that pad and to what, I think, is our biggest priority now, that is, reacting to address / route changes on the host. Containers that programmatically start as boot (for example Podman's quadlets) are partially broken right now because the address they get depend on when they were brought up (not entirely avoidable, but that should have a logic). People have crazy workarounds with busy loops and sleep commands in systemd units. That's *bad*. And your RFC series (minus 12/12, I don't think we want that... at least not yet) seems to provide all the infrastructure we need to fix that, including a part of what we might want to have as final implementation. I think it's a matter of figuring out what we want to do in some non-obvious cases, such as addresses being deleted or conceptual swaps of template interfaces. So I actually went back to the name of the pad I originally created, that is (note the lowercase 'n'): https://pad.passt.top/p/netlinkMonitor and started writing down a few examples of what I think we still need to define. Feel free to use it. If you find it gets in your way, though, perhaps let's just discuss over patchsets instead? -- Stefano