Re: PASST/PASST Dynamic Networking Features

[Stefano Brivio <sbrivio@redhat.com>]

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 <jmaloy@redhat.com> 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