Summer of Code and Projects around Wine

[Francois Gouget]

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).


-- 
Francois Gouget <fgouget at free.fr>              http://fgouget.free.fr/
                     Linux: the choice of a GNU generation