Project

General

Profile

Actions

action #155857

open

[containers] Create podman migration scenario

Added by ph03nix about 1 year ago. Updated 4 days ago.

Status:
In Progress
Priority:
High
Assignee:
Target version:
-
Start date:
2024-04-01
Due date:
% Done:

0%

Estimated time:

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 and testenv_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
Actions #1

Updated by ph03nix about 1 year ago

This is a good ticket for a squad rotation candidate. I'm blocking it until further notice.

Actions #3

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.

Actions #4

Updated by ph03nix 12 months ago

  • Status changed from Blocked to In Progress

Unblocking ticket, as Dee joined our squad.

Actions #5

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.

Actions #6

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?

Actions #7

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 .

Actions #8

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.

Actions #9

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

Actions #10

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

Actions #11

Updated by dvenkatachala 11 months ago

  • Status changed from In Progress to Feedback
Actions #12

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?

Actions #13

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?

Actions #14

Updated by ph03nix 11 months ago

  • Tags set to slem
  • Project changed from 216 to Containers and images
Actions #15

Updated by etchubykalo 11 months ago

  • Status changed from Feedback to In Progress
  • Assignee changed from dvenkatachala to etchubykalo
Actions #16

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?

Actions #17

Updated by etchubykalo 7 months ago

working on some higher priority tickets, but this is still on my list.

Actions #18

Updated by ph03nix 6 months ago

I feel this ticket is progressing too slow. @etchubykalo what is the status?

Actions #19

Updated by etchubykalo 5 months ago

  • Assignee deleted (etchubykalo)
Actions #20

Updated by ph03nix 5 months ago

  • Tags changed from slem to containers
Actions #21

Updated by ph03nix 5 months ago

  • Status changed from In Progress to Workable
Actions #22

Updated by ph03nix 5 months ago

  • Subject changed from Create podman migration scenario to [containers] Create podman migration scenario
Actions #23

Updated by ph03nix about 2 months ago

  • Priority changed from Normal to High
Actions #24

Updated by vkatkalov about 2 months ago

  • Assignee set to vkatkalov
Actions #25

Updated by ph03nix about 2 months ago

  • Tags changed from containers to containers, to-be-refined
  • Status changed from Workable to Blocked

Needs refinement

Actions #26

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

  1. Understand if https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/19163 fullfills the needs for a migration test
  2. Integrate this in the Tumbleweed test scenarios (see below)
  3. 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.

Actions #27

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.

Actions #28

Updated by vkatkalov 4 days ago

  • Status changed from In Progress to Workable
  • Assignee deleted (vkatkalov)
Actions #29

Updated by rbranco 4 days ago

  • Status changed from Workable to In Progress
  • Assignee set to rbranco
Actions

Also available in: Atom PDF