RFC: buildah bud cache network namespace for all run statements

[Luap99]

When building a dockerfile with more than one run statement and private networking set, buildah will create a new network namespace each time. Network setup and teardown is slow especially for CNI (60-100 ms on my laptop just for one setup). I think we can improve the build time when we reuse the network namespace.

One problem with this could be when a process is modifying the network namespace and the next run command wants to start from a "clean" state. Also I do not think this can work with custom uid/gid mapping.

[flouthoc]

@Luap99 I don't think we should do this by default for the very same reason that each RUN has ability to modify and playaround in network namespace and other RUN should not inherit those changes unless specified.

Do you think we could have a dedicated flag for advanced users --share-namespaces [] where users could do it if they want to but I doubt if any regular user would like to do it.

[Luap99]

If the container is run with seccomp and restricted capabilities (which is the default AFAIK) you cannot change the network namespace in any meaningful way. I think this could be a good way to save build time. We need to execute the network stack every time, also if we really enable dns by default for netavark then this will get even slower.

[Luap99]

BTW I just tried this with docker build and they share the same namespace

[flouthoc]

Do you think we could have a dedicated flag for advanced users --share-namespaces [] where users could do it if they want to but I doubt if any regular user would like to do it.

Then this should be other-way around for the people who want to do changes with custom seccomp and capabilities maybe --dont-share-namespaces [].

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

If this is not a problem with netavark, should we close?

[Luap99]

Netavark is faster than CNI but it is still slow (about 40 ms for a simple setup call). I think this could safe a lot of time for people with many run statements.

[rhatdan]

What is your definition of many run statements? I could potentially see this in CI systems, but I think in the real work not likely to be seen. I don't think this effects RUN commands in Containerfiles. My fear here is the complexity of cleaning this up. @nalind WDYT?

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@Luap99 interested in opening a PR to add this feature?

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@flouthoc any time to work on this?

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

Since no one ever moved forward on this, and I am not sure it saves much in the real world, closing.