So I'll hijack this thread a bit...
Would a GSOC project to improve the TestBot make sense / fit into the GSOC mandate? Like some other proposals it would not be on the Wine codebase but still the Wine infrastructure.
Here are some ideas:
* Javascript-ification of the site The goal would be to avoid reloading pages all the time. - A prime target would be the job details page which reloads every time one shows / hides a log or a screenshot. Screenshots would be easy. The interesting part would be to have the website provide an API to retrieve the logs which the JavaScript code would then insert in the right place. - Another target could be the main page. Instead of reloading all of it JavaScript could use an API to retrieve just the updates and refresh the page accordingly. - The job submit page could also benefit from this.
* Swap TestBot's Object Relational Mapper - The TestBot uses its own Perl ORM implementation which has a lot of issues: https://bugs.winehq.org/show_bug.cgi?id=45023 - These issues were quite troublesome at some point but the TestBot code works around them and they are not hindering the kind current development. So replacing the ORM is low priority now. However performance is pretty bad. My feeling is that it's an order of magnitude slower than it should. See for instance the load times for the home and activity pages. - So swapping it for an ORM we don't have to maintain would be nice. I don't know if it would fit for a GSOC though. There's one part which is figuring out if there's a way to implement the old API on top of the new one to ease the transition. That would probably be a good fit for part of a GSOC. The second part is switching the code to the new API and which may be repetitive and not particularly educational. - Also if reimplementing the old API on top of the new one is not possible it the only way to test and perform the switch may be with one big commit that changes everything :-(
* Implement load balancing and failover https://bugs.winehq.org/show_bug.cgi?id=39412 This implies: - Adding a middle layer between tasks and the VM configurations they are supposed to run on. - Modifying the database schema to represent the VM exclusions: - If the w1064 VM has French and English configurations only one instance can be run at a time because both are in the same VM. - For most VMs we only have a single OS license so only one instance must run at a time even if the VM is present on two hosts. For others (e.g. Debian) we could allow more than one instance to run at a time. (use IP addresses as a proxy for license counts?) - Update the code that depends on the above changes (essentially everything). - Update the task scheduler to take into account all these constraints. That may be too much for a GSOC though.
* Research VM isolation and resource allocation The goal would be to be able to run multiple VMs simultaneously without having one VM interfere with the timing of the tests in another VM. Once it works it opens up a number of issues though: - Core pinning seems like it would be required. Then how do we allocate cores to VMs? Can we make it so the TestBot runs 4 2-core Windows VMs while the Debian VM that normally gets 8 cores is powered off? Or is that so complex that only a static core allocation is workable? (it would certainly be better than the current scheme anyway) - How do we make it so the TestBot does not start two VMs that need the same PCI-passthrough graphics card at the same time? Note that this is probably closely related to the exclusion mechanism for the failover project above. - Can we assume that the number of cores will always be the limiting factor or should we add memory constraints? The TestBot hardware may not be ready for this type of work in time for this year's GSOC though, and it may be hard for a student to get hold of a beefy enough system to meaningfully test these issues (or to work on them remotely).