action #155857
open[containers] Create podman migration scenario
0%
Description
We need to establish a new migration scenario to check if existing podman
container can be migrated from one SLEM version to the next one.
Our current test design doesn't allow this, because in each test module we create resources and also delete them. We need a new scenario, in which we have a preparation and a validation test module. The purpose is to generate podman containers, validate them, perform the migration and then validate them again.
Test scenario¶
- Generate two new test modules:
testenv_prepare
andtestenv_validate
- In
testenv_prepare
we should generate some containers using the existing system configuration. e.g. A single Tumbleweed container and a pod consisting of two containers, which depend on each other - In
testenv_validate
we check, if the expected containers and pods are present, and if they are functioning
The idea is that one can create different scenarios using those two test modules, e.g.
- Installation
testenv_prepare
testenv_validate
But also a migration scenario like
- Installation
testenv_prepare
testenv_validate
- System update/System migration
testenv_validate
Acceptance criteria¶
- Generate the test modules according to the plan above
- Integrate the new test modules in O3 - The
container-host2microosnext
scenario would be a good candidate
Updated by ph03nix about 1 year ago
This is a good ticket for a squad rotation candidate. I'm blocking it until further notice.
Updated by ph03nix about 1 year ago
- Assignee set to dvenkatachala
We'll reserve this ticket for @dvenkatachala during her squad rotation program, as this is IMHO a good learning project.
Updated by dvenkatachala 12 months ago · Edited
I manually created and ran a Tumbleweed container in SLE Micro 5.5 and migrated it to SLE Micro 6.0. Afterwards, I validated the container's status. I configured the container to start automatically as a systemd service. After the migration, I ensured that the container was running and validated its status.
Container creation.
localhost:~ # podman image ls REPOSITORY TAG IMAGE ID CREATED SIZE registry.opensuse.org/opensuse/tumbleweed latest 2f7e3aae2e12 36 hours ago 143 MB localhost:~ # podman create --name tumbleweed_container_test registry.opensuse.org/opensuse/tumbleweed sleep infinity 099d7f272a4bfd6a2f167bd064034ea5074f712d4cd19d5bf287bbb5a4a5e2de localhost:~ # podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 099d7f272a4b registry.opensuse.org/opensuse/tumbleweed:latest sleep infinity 22 seconds ago Up 3 seconds tumbleweed_container_test localhost:~ # podman container inspect --format='{{.State.Running}}' tumbleweed_container_test true localhost:~ # podman inspect -f '{{.NetworkSettings.IPAddress}}' tumbleweed_container_test 10.88.0.2
Configure the container to start automatically as a systemd service.
localhost:~ # podman generate systemd --new --files --name tumbleweed_container_test /root/container-tumbleweed_container_test.service localhost:~ # cp container-tumbleweed_container_test.service /etc/systemd/system localhost:~ # systemctl start container-tumbleweed_container_test.service localhost:~ # systemctl enable container-tumbleweed_container_test.service Created symlink /etc/systemd/system/default.target.wants/container-tumbleweed_container_test.service → /etc/systemd/system/container-tumbleweed_container_test.service. localhost:~ # podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f5a7a407df10 registry.opensuse.org/opensuse/tumbleweed:latest sleep infinity 3 minutes ago Up 3 minutes tumbleweed_container_test localhost:~ # systemctl stop container-tumbleweed_container_test.service localhost:~ # podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Validate the status of the Podman Tumbleweed container after migrating it to SLE Micro 6.0.
ocalhost login: root Password: Last login: Fri Apr 5 09:05:44 UTC 2024 on ttyS0 Activate the web console with: systemctl enable --now cockpit.socket Have a lot of fun... localhost:~ # podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 81f90c282f2a registry.opensuse.org/opensuse/tumbleweed:latest sleep infinity 14 seconds ago Up 15 seconds tumbleweed_container_test localhost:~ #
Now the next plan is to continue automation with the above steps and later extend the podman container part to pods.
Updated by ph03nix 12 months ago
dvenkatachala wrote in #note-5:
Now the next plan is to continue automation with the above steps and later extend the podman container part to pods.
This is great! I think you could attempt to simplify the setup by modifying the systemd unit in such a way, that you don't need anything else. I mean that on a fresh system you only need to deploy a systemd unit to /etc/systemd/system
, start the unit and the unit creates and destroys the required containers itself?
Updated by dvenkatachala 12 months ago
I have verified the creation of a single Tumbleweed container in SLE-5.5 Micro and ensured the container is running after migrating from SLE-5.5 Micro to SLE-6.0 Micro.
http://deepthi-openqa.qe.suse.de/tests/6857
I will follow up with Felix for further progress .
Updated by ph03nix 12 months ago
The current state looks already very good! We agreed to prepare a first PR by extending the current container test by a network check. This means that the container needs to publish a port and provide a testable service, that we can check. e.g. a webserver where we could fetch a predefined website and verify if the expected site (or identifiable parts of it) is being delivered.
Updated by dvenkatachala 12 months ago · Edited
The first PR is about running a Podman Nginx container under systemd and ensuring that the Nginx container is still running after the migration
PR : https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/19084
Updated by dvenkatachala 11 months ago · Edited
Created two containers within a pod under systemd and ensured that both the containers and the pod are running after migrating from SLEM-5.5 to SLEM-6.0.
PR- https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/19163.
scheduled in the OSD development job group - https://openqa.suse.de/tests/14130940
Updated by dvenkatachala 11 months ago
- Status changed from In Progress to Feedback
Updated by JERiveraMoya 11 months ago
When you see that is stable, let us know so we can add it to our test coverage for review. Where this will be if it is already in GMC, in maintenance?
Updated by ph03nix 11 months ago
JERiveraMoya wrote in #note-12:
When you see that is stable, let us know so we can add it to our test coverage for review. Where this will be if it is already in GMC, in maintenance?
Currently this is still a prototype.
I remember the agreement was that for SLEM 5.5 -> 6.0 this is going to be tested manually, no?
Updated by etchubykalo 11 months ago
- Status changed from Feedback to In Progress
- Assignee changed from dvenkatachala to etchubykalo
Updated by ph03nix 10 months ago · Edited
Hey @etchubykalo, what is the status of this ticket? Are there any updates in the meantime or are you blocked somehow?
Updated by etchubykalo 7 months ago
working on some higher priority tickets, but this is still on my list.
Updated by ph03nix 6 months ago
I feel this ticket is progressing too slow. @etchubykalo what is the status?
Updated by ph03nix about 2 months ago
- Tags changed from containers to containers, to-be-refined
- Status changed from Workable to Blocked
Needs refinement
Updated by ph03nix about 2 months ago
- Tags changed from containers, to-be-refined to containers
- Status changed from Blocked to In Progress
AFAICS the current state is that there is a prototype implementation for the testenv_prepare
and testenv_validate
steps as requested (https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/19163) but there is no scenario defined yet.
So what we need to do, is to
- Understand if https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/19163 fullfills the needs for a migration test
- Integrate this in the Tumbleweed test scenarios (see below)
- Notify the Migration squad about the availability of those test runs
To Tumbleweed I see that this probably should be part of the following scenarios:
container_host-old2microosnext
container_host2microosnext
zdup_twjeos2twnext@64bit_virtio
I'm not sure if that's feasible for all of them. If there are obstacles, we can discuss the coverage there.
Updated by slo-gin 25 days ago
This ticket was set to High priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.