Bill Peck wrote:
CAI Qian wrote:
> ----- Bill Peck <bpeck(a)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(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/beaker-devel
>
>
_______________________________________________
Beaker-devel mailing list
Beaker-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/beaker-devel