action #30074
closedUse container as a product under test
0%
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?
Updated by coolo almost 7 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.
Updated by pgeorgiadis almost 7 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.
Updated by EDiGiacinto almost 7 years ago
- Related to action #20246: [gsoc] Investigate/implement container-based backend added
Updated by okurz about 5 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.