Project

General

Profile

Actions

action #98664

closed

Hiding test data

Added by tonyyuan about 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Support
Target version:
Start date:
2021-09-15
Due date:
% Done:

0%

Estimated time:

Description

The virtualization test sometimes need to create several guest VMs in a openQA job. They have different sles versions installed. Some guests in ltss stage require Ltss repos to be added from scc. As we know, each ltss sles version has an unique ltss code. An easy solution is to create a hash, something like test data:

$ltss= {
sles15sp1 => "ltss code1",
sles15 => "ltss code2",
sles12sp4 => "ltss code3"
...
}

The problem is that ltss code can't be exposed to public in github. The hash can't be placed in source code, schedule yaml, data, asset because they are all public in github.

Can some test data be hidden in OpenQA. Is there a way of using private test data in OpenQA?

Actions #1

Updated by okurz about 3 years ago

  • Due date set to 2021-09-30
  • Assignee set to okurz
  • Target version set to Ready

The problem is that ltss code can't be exposed to public in github. The hash can't be placed in source code, schedule yaml, data, asset because they are all public in github.

Maybe you are confusing something. For SLE tests the schedule data is mostly on gitlab.nue.suse.com which is SUSE-internal so not public

Actions #2

Updated by okurz about 3 years ago

  • Project changed from openQA Infrastructure to openQA Project
  • Category set to Support
Actions #3

Updated by okurz about 3 years ago

  • Status changed from New to Feedback
Actions #4

Updated by tonyyuan about 3 years ago

Hello,
Let me clearly it a bit more.

I have a test data, a hash which have some scc code for internal test:

$ltss= {
sles15sp1 => "ltss code1",
sles15 => "ltss code2",
sles12sp4 => "ltss code3"
...
}

I don't know where to define/place it because the places which are supposed to store test data in source tree: test module, the files in factory/other/, data/, schedule/ are all public in github.

So, my request is that OpenQA infrastructure should provide someplace for us to store private test data. It should be easy to retrieve in test run.

By the way, gitlab.nue.suse.com isn't working. Maybe, you mean gitlab.suse.de? I know the job groups schedule and settings are stored in gitlab.suse.de. However, they do not support data structure, like hash.

Actions #5

Updated by okurz about 3 years ago

tonyyuan wrote:

I don't know where to define/place it because the places which are supposed to store test data in source tree: test module, the files in factory/other/, data/, schedule/ are all public in github.

Well, https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/data and https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/schedule are public, correct. But what do you mean with "factory/other/" being on github? It's merely a simple local directory on OSD which is filled from assets copied there. Which means that you can also copy data there which can be made available as assets and then provided as tests to be read there. So you could put your hash as perl code in a file, put it into these other assets, register in tests as assets and access from tests.

Another alternative might be to checkout a git submodule from an internal git repo into a subfolder of the checkout folder of os-autoinst-distri-opensuse. The management of that git checkout folder should be done in https://gitlab.suse.de/openqa/salt-states-openqa where you can create a merge request.

By the way, gitlab.nue.suse.com isn't working. Maybe, you mean gitlab.suse.de?

Well, I did mean gitlab.nue.suse.com but that points to gitlab.suse.de . So using either is fine although in a properly configured network both domains nue.suse.com as well as suse.de should work

I know the job groups schedule and settings are stored in gitlab.suse.de. However, they do not support data structure, like hash.

Well, I don't know if anybody has used test settings in this way but I am pretty sure that for example a properly escaped YAML document in a test setting could be defined and read from test code. The low-tech alternative of course would be to define the hash values as individual job settings, e.g. following your above example

  • SCC_REGCODE_LTSS_SLES15SP1="ltss code1"
  • SCC_REGCODE_LTSS_SLES15="ltss code2"
Actions #6

Updated by tonyyuan about 3 years ago

The simplest workaround I have thought of is to create one single VAR, like:
LTSS_PRODUCTS_CODES="15.1,INTERNAL-USE-xxxxxx,15,INTERNAL-USE-ONLY-yyyyyyy,12.4,INTERNAL-USE-ONLY-cccccc,12.3,INTERNAL-USE-ONLY-dddddd".

This VAR can be placed in testsuite definitions or jobgroup template settings which are not public.

Then ,convert it to hash in the test code:
my %ltss_products_codes = @{get_var_array("LTSS_PRODUCTS_CODES")};

The hash key is product version and value is the ltss code.

However, the value of LTSS_PRODUCTS_CODES is quite lengthy string. It looks wired and ugly. That is why I am asking: maybe openQA should provide a better way for us to keep private data.

Actions #7

Updated by okurz about 3 years ago

However, the value of LTSS_PRODUCTS_CODES is quite lengthy string. It looks wired and ugly. That is why I am asking: maybe openQA should provide a better way for us to keep private data.

have you read my comment in https://progress.opensuse.org/issues/98664#note-5 regarding putting assets in the "other/" directory?

Actions #8

Updated by tonyyuan about 3 years ago

okurz wrote:

However, the value of LTSS_PRODUCTS_CODES is quite lengthy string. It looks wired and ugly. That is why I am asking: maybe openQA should provide a better way for us to keep private data.

have you read my comment in https://progress.opensuse.org/issues/98664#note-5 regarding putting assets in the "other/" directory?

Yes, I have.
A question: Is there a way to handle the file in worker pool directory? You know, it might not make sense to handle file with data like ltss code in SUT. I mean that downloading it into SUT, then retrieving it via "script_output" does not look good.

Actions #9

Updated by okurz about 3 years ago

Yes. Files in the pool directory can be directly opened by standard perl code. The pool directory is the "current directory" so just opening by filename should work

Actions #10

Updated by okurz about 3 years ago

  • Due date deleted (2021-09-30)
  • Status changed from Feedback to Resolved

hi, I assume the above options should be sufficient for you to try. You are welcome to respond back if there are still open points.

Actions

Also available in: Atom PDF