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
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