action #33697
closed[tools][hard][pvm] Enable the powerVM backend to conduct multimachine tests
0%
Description
In poo#21838 the need for multimachine tests on PowerVM was mentioned.
To cite coolo on what needs to be done:
I don't think there is inherit problem - but you would need to undo a lot of qemu specific hardcoding. But you can create vlans for the lpars and then have PARALLEL_WITH 2 lpars.
AC1: Multimachine tests can run on PowerVM
AC1.1: Implement vland handling for LPARs
AC1.2: Find all qemu hardcodings and adapt the backend to do MM tests on other backends
Suggestion¶
Configure vlans between the lpars and treat them as machines in the network with a proper worker class (see coolo's comment)
Updated by nicksinger almost 7 years ago
- Copied from action #33388: [functional][u][easy][pvm] Implement proper split from other backends added
Updated by nicksinger almost 7 years ago
- Copied from deleted (action #33388: [functional][u][easy][pvm] Implement proper split from other backends)
Updated by nicksinger almost 7 years ago
- Follows coordination #21838: [functional][u][saga] PowerVM backend added
Updated by coolo almost 7 years ago
- Project changed from openQA Project (public) to openQA Tests (public)
- Subject changed from [tools][functional][hard][pvm] Enable the powerVM backend to conduct multimachine tests to [functional][hard][pvm] Enable the powerVM backend to conduct multimachine tests
- Category deleted (
132)
I claim we don't do anything about it - and handle powervm lpars just like phyiscal machines in our network. They are there and if they can be used for MM tests is defined by worker class. If the admins setup a proper vlan or not is up to the tests writers.
Updated by okurz almost 7 years ago
- Subject changed from [functional][hard][pvm] Enable the powerVM backend to conduct multimachine tests to [functional][u][hard][pvm] Enable the powerVM backend to conduct multimachine tests
- Target version set to Milestone 21+
- Difficulty set to hard
Updated by okurz over 6 years ago
- Start date changed from 2017-08-09 to 2018-08-29
due to changes in a related task
Updated by okurz over 6 years ago
- Start date changed from 2018-08-29 to 2018-08-01
due to changes in a related task
Updated by okurz over 6 years ago
- Target version changed from Milestone 21+ to Milestone 21+
Updated by okurz over 6 years ago
- Related to action #37372: [tools][pvm] powerVM production worker added
Updated by okurz over 6 years ago
- Target version changed from Milestone 21+ to Milestone 23
I see this only happening after #37372 and even then I doubt that qsf-u has the capacity to work on this within the early milestones of M21 so a bit later
Updated by okurz over 6 years ago
- Priority changed from Normal to Low
- Target version changed from Milestone 23 to Milestone 26
If I understood QA-CSS correctly they plan similar work and want to have it but do not yet have a ticket or similar so not that important or urgent. Therefore delaying.
Updated by okurz almost 6 years ago
- Target version changed from Milestone 26 to future
putting to "holding tank" :)
Updated by szarate almost 5 years ago
- Description updated (diff)
- Assignee set to mgriessmeier
Updated by SLindoMansilla almost 5 years ago
- Assignee changed from mgriessmeier to SLindoMansilla
As PO I will be in touch with PowerVM enablement
Updated by szarate almost 5 years ago
- Project changed from openQA Tests (public) to openQA Project (public)
- Subject changed from [functional][u][hard][pvm] Enable the powerVM backend to conduct multimachine tests to [tools][hard][pvm] Enable the powerVM backend to conduct multimachine tests
- Category changed from New test to Feature requests
I think this belongs more in the openQA project
Updated by okurz over 4 years ago
@szarate I missed that you assigned this ticket to "[tools]" as you kept slindomansilla as assignee. IMHO the comment from #33697#note-4 is still valid and there are no plans by the QA tools team to do more implementation about this. However considering that our powerVM backends can be treated just the same as bare metal IMHO we have a solution already: Tests can be triggered in parallel with no problem and synchronization primitives can be used. As the network can not be fully virtual of course then the network admin needs to ensure according separation where needed. What we can do is maybe mention this explicitly in documentation.
Updated by okurz over 4 years ago
- Status changed from New to Feedback
- Assignee changed from SLindoMansilla to okurz
Trying to clarify in documentation what can be done / needs to be done: https://github.com/os-autoinst/openQA/pull/3256
It's not that much though but I consider it's what we can do, the rest is for test maintainers to show what's possible and tell the network admin what's missing :)
Updated by okurz over 4 years ago
- Status changed from Feedback to Resolved