| Age | Commit message (Collapse) | Author |
|---|
|
Replace two-word "can not" / "Can not" with "cannot" across comments,
ConfigError messages, CLI help text, and op-mode output.
Standard SNMP MIB files under mibs/ are left unchanged.
|
|
Fix typos and mistakes in the commands and comments
No functional changes
|
|
|
|
Container networks are only started when there is at least one active consumer.
If a network is created without any attached containers, it does not need to be
assigned to a VRF yet.
When the last container in a pod is stopped, its associated container network
is removed. Upon container restart, the kernel recreates the network, but the
VRF assignment may be lost in the process.
This change ensures that all container networks are correctly reattached to
their designated VRFs when a pod restarts.
|
|
The call to rc_cmd('podman inspect ...') determines whether a container image
scheduled for deletion has any ancestor containers still using it. Previously,
if the podman command wrote output to stderr, rc_cmd() would return that error
message alongside or instead of the ancestor container ID.
This caused subsequent podman calls to fail, as the error string was incorrectly
treated as a valid command argument. This change ensures only valid ancestor
IDs are returned.
This is a fix for commit a99ca6d11b5 ("op-mode: T7403: add option for forcefully
remove a container image")
|
|
Fixed issue with podman and systemd sync when restarting
containers with 'podman restart' command.
- Placed podman storage directory in vyos/defaults.py
- Replaced repeated declarations with vyos.defaults.directories['podman_storage']
|
|
Commit a99ca6d11 ("op-mode: T7403: add option for forcefully removing a
container image") did not account for the case where a single image ID is
passed as a string. This led to incorrect behavior during iteration.
Without converting the string to a list, the code iterates over individual
characters of the image ID rather than treating it as a single item. As a
result, the system attempts to delete non-existent container images based
on these characters.
|
|
If you have multiple images (tags) loaded for a container which point to the
exact same hash - you can only forcefully delete them.
vyos@vyos:~$ delete container image 70dc5806
Error: unable to delete image "70dc5806" by ID with more than one tag
([registry.io/foo/bar:v1.0 registry.io/foo/bar:v1.0.1]):
please force removal
In additon an image that is still beeing used can not be removed from the
system as this would cause infinite container restarts.
vyos@vyos:~$ delete container image all force
Cannot delete image "d205499ae8bb" because it is currently being used by
container "3b290f90e83d"!
|
|
|
|
The legal team says years are not necessary so we can go ahead with it, since
it will simplify backporting.
Automatically removed using: git ls-files | grep -v libvyosconfig | xargs sed -i -E \
's/^# Copyright (19|20)[0-9]{2}(-[0-9]{4})? VyOS maintainers.*/# Copyright VyOS maintainers and contributors <maintainers@vyos.io>/g'
In addition we will error-out during "make" if someone re-adds a legacy
copyright notice
|
|
journald
|
|
found using "git ls-files *.py | xargs pylint | grep W0611"
|
|
The current VyOS container image manipulation "delete container image" command
allows force removal of container images - even if they still have a container
running.
Drop the --force option from the op-mode script.
vyos@vyos:~$ delete container image 2636705a815a
Error: image used by 6adb0175d47f.. image is in use by a container: consider
listing external containers and force-removing image
|
|
container: T6060: support removing all container images at once via op-mode
|
|
cpo@LR1.wue3:~$ show container image
REPOSITORY TAG IMAGE ID CREATED SIZE
docker.io/library/busybox latest 3f57d9401f8d 5 weeks ago 4.5 MB
docker.io/jacobalberty/unifi v7.5 f6df690d6c67 4 months ago 827 MB
docker.io/jacobalberty/unifi v7.4 7838b75ef7b9 7 months ago 786 MB
cpo@LR1.wue3:~$ delete container image
Possible completions:
3f57d9401f8d Delete container image
7838b75ef7b9
all
f6df690d6c67
cpo@LR1.wue3:~$ delete container image all
cpo@LR1.wue3:~$ show container image
REPOSITORY TAG IMAGE ID CREATED SIZE
|
|
It does not make sense to perform the "podman login" command when setting up
containers, as images are not automatically pulled in from the registry - due
to issues with the default route during startup.
The same issue manifests in "podman login" where we can not login to a registry
unless there is a default route present.
This commit changes the behavior that the container registry is part of the
configuration, but it is only referenced during "add container image" and thus
never during system boot.
|
|
* T5195: move run, cmd, call, rc_cmd helper to vyos.utils.process
* T5195: use read_file and write_file implementation from vyos.utils.file
Changed code automatically using:
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import read_file$/from vyos.utils.file import read_file/g' {} +
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import write_file$/from vyos.utils.file import write_file/g' {} +
* T5195: move chmod* helpers to vyos.utils.permission
* T5195: use colon_separated_to_dict from vyos.utils.dict
* T5195: move is_systemd_service_* to vyos.utils.process
* T5195: fix boot issues with missing imports
* T5195: move dict_search_* helpers to vyos.utils.dict
* T5195: move network helpers to vyos.utils.network
* T5195: move commit_* helpers to vyos.utils.commit
* T5195: move user I/O helpers to vyos.utils.io
|
|
|
|
containers"
This reverts commit b17251334c57c2f6875c19ad4e6c6127aa9e1811.
|
|
|
|
Encapsulating the add/delete image commands in the op-mode script allows
automatic generation of corresponding API schema definitions.
|
|
|
|
|
|
Add option restart to `containers.py`
|
|
Rewrite op-mode:
- show container
- show container network
- show container image
to the new vyos.opmode format
|
