Clarify when not to use multihost testing#4958
Conversation
Document that multihost testing is intended for scenarios where the provisioned guests need to communicate with each other (e.g. a server/client setup). For multi-environment testing where hosts run independently and do not need to talk to each other (for example running the same tests across multiple environments or architectures), users should create a **separate plan** per environment instead of using multihost testing. Fixes teemtee#4946 Assisted-by: Claude Code Signed-off-by: Miroslav Vadkerti <mvadkert@redhat.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a note to docs/guide.rst clarifying the appropriate use cases for multihost testing. Simplify the phrasing and use parentheses in the note to improve readability.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| If your guests do **not** need to talk to each other, for example | ||
| when you only want to run the same tests across multiple | ||
| environments or architectures independently, do **not** use | ||
| multihost testing. Create a **separate plan** for each environment |
There was a problem hiding this comment.
Use parentheses and simplify the phrasing to improve readability.
| If your guests do **not** need to talk to each other, for example | |
| when you only want to run the same tests across multiple | |
| environments or architectures independently, do **not** use | |
| multihost testing. Create a **separate plan** for each environment | |
| If your guests do **not** need to talk to each other (for example, | |
| when running the same tests across multiple environments or | |
| architectures independently), do **not** use multihost testing. | |
| Create a **separate plan** for each environment |
LecrisUT
left a comment
LecrisUT
left a comment
There was a problem hiding this comment.
Overall I do not think this is important to document on our side. It's an issue on how a user deployed, we offer advice and move on, we do not have to document each of these situations that individual users encounter.
| multihost testing. Create a **separate plan** for each environment | ||
| instead. This keeps the scenarios isolated, makes results easier to |
There was a problem hiding this comment.
This does not seem like a good design for the user to use. Testing-farm has explicit api to specify the architectures. It is better handled on that kind of layer rather then the user one, i.e. do not want the user to go through all of their plans to enable risc-v manually because that is how we recommended them to mange this.
There was a problem hiding this comment.
I disagree with the idea of creating separate plans - that is not needed, not even remotely, users do not have to create separate plans. They can and do have one plan and live happily. The key is to run the plan multiple times, for example with different context given to each invocation to adjust plans and tests for the given environment (namely architecture). That may be realized as a TF job with multiple architectures, or multiple tmt run commands locally, but it does not require creation of separate plans.
There was a problem hiding this comment.
@happz yeah, indeed, should not require create multiple plans. Will remove.
There was a problem hiding this comment.
Overall I do not think this is important to document on our side. It's an issue on how a user deployed, we offer advice and move on, we do not have to document each of these situations that individual users encounter.
Well, I do not agree it should not be documented, It should be documented so next time the user tries to do this we have some clear guidance and I can just point him to some FAQ or whatever
There was a problem hiding this comment.
Overall I do not think this is important to document on our side. It's an issue on how a user deployed, we offer advice and move on, we do not have to document each of these situations that individual users encounter.
Well, I do not agree it should not be documented, It should be documented so next time the user tries to do this we have some clear guidance and I can just point him to some FAQ or whatever
I do not like having lists of "do not do this" because there is an endless amount of things that we would be putting there. Positive guidance on how you could be using is more useful, but that is already covered in the current documentation, just in different wordings and less emphasis.
psss
changed the title
vaibhavdaren
added
the
ci | full test
|
/packit test |
Since its only documentation changes it makes a good candidate. |
6 participants
Document that multihost testing is intended for scenarios where the provisioned guests need to communicate with each other (e.g. a server/client setup).
For multi-environment testing where hosts run independently and do not need to talk to each other (for example running the same tests across multiple environments or architectures), users should create a separate plan per environment instead of using multihost testing.
Fixes #4946
Assisted-by: Claude Code
Pull Request Checklist