Project

General

Profile

action #51836

Manage (parts) of s390p7 and s390p8 with salt

Added by nicksinger about 2 years ago. Updated 10 months ago.

Status:
Feedback
Priority:
Normal
Assignee:
Target version:
Start date:
2019-05-22
Due date:
% Done:

0%

Estimated time:

Description

Recent example: s390p8 ran out of space because the openQA worker don't depend/wait for the mount of a separate FCP storage disk. This could be avoided by deploying a machine specific openqa-worker unit override (similar to the auto-format on aarch64 workers). To manage these kind of specialties and to uniform our setup it would make sense to include these two hosts into our openQA salt.


Related issues

Related to openQA Infrastructure - action #51833: [tools][functional][u] s390p8 is out-of-space in /Resolved2019-05-22

History

#1 Updated by nicksinger about 2 years ago

  • Copied from action #51833: [tools][functional][u] s390p8 is out-of-space in / added

#2 Updated by nicksinger about 2 years ago

  • Copied from deleted (action #51833: [tools][functional][u] s390p8 is out-of-space in /)

#3 Updated by nicksinger about 2 years ago

  • Related to action #51833: [tools][functional][u] s390p8 is out-of-space in / added

#4 Updated by szarate about 2 years ago

  • Subject changed from [tools][functional][u] Manage (parts) of s390p7 and s390p8 with salt to [tools] Manage (parts) of s390p7 and s390p8 with salt

This does not belong on the [u] team :) At least from a brief chat with Matthias

#5 Updated by okurz 12 months ago

  • Subject changed from [tools] Manage (parts) of s390p7 and s390p8 with salt to Manage (parts) of s390p7 and s390p8 with salt
  • Status changed from New to Feedback
  • Assignee set to mgriessmeier
  • Priority changed from High to Normal
  • Target version set to Ready

szarate wrote:

This does not belong on the [u] team :) At least from a brief chat with Matthias

Doesn't belong to "[tools]" either according to https://progress.opensuse.org/projects/qa/wiki/Wiki#Out-of-scope

mgriessmeier I think you can help clarify responsibilities here as:

  • I understand that QSF-u wants to have less responsibilities with infrastructure
  • You are still an expert in this topic but also in a different position where you can better clarify responsibilities

But please also keep in mind the recently more limited capacity of https://confluence.suse.com/display/openqa/openQA#openQA-Team

#6 Updated by mgriessmeier 12 months ago

hey,

so I can understand both of your sides - and yeah, one can probably argue if this is "Administration of workers" or "maintenance of workers".
but since this is lying around for such a long time, it seems that apparently the annoyance of this not being done is not high enough (yet).

I don't see a crystal-clear responsibility for that task here, so what about the following proposal:
do a joint collaboration between QSF and Tools team - sit down for few hours and do this thing together? I'm happy to help here of course =)

#7 Updated by okurz 12 months ago

mgriessmeier wrote:

since this is lying around for such a long time, it seems that apparently the annoyance of this not being done is not high enough (yet).

Yes, I think so. This is why I lowered from "High" to "Normal" priority.

I don't see a crystal-clear responsibility for that task here, so what about the following proposal:
do a joint collaboration between QSF and Tools team - sit down for few hours and do this thing together? I'm happy to help here of course =)

Well of course everybody is happy to offer help but this task lying around for more than a year already shows that this is not problem. Just an outlook into the future if nothing is done here: Eventually the machines will break down or need to be replaced (again) and everybody will just point to mgriessmeier who should know best ;)

#8 Updated by okurz 10 months ago

  • Target version changed from Ready to future

I am trying to make it more obvious that with the current team's capacity and capabilities this is unlikely to be worked on by SUSE QA Tools hence setting the target version accordingly to "future".

mgriessmeier considering that we just had problems with s390pb these days (I think even twice) I suggest to consider this issue more important to save confusion and therefore cost and confusion in the future again.

Also available in: Atom PDF