Project

General

Profile

Actions

action #20246

closed

[gsoc] Investigate/implement container-based backend

Added by EDiGiacinto over 7 years ago. Updated about 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
QA (public, currently private due to #173521) - future
Start date:
2017-07-04
Due date:
% Done:

0%

Estimated time:

Description

As spoken briefly with Richard, i couldn't find an already open issue regarding containers support in the backend, so opening a new one.

User story

As a tester, i want to be able to test containers and validating images before going further down in the pipelines. (e.g. testing images before being used for deploying container-based services in multi-machine environments)

acceptance criteria

  • AC1: transparent implementation to support different types of containerization technologies ( docker, rkt, lxc .. )
  • AC2: do not have to increase tweakings or options to overwhelm the tester
  • AC3: try to provide maximum compatibility on features that we use already in VM-based backends
  • ...

tasks

  • Investigate required changes to the codebase and look into cpan if there are modules that we could use
  • Provide basic support to handle containers operations in the backend side
  • Add support for the docker backend (as we use it in some of our products)
  • ...

further details

Investigate if makes sense implement a backend for containers.
In case it is, we should discuss also what container-based backend(s) we would like to add support to.

A backend capable of directly testing containers could be useful since we provide container images, and might add business value as well ( as CaaSP is using docker ).


Related issues 2 (0 open2 closed)

Related to openQA Project (public) - action #30074: Use container as a product under testRejectedokurz2018-01-09

Actions
Related to openQA Tests (public) - action #12804: [qe-core][functional][sles][opensuse][installation] Do more easy to debug tests by using chroot installations … or containers :)Rejected2016-07-21

Actions
Actions #1

Updated by coolo over 7 years ago

testing containers within reference vms is good enough for the moment - and we have other requirements that are not possible at all. So I'm inclined to set this to future milestone

Actions #2

Updated by coolo about 7 years ago

  • Subject changed from [tools]Investigate/implement container-based backend to Investigate/implement container-based backend
  • Target version set to future
Actions #3

Updated by EDiGiacinto almost 7 years ago

  • Related to action #30074: Use container as a product under test added
Actions #4

Updated by EDiGiacinto almost 7 years ago

  • Subject changed from Investigate/implement container-based backend to [gsoc] Investigate/implement container-based backend
Actions #5

Updated by szarate almost 7 years ago

Talking to panos, he mentioned this (Which seems to be using systemd-nspawn) https://github.com/drpaneas/egkatastasis

Actions #6

Updated by okurz over 6 years ago

  • Target version changed from future to future
Actions #8

Updated by okurz about 6 years ago

  • Related to action #12804: [qe-core][functional][sles][opensuse][installation] Do more easy to debug tests by using chroot installations … or containers :) added
Actions #9

Updated by okurz over 5 years ago

  • Category changed from 132 to Feature requests
Actions #10

Updated by okurz almost 5 years ago

Actions #11

Updated by okurz about 4 years ago

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

The issue for GSOC is still open. For us in this ticket I assess that we do not need to keep this reference. The current approach to test container images within openQA tests is still as mentioned in https://progress.opensuse.org/issues/20246#note-1 within the scope of a surrounding OS running the container images. This has the benefit of keeping it visible to test reviewers what the actual surrounding environment is which can have quite some impact on the executed container instances. Just for comparison our s390x z/VM as well as s390x kvm backend is trying to "abstract away" the surrounding layers including an additional X server, vncviewer and such. As this layer is not without problems this is making it hard for test reviewers to understand what is going on so also not the best approach.

Actions

Also available in: Atom PDF