coordination #80372
closedcoordination #58184: [saga][epic][use case] full version control awareness within openQA
[epic] Cleanup vars.json as initial information container between openQA worker and isotovideo
Description
Motivation¶
openQA leaks internal data about cache directory and other data into vars.json and to isotovideo. This causes problems like #67723 that we try to fix, makes it impossible for any user to run tests just by downloading the vars.json file without changes and also makes the "investigation" tab show up irrelevant changes when a scenario has been running jobs on different worker hosts or instances which is likely to happen. We should ensure a proper design from openQA side that we only write to vars.json what is portable and make os-autoinst cope with that.
Also see #58184
Acceptance criteria¶
- AC1: #67723 can be fixed without hacky workarounds (okurz: I know, this is quite subjective)
- AC2: A
vars.jsonfile downloaded from any production worker can be run locally with isotovideo without needing to replace all "cache" related paths to point to local paths - AC3: A diff of
vars.jsonfiles between two jobs from different worker instances and/or machines within one scenario show less irrelevant, automatic changes, e.g. no "cache" related ones
Suggestions¶
As os-autoinst already supports relative paths, how about not writing something like
PRODUCTDIR=/var/lib/openqa/cache/openqa1-opensuse/tests/opensuse/products/opensusebut symlink the test distribution into the current pool folder of the worker and use justPRODUCTDIR=opensuse/products/opensuse? As an alternative, maybe we do not need to care about PRODUCTDIR in openQA at all but move that logic to os-autoinst.As discussed in daily 2020-11-27 we were thinking about another approach, probably even easier: We can add a default fallback value for CASEDIR to read the current directory. Then in the openQA worker we create the symlink as mentioned above and do not need to specify CASEDIR at all
Updated by Xiaojing_liu over 3 years ago
- Blocks coordination #67723: [epic] Remote openQA worker fails to run tests from openqa-clone-custom-git-refspec added
Updated by livdywan over 3 years ago
- Status changed from New to Feedback
Another approach from Jane is being discussed on GitHub, hence Feedback:
Updated by okurz over 3 years ago
- Status changed from Feedback to Workable
it's good that we explore the ideas but actually I would like to set the epic to "Workable" as anyone can be the epic owner and create according subtasks
Updated by okurz over 3 years ago
Based on our discussion today and me looking into the current use of DISTRI and other variables within os-autoinst I am once again sure that we should not need any additional variables within os-autoinst.
Unless I am mistaken os-autoinst already has all variables that are needed to describe all possible situations that we need to support. And all variables should support relative directories, i.e. CASEDIR, PRODUCTDIR, NEEDLES_DIR. We already mentioned this in https://github.com/os-autoinst/os-autoinst/pull/1569#discussion_r529016541 .
My suggestion in https://github.com/os-autoinst/openQA/pull/3604#issuecomment-736575668 is still true, mainly about relative directories and providing symlinks within the scope of openQA.
My idea is (still) that with just relative directories specified by openQA and all necessary data available from these relatives directories it should be possible to fully specify what os-autoinst needs but still provide clone-able jobs.
I am trying to come up with some different cases we need to support with according example variable settings:
- absolute casedir path with needles in same repo, no caching, no git:
casedir=/var/lib/openqa/share/tests/foo(+ needles inneedles/, not necessary to specify, read by default in https://github.com/os-autoinst/os-autoinst/blob/master/needle.pm#L324) - absolute casedir path with productdir, no caching, no git:
casedir=/var/lib/openqa/share/tests/foo+productdir=products/opensuse(+ needles inneedles/, now relative to productdir, still not necessary to specify, also covered by https://github.com/os-autoinst/os-autoinst/blob/master/needle.pm#L324) - casedir path with productdir, caching, no git:
casedir=foo(symlink to /var/lib/…/cache/…) +productdir=products/opensuse(+ needles inneedles/, still relative to productdir, same as in 2.) - casedir path with productdir, caching, git, needles not in same git:
casedir=https://github.com/my/repo+productdir=products/opensuse+needles_dir=needles(now specified explicitly, symlinked from cache into pool)
So with this I expect that we can get the change done without needing to change anything in os-autoinst, just by providing symlinks in the openQA worker pool directory and specifying relative directory variables instead of absolute ones.
Updated by Xiaojing_liu over 3 years ago
- Blocks action #81703: The values of 'ISO' and 'HDD' includes absolute path in vars.json added
Updated by Xiaojing_liu over 3 years ago
- Blocks deleted (action #81703: The values of 'ISO' and 'HDD' includes absolute path in vars.json)
Updated by okurz about 3 years ago
https://github.com/os-autoinst/openQA/pull/3604 was merged and reverted again in https://github.com/os-autoinst/openQA/pull/3693 after an error report https://github.com/os-autoinst/openQA/pull/3604#issuecomment-765888161
Updated by okurz about 3 years ago
- Status changed from Workable to Blocked
- Assignee set to okurz
Updated by okurz almost 3 years ago
- Copied to coordination #92314: [epic] Cleanup vars.json as initial information container between openQA worker and isotovideo - further cleanup added
Updated by okurz almost 3 years ago
- Status changed from Blocked to Resolved
I tested now. Downloaded vars.json from https://openqa.opensuse.org/tests/1730497 and with a command ln -sf ~/local/os-autoinst/opensuse && isotovideo -d iso=~/local/tmp/openSUSE-Leap-15.2-NET-x86_64.iso I could successfully start tests so that covers AC2.
https://openqa.opensuse.org/tests/1730365#investigation shows no cache related changes for an investigation showing the diff between two jobs on different worker machines and instances which covers AC3. AC1 is already covered by the referenced ticket. The subtask #81703 is still open but can be followed up with independant of AC1-3 so I split out an epic #92314 , set that as parent for #81703 and resolving the current ticket.