Project

General

Profile

Actions
Copy link

action #90629

closed

openQA Project - coordination #64746: [saga][epic] Scale up: Efficient handling of large storage to be able to run current tests efficiently but keep big archives of old results

openQA Project - coordination #80546: [epic] Scale up: Enable to store more results

administration of the new "Storage Server"

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

Status:
Resolved
Priority:
Normal
Assignee:
nicksinger
Category:
-
Target version:
openQA Project - Ready
Start date:
2020-08-04
Due date:
% Done:

0%

Estimated time:

Description

Observation

If I read the information from #69577 and #66709 correctly then the machine "storage.qa.suse.de" calls itself "f189" and it's IPMI interface is "d87.suse.de" and https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/openqa/workerconf.sls#L990 mentions credentials but as specified these can not be parsed into IPMI aliases according to https://gitlab.suse.de/openqa/salt-pillars-openqa#get-ipmi-definition-aliases

Acceptance criteria

  • AC1: hostname of storage.qa.suse.de is correct
  • AC2: IPMI interface follows convention, e.g. storage-ipmi.qa.suse.de or storage-ipmi.suse.de?
  • AC3: IPMI command line can be parsed into ipmi definition alias in salt pillars repo

Related issues 3 (0 open — 3 closed)

Related to openQA Infrastructure - action #90746: OSD deployment fails at 2021-04-07 because 'storage.qa.suse.de: Minion did not return'Resolvedokurz2021-04-072021-04-21

Actions
Related to openQA Infrastructure - action #93683: osd-deployment failed due to storage.qa.suse.de not reachable by saltResolvednicksinger2021-06-09

Actions
Copied from openQA Infrastructure - action #69577: Handle installation of the new "Storage Server"Resolvednicksinger2020-08-04

Actions
Actions
Copy link
 #1

Updated by okurz over 3 years ago

  • Copied from action #69577: Handle installation of the new "Storage Server" added
Actions
Copy link
 #2

Updated by okurz over 3 years ago

  • Related to action #90746: OSD deployment fails at 2021-04-07 because 'storage.qa.suse.de: Minion did not return' added
Actions
Copy link
 #3

Updated by Xiaojing_liu over 3 years ago

Could we change the ipmi interface d87.suse.de to storage-ipmi.qa.suse.de by following https://confluence.suse.com/pages/viewpage.action?spaceKey=enginfra&title=How+to+change+DHCP+and+DNS+records

Actions
Copy link
 #4

Updated by nicksinger over 3 years ago

  • Status changed from Workable to In Progress
  • Assignee set to nicksinger
Actions
Copy link
 #5

Updated by nicksinger over 3 years ago

AC1:

storage:~ # hostnamectl status 
   Static hostname: storage
         Icon name: computer-server
           Chassis: server
        Machine ID: 210f7364a478411499e4ccd3763028ae
           Boot ID: ae1d205ce5474987bb7f550c3ec3202c
  Operating System: openSUSE Leap 15.3 Alpha
       CPE OS Name: cpe:/o:opensuse:leap:15.3
            Kernel: Linux 5.3.18-40-default
      Architecture: x86-64

AC2: https://gitlab.suse.de/qa-sle/qanet-configs/-/commit/a3f5821e75d44350a6313740c2d53e2970d1250e
AC3: https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/304

Actions
Copy link
 #6

Updated by nicksinger over 3 years ago

  • Status changed from In Progress to Feedback
Actions
Copy link
 #7

Updated by nicksinger over 3 years ago

  • Status changed from Feedback to Resolved
Actions
Copy link
 #8

Updated by okurz over 3 years ago

  • Status changed from Resolved to Feedback

something seems to have been lost again hostnamectl status returns a static hostname of f189

Actions
Copy link
 #9

Updated by okurz over 3 years ago

another thing, because the installation is Leap 15.3 Alpha the auto-upgrade job does not seem to be able to do anything useful as we would need zypper dup, not only patches.

Actions
Copy link
 #10

Updated by nicksinger over 3 years ago

  • Assignee changed from nicksinger to okurz

Huh, forget to update the status here. Last time I did a manual zypper dup bringing the machine to 15.3 Beta. Before rebooting I changed DHCLIENT_SET_HOSTNAME="no" and DHCLIENT6_SET_HOSTNAME="no" in /etc/sysconfig/network/dhcp to avoid the hostname change. After rebooting to apply the updates we had a temporary hostname again. So I asked in #wicked (https://chat.suse.de/channel/wicked?msg=QK7yM8AgufjFwcCju) but unfortunately got no answer. Today I did another zypper dup and reboot. This time the machine remembered its hostname. So maybe this was a bug last time or I messed hostnamectl up. So I think we're good here in regards of the hostname.

@okurz: the machine is now on Leap15.3 (according to /etc/os-release no Alpha, no Beta - according to https://www.opensuse.org/ it is RC). Do you think from now on the automatic updates will apply without dup? Or do we have to do another dup from RC to Release?

Actions
Copy link
 #11

Updated by okurz over 3 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from okurz to nicksinger

nicksinger wrote:

@okurz: the machine is now on Leap15.3 (according to /etc/os-release no Alpha, no Beta - according to https://www.opensuse.org/ it is RC). Do you think from now on the automatic updates will apply without dup? Or do we have to do another dup from RC to Release?

The latter. I would expect RC not staying the last build. I assume latest when we update all machines to 15.4 we will find the machine again to consolidate :D

I could verify that the hostname is fine and reboot-safe, so thanks! and resolved :)

Actions
Copy link
 #12

Updated by okurz over 3 years ago

  • Related to action #93683: osd-deployment failed due to storage.qa.suse.de not reachable by salt added
Actions
Copy link

Also available in: Atom PDF