Project

General

Profile

action #20246

[gsoc] Investigate/implement container-based backend

Added by EDiGiacinto about 4 years ago. Updated 11 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2017-07-04
Due date:
% Done:

0%

Estimated time:
Difficulty:

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

Related to openQA Project - action #30074: Use container as a product under testRejected2018-01-09

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

History

#1 Updated by coolo about 4 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

#2 Updated by coolo almost 4 years ago

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

#3 Updated by EDiGiacinto over 3 years ago

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

#4 Updated by EDiGiacinto over 3 years ago

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

#5 Updated by szarate over 3 years ago

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

#6 Updated by okurz over 3 years ago

  • Target version changed from future to future

#8 Updated by okurz almost 3 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

#9 Updated by okurz over 2 years ago

  • Category changed from 132 to Feature requests

#10 Updated by okurz over 1 year ago

#11 Updated by okurz 11 months 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.

Also available in: Atom PDF