QA (public) » openQA Project (public) » openQA Infrastructure (public)

I've already been creating a draft so I'll assign myself: https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/770

Maybe it makes sense to test/apply this after the security zone migration to avoid doing too many things at once.

Ok, I'll try it out now on OSD then.

EDIT: The change generally doesn't break everything, e.g. sudo salt --no-color --state-output=changes -C 'G@roles:worker' cmd.run 'grep remote_ip /etc/wicked/scripts/gre_tunnel_preup.sh' still shows the IPs as expected. The next step would be removing bridge_ip from the pillars (e.g. in a few places as a start) to see whether then the fallback to use FQDNs works.

EDIT: It doesn't work. I cannot add anything to the salt mine and don't know how to continue. It appears like my change to mine.sls is completely ignored despite having the change now also in the pillars repo.

Setting due date based on mean cycle time of SUSE QE Tools

The deployment pipeline has passed, the salt mine changes are effective and the config looks still sane.

Looks like now there are some template rendering issues in the relevant code:

QA-Power8-5-kvm.qa.suse.de:
    Data failed to compile:
----------
    Rendering SLS 'base:openqa.openvswitch' failed: Jinja variable list object has no element 0
malbec.arch.suse.de:
    Data failed to compile:
----------
    Rendering SLS 'base:openqa.openvswitch' failed: Jinja variable list object has no element 0
worker11.oqa.suse.de:
    Data failed to compile:
----------
    Rendering SLS 'base:openqa.openvswitch' failed: Jinja variable list object has no element 0
worker3.oqa.suse.de:
    Data failed to compile:
----------
    Rendering SLS 'base:openqa.openvswitch' failed: Jinja variable list object has no element 0
worker6.oqa.suse.de:
    Data failed to compile:
----------
    Rendering SLS 'base:openqa.openvswitch' failed: Jinja variable list object has no element 0
worker5.oqa.suse.de:
    Data failed to compile:
----------
    Rendering SLS 'base:openqa.openvswitch' failed: Jinja variable list object has no element 0
worker8.oqa.suse.de:
    Data failed to compile:
----------
    Rendering SLS 'base:openqa.openvswitch' failed: Jinja variable list object has no element 0
worker9.oqa.suse.de:
    Data failed to compile:
----------
    Rendering SLS 'base:openqa.openvswitch' failed: Jinja variable list object has no element 0
worker12.oqa.suse.de:
    Data failed to compile:
----------
    Rendering SLS 'base:openqa.openvswitch' failed: Jinja variable list object has no element 0
worker10.oqa.suse.de:
    Data failed to compile:
----------
    Rendering SLS 'base:openqa.openvswitch' failed: Jinja variable list object has no element 0

(from https://gitlab.suse.de/openqa/salt-states-openqa/-/jobs/1252150)

We've discussed that in the unblock meeting.

About the first issue (#120163#note-11): It only happened once and could not be reproduced. It is likely a general issue with the mine that at some point was apparently not fully populated. So we can likely close this ticket for now (that only introduced yet another use of the mine) but keep it in mind should we see the problem again.

About the second issue (#120163#note-12): It is really unrelated and shouldn't block this ticket from being resolved. It is likely happening because the minion is still busy at the time one attempts to apply states again. I don't really understand it because on the previous run e.g. arm-2 succeeds (no timeout or anything) and on the next run it runs into the problem.