diff options
author | Matthew Heon <matthew.heon@pm.me> | 2020-06-09 17:10:37 -0400 |
---|---|---|
committer | Paul Holzinger <paul.holzinger@web.de> | 2020-12-07 19:26:23 +0100 |
commit | b0286d6b43ebec367c0d9ed87bc6566d76ece8f8 (patch) | |
tree | a0629a333e8b1c28dbd78ad75a8a4ccc537fb1f8 /Vagrantfile | |
parent | e74072e742a427fbd8577fdc98daf1133cf13c48 (diff) | |
download | podman-b0286d6b43ebec367c0d9ed87bc6566d76ece8f8.tar.gz podman-b0286d6b43ebec367c0d9ed87bc6566d76ece8f8.tar.bz2 podman-b0286d6b43ebec367c0d9ed87bc6566d76ece8f8.zip |
Implement pod-network-reload
This adds a new command, 'podman network reload', to reload the
networks of existing containers, forcing recreation of firewall
rules after e.g. `firewall-cmd --reload` wipes them out.
Under the hood, this works by calling CNI to tear down the
existing network, then recreate it using identical settings. We
request that CNI preserve the old IP and MAC address in most
cases (where the container only had 1 IP/MAC), but there will be
some downtime inherent to the teardown/bring-up approach. The
architecture of CNI doesn't really make doing this without
downtime easy (or maybe even possible...).
At present, this only works for root Podman, and only locally.
I don't think there is much of a point to adding remote support
(this is very much a local debugging command), but I think adding
rootless support (to kill/recreate slirp4netns) could be
valuable.
Signed-off-by: Matthew Heon <matthew.heon@pm.me>
Signed-off-by: Paul Holzinger <paul.holzinger@web.de>
Diffstat (limited to 'Vagrantfile')
0 files changed, 0 insertions, 0 deletions