QA » openQA Project

okurz wrote:

https://github.com/os-autoinst/openQA/pull/3799 is merged. As https://github.com/os-autoinst/os-autoinst/pull/1634 already includes a fix for all the cases where we assume we had problems I suggest after deployment to enable the feature on o3 completely, e.g. within the worker config of all our production workers, then wait a week, then enable on OSD, then wait a week, then go on with other features for which we brought in this change initially.

As ENABLE_RELATIVE_PATH is a job setting, do you mean to add it to the worker settings of each worker via the web UI? I was thinking per job group 🤔️

@Xiaojing_liu Please document what you decide to enable

cdywan wrote:

As ENABLE_RELATIVE_PATH is a job setting, do you mean to add it to the worker settings of each worker via the web UI? I was thinking per job group 🤔️

So which job groups did you think about then? We want the new behaviour to be default. And given the variable precedence it should be possible to set ENABLE_RELATIVE_PATH=1 in the worker config and where necessary we can set +ENABLE_RELATIVE_PATH=0 e.g. in specific test suites or job groups where we identify problems.

cdywan wrote:

okurz wrote:

https://github.com/os-autoinst/openQA/pull/3799 is merged. As https://github.com/os-autoinst/os-autoinst/pull/1634 already includes a fix for all the cases where we assume we had problems I suggest after deployment to enable the feature on o3 completely, e.g. within the worker config of all our production workers, then wait a week, then enable on OSD, then wait a week, then go on with other features for which we brought in this change initially.

As ENABLE_RELATIVE_PATH is a job setting, do you mean to add it to the worker settings of each worker via the web UI? I was thinking per job group 🤔️

@Xiaojing_liu Please document what you decide to enable

I think we shouldn't add it to the worker settings. Just as @cdywan said, ENABLE_RELATIVE_PATH is a job setting, we don't add worker's setting into the job's setting, so maybe this way doesn't make sense.
My intent was that adding this param when doing isos post, but I don't know where the command is called when a new build coming.

I think we shouldn't add it to the worker settings. Just as @cdywan said, ENABLE_RELATIVE_PATH is a job setting, we don't add worker's setting into the job's setting, so maybe this way doesn't make sense.

Well, everything is a job setting. The worker settings end up in job settings as well, isn't it?

My intent was that adding this param when doing isos post, but I don't know where the command is called when a new build coming.

It comes from https://github.com/os-autoinst/openqa-trigger-from-obs . Don't make that too complicated. Our intention is to have that behaviour enabled by default anyway. So unless you have a better idea I suggest to just enable it everywhere and then we can exclude it where needed until we have all the special cases fixed as well. If you want to go step-wise, how about adding it in the media. But likely these are already also too many to be easily changeable.

okurz wrote:

I think we shouldn't add it to the worker settings. Just as @cdywan said, ENABLE_RELATIVE_PATH is a job setting, we don't add worker's setting into the job's setting, so maybe this way doesn't make sense.

Well, everything is a job setting. The worker settings end up in job settings as well, isn't it?

My intent was that adding this param when doing isos post, but I don't know where the command is called when a new build coming.

It comes from https://github.com/os-autoinst/openqa-trigger-from-obs . Don't make that too complicated. Our intention is to have that behaviour enabled by default anyway. So unless you have a better idea I suggest to just enable it everywhere and then we can exclude it where needed until we have all the special cases fixed as well. If you want to go step-wise, how about adding it in the media. But likely these are already also too many to be easily changeable.

I see. I wasn't sure if adding the settings in the worker configuration file worked. And you are right, it works. So I think we can enable this by adding setting in worker's files.

Xiaojing_liu wrote:

okurz wrote:

I think we shouldn't add it to the worker settings. Just as @cdywan said, ENABLE_RELATIVE_PATH is a job setting, we don't add worker's setting into the job's setting, so maybe this way doesn't make sense.

Well, everything is a job setting. The worker settings end up in job settings as well, isn't it?

My intent was that adding this param when doing isos post, but I don't know where the command is called when a new build coming.

It comes from https://github.com/os-autoinst/openqa-trigger-from-obs . Don't make that too complicated. Our intention is to have that behaviour enabled by default anyway. So unless you have a better idea I suggest to just enable it everywhere and then we can exclude it where needed until we have all the special cases fixed as well. If you want to go step-wise, how about adding it in the media. But likely these are already also too many to be easily changeable.

I see. I wasn't sure if adding the settings in the worker configuration file worked. And you are right, it works. So I think we can enable this by adding setting in worker's files.

Adding the setting in worker configuration works, but there is another problem. If we add the setting in worker file, we cannot change it unless we change the value in the worker file. Because we handle the job's setting first, then adding the worker's setting into it. So the worker's setting will override the same job settings. @okurz how about adding this to machines' settings? the number of machines is less than the media.

This all sounds way too complicated. Again, as the goal should be to have the relative paths the default behaviour I now suggest that we follow our suggestions but in a slightly different order. So create a PR that turns around the feature flag to make relative paths the default unless disabled by a feature flag. Then again, wherever we hit problems in tests the test maintainers can choose which place is the most suitable to go back to absolute paths, be it individual test suites, job groups, machines or workers.

PR: https://github.com/os-autoinst/openQA/pull/3817