Project

General

Profile

Actions

action #107173

closed

s.qa.suse.de needs to be upgraded to a current OS

Added by okurz almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Start date:
2022-02-21
Due date:
% Done:

0%

Estimated time:

Description

Not strictly SUSE QE Tools but maintained originally by nsinger so needs to be done here.


Related issues 1 (0 open1 closed)

Related to QA (public) - action #107731: Salt all SUSE QA machines, at least passwords and ssh keys and automatic upgrading size:MResolvedokurz2022-03-01

Actions
Actions #1

Updated by okurz almost 3 years ago

  • Status changed from New to In Progress
  • Assignee set to okurz

nginx currently already shows "502 Bad Gateway" so I can try to upgrade as it's already broken :)

Actions #2

Updated by okurz almost 3 years ago

From nsinger: link shortener is backā€¦ uwsgi service was not starting (needs to be enabled) but also /var/run/uwsgi needs to be created before starting the service.

Actions #3

Updated by okurz almost 3 years ago

I wonder if we should just add the host to the salt controlled infrastructure of OSd as well. Or similar to how we do https://gitlab.suse.de/qa-sle/backup-server-salt maybe.

Actions #4

Updated by openqa_review almost 3 years ago

  • Due date set to 2022-03-08

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

Actions #5

Updated by okurz almost 3 years ago

  • Priority changed from High to Normal

Fully upgraded to Leap 15.3 and working. I plan to salt it later.

Actions #6

Updated by okurz almost 3 years ago

  • Status changed from In Progress to Feedback

I forgot to mention that upgrading caused a problem due to a missing magic coding comment in schort.py so I created https://github.com/sqozz/schort/pull/8 to fix that.

I have created a salt repo on https://gitlab.suse.de/qa-sle/s-salt.git with initial configuration from what I found in history and the files that likely are necessary.
I installed SUSE certificates with the help of http://ca.suse.de/gettingstarted/#system and have cloned the salt recipes initially with git -C /srv clone https://gitlab.suse.de/qa-sle/s-salt.git salt. Then I tested application of the salt state with salt-call --local -l error state.apply test=True and after that turned out to look good I applied the high state with salt-call --local -l error state.apply. From now on any changes to the salt repo will be automatically applied to the machine. Additionally we could add the machine to monitoring and auto-upgrade likely just by configuring the salt minion to connect to osd, same as we did on storage.qa and backup.qa. Should we do that?

Actions #7

Updated by okurz almost 3 years ago

  • Due date deleted (2022-03-08)
  • Status changed from Feedback to Resolved
Actions #8

Updated by nicksinger almost 3 years ago

I think this is a very good idea :)

Actions #9

Updated by okurz almost 3 years ago

  • Related to action #107731: Salt all SUSE QA machines, at least passwords and ssh keys and automatic upgrading size:M added
Actions

Also available in: Atom PDF