Bill Peck wrote:
CAI Qian wrote:
----- Bill Peck bpeck@redhat.com 写道:
Just sending this to the list to get feedback. If you remember from previous emails a recipe = a single system. a RecipeSet contains mutliple recipes that need to be scheduled at the same time. Also, we only want multi-host jobs to be scheduled on the same lab controller.
Why? I can think of scenarios that to pick up machines from different lab controllers are still valid
We have never supported this.
Right now all our lab controllers are on the same network. But when we allow a remote lab at some vendor they won't be able to talk to another sites systems.
Is there any piece of HW expensive enough and rarely used, it makes sense to workaround it in SW (scheduler)? There has to be!
Infrastructure workaround: concentrate all such special HW in one place. - CONS: failures during e.g. US bank holiday, will effect QE worldwide [ or poor mbrodeur will have to cancel holiday on Costa-Rica... ]
Proper SW solution:
What about adding another layer for network as a fallback, if single lab_controller can not be found? Or, in general, multiple layers - actually test-labs networks form a tree, or better a forest, with several isolated trees: Red Hat - US - BOS - RDU - ... - EUROPE - BRQ - STR
Vendor1 - ...
Vendor2 - ...
In multi-layer arch, scheduler should prefer minimal depth sub-tree meeting requirements. [ Although this could lead to over-using one lab, while similar infrastructure would be idle in other locations, at least it will not disable some legal tests completely. ]
An overkill?
-- Marian
- some systems are only in one lab controller like s390(x), but we also can have a flexibility to pick up other machines in some other labs.
This is an infrastructure issue.
- test how a server handling slow/link delay clients, which might be easier to pick up from some remote lab controllers.
I think this should be implemented with dedicated hardware for reproducibility. You can't rely on the network acting the same every time.
I agree it makes sense to be scheduled on the same lab controller by default, but should not eliminate the flexibility.
CAI Qian _______________________________________________ Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/beaker-devel
Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/beaker-devel