summaryrefslogtreecommitdiff
path: root/Vagrantfile
diff options
context:
space:
mode:
authorMatthew Heon <matthew.heon@pm.me>2020-06-09 17:10:37 -0400
committerPaul Holzinger <paul.holzinger@web.de>2020-12-07 19:26:23 +0100
commitb0286d6b43ebec367c0d9ed87bc6566d76ece8f8 (patch)
treea0629a333e8b1c28dbd78ad75a8a4ccc537fb1f8 /Vagrantfile
parente74072e742a427fbd8577fdc98daf1133cf13c48 (diff)
downloadpodman-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