| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
due to a lack of "locking" on cni operations, we could get ourselves in trouble when doing rapid creation or removal of networks. added a simple file lock to deal with the collision and because it is not considered a performent path, use of the file lock should be ok. if proven otherwise in the future, some generic shared memory lock should be implemented for libpod and also used here.
moved pkog/network to libpod/network because libpod is now being pulled into the package and it has therefore lost its generic nature. this will make it easier to absorb into libpod as we try to make the network closer to core operations.
Fixes: #7807
Signed-off-by: baude <bbaude@redhat.com>
|
|
|
|
| |
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the advent of Podman 2.0.0 we crossed the magical barrier of go
modules. While we were able to continue importing all packages inside
of the project, the project could not be vendored anymore from the
outside.
Move the go module to new major version and change all imports to
`github.com/containers/libpod/v2`. The renaming of the imports
was done via `gomove` [1].
[1] https://github.com/KSubedi/gomove
Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The pkg/network/files.go methods currently use the constant '/etc/cni/net.d'
for network handling. This results in the unability of podman-network-inspect
and podman-network-rm to locate the cni network configuration files.
This commit propagates the libpod.Runtime through the networking methods and
finally makes use of its configuration (config.Network.NetworkConfigDir).
Closes #6212
Signed-off-by: Maximilian Müller <maxm123@techie.com>
|
|
|
|
|
|
|
|
| |
when creating a new networking, we should check existing networks for
their bridge names and make sure the proposed new name is not part of
this. reported by QE.
Signed-off-by: baude <bbaude@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
when removing a podman network, we need to make sure we delete the
network interface if one was ever created (by running a container).
also, when removing networks, we check if any containers are using the
network. if they are, we error out unless the user provides a 'force'
option which will remove the containers in question.
Signed-off-by: baude <bbaude@redhat.com>
|
|
initial implementation of network create. we only support bridging
networks with this first pass.
Signed-off-by: baude <bbaude@redhat.com>
|