action #6954

Create Assets and upload them to webui

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

Status:ResolvedStart date:25/03/2015
Priority:NormalDue date:
Assignee:nadvornik% Done:

100%

Category:Feature requests
Target version:Sprint 16
Difficulty:
Duration:

Subtasks

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

action #6974: define relations between jobs, asset creation and depende...Resolvedoholecek

action #6976: infrastructure for uploading large filesResolved

History

#1 Updated by coolo about 5 years ago

  • Category set to 132
  • Assignee set to nadvornik

#2 Updated by coolo about 5 years ago

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

#3 Updated by mlin7442 about 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 about 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 about 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 almost 5 years ago

  • Status changed from New to In Progress

#7 Updated by oholecek almost 5 years ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF