Project

General

Profile

action #6954

Create Assets and upload them to webui

Added by coolo over 5 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2015-03-25
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Difficulty:
Duration:

Subtasks

action #6972: add disk image extraction support to os-autoinst backendResolvedoholecek

action #6974: define relations between jobs, asset creation and dependent jobs in schedulerResolvedoholecek

action #6976: infrastructure for uploading large filesResolved

History

#1 Updated by coolo over 5 years ago

  • Category set to 132
  • Assignee set to nadvornik

#2 Updated by coolo over 5 years ago

I forgot: we need to schedule tests associated with these assets

#3 Updated by mlin7442 over 5 years ago

I would like to open a discussion about "enable snapshot support to assets" in this topic, the idea is the assets in this target can enable snapshot support as if MAKETESTSNAPSHOT=1 sets, then we can re-use the assets for some test scenario, eg. someone just want to test updated x11 application on an specific version, he can jump to first login, so everytime he can get an fresh environment without those setups what openqa tests did, I think it's useful for important milestone version ie. beta1, beta2, etc. it's not far away from this task, and the snapshot's node can store to DB when the asset created, so I think this feature is worth to do. Any opinion?

#4 Updated by oholecek over 5 years ago

Use cases:
1) save time by skipping installation - reuse multiple installation results for multiple application tests

  • create assets for RAID, NET, DVD, AutoYaST ... installations
  • use these assets for console, KDE, GNOME, xfce ... tests 2) enable 3rd party polling, i.e. Jenkins, for running their test on up-to-date installation

#5 Updated by mlin7442 over 5 years ago

JFYI, about how to handle backing file with snapshot support, I did some experiment with it:

1) the test job with backing file: the derived image can keeps snapshot nodes like below
innoko:/var/lib/openqa/pool/2/raid # qemu-img info 1
image: 1
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 10G
cluster_size: 65536
backing file: /var/lib/openqa/share/factory/hdd/openSUSE-13.1-gnome64.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 installation-isosize 2.9M 2015-03-27 11:45:31 00:00:00.217
2 installation-bootloader 2.9M 2015-03-27 11:45:32 00:00:00.461
3 installation-welcome 6.8M 2015-03-27 11:46:46 00:01:14.025
4 installation-good_buttons 733M 2015-03-27 11:48:10 00:02:37.352
5 installation-upgrade_select 734M 2015-03-27 11:48:24 00:02:37.563
6 installation-installation_overview 995M 2015-03-27 11:49:53 00:03:51.684
7 installation-start_install 995M 2015-03-27 11:50:20 00:03:56.397
8 installation-livecdreboot 997M 2015-03-27 11:50:46 00:04:02.791
Format specific information:
compat: 1.1
lazy refcounts: false

but need to make sure the backing file(ie. base iamge) be there when re-use the derived image.

2) if executed qemu-img convert or reabase/commit(in order to merged the base image and the derived image), the snapshot nodes will lost afterwards

#6 Updated by oholecek about 5 years ago

  • Status changed from New to In Progress

#7 Updated by oholecek about 5 years ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF