Project

General

Profile

Actions

action #30074

closed

Use container as a product under test

Added by pgeorgiadis about 6 years ago. Updated over 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
-
Start date:
2018-01-09
Due date:
% Done:

0%

Estimated time:

Description

From what I know, I can use either an 'ISO' or a 'qcow2' image and start testing it. What if I want to boot from a Docker container image or systemd-nspawn image instead?


Related issues 1 (0 open1 closed)

Related to openQA Project - action #20246: [gsoc] Investigate/implement container-based backendRejectedokurz2017-07-04

Actions
Actions #1

Updated by coolo about 6 years ago

I'd go with a fixed HDD_1 and downloading the container into the VM to run there. This might be overkill, but the VMs boot fast enough for testing.

If that won't work for the use case (you didn't specify a user story actually), use a hop into a predefined docker host.

Actions #2

Updated by pgeorgiadis about 6 years ago

Scenario:

Given we build Docker images in OBS
When those images are ready to be released into a registry (SUSE Registry or DockerHub)
Then they should be tested first

In the past, our opensuse docker images had serious problems (orphaned packages, wrong repositories). These problems can be easily mitigated by applying basic testing.

The analogy of having 1 VM per 1 container doesn't scale, yet I'm fine going with that as long as we have enough hardware resources to support this. Currently, we don't build that many containers, but we need to keep an eye in case the situation changes (in the future).

So, how do we proceed? Should we define some standard procedure? e.g. make a 'golden' HDD image that boots fast (JeOS or MicroOS/Kubic maybe?) and is recommended by default in these container testing scenarios.

Actions #3

Updated by EDiGiacinto about 6 years ago

  • Related to action #20246: [gsoc] Investigate/implement container-based backend added
Actions #4

Updated by okurz over 4 years ago

  • Status changed from New to Rejected
  • Assignee set to okurz

I discussed this with fvogt and we came to the conclusion that the environment under which a container is spawned does matter. So far many containers and their according ecosystem are covered in os-autoinst-distri-opensuse with good success. There are other CI's more suited for working directly with containers, but not necessarily considering them as "product under test". So I think we don't need this anymore.

Actions

Also available in: Atom PDF