From Fedora Project Wiki

< User:Tflink

Revision as of 17:46, 8 November 2011 by Tflink (talk | contribs) (→‎System Design: adding system diagram)

tl;dr version

This is a proposal to create the minimum viable product for a system to allow for installation testing on remote machines without downloading installation images, creating virtual machines or having spare hardware.

Problem Space

With the coming UI rewrite for anaconda in Fedora 17, we need all the user testing we can get to help shake out bugs before release.

One of the barriers for users to test the UI is that they need to download a test .iso and either create a virtual machine locally or have hardware available for testing. While this is not a significant barrier to many testers, we would like to make the process easier for existing testers and possibly attract new testers who might not have otherwise participated in installation testing.

Time Frame

The initial function of this proposal is for graphical installation testing in Fedora 17. If we go forward with it, the system would need to be functional before Fedora 17 alpha testing is in full swing and hopefully around the time that the first testable builds of anaconda are available.

The initial working date would be to have an initial deployment before mid December, 2011.

Proposed Solution

This proposal is for a minimum viable product - just enough to work and to see if it would actually be used. Assuming that there is enough usage to justify continuing the project, features will be added at that time.

The basic idea is to spin up virtual machines with a Fedora installation iso and allow for installer testing through VNC that is routed through a web gateway. This VNC to HTML/js translation would be handled by guacamole.

Basic Use Case

  • User logs in to web interface
  • User selects image to test
  • Virtual Machine pointing to install iso is created and started
  • Guacamole link and login information are displayed to the user
  • User does installation testing
  • VM is rebooted following successful installation
  • User collects logs if needed
  • User indicates test completion through web interface
  • VM is destroyed

Minimum Viable Product

The minimum viable product would consist of:

  • Simple web interface
    • Apache or local db based auth
    • Locations of available installation media(manually entered)
  • Controller
    • Simple standalone system for running commands on the virt-host
    • Creates and destroys VMs on virt-host
  • Guacamole Server
    • Static, file based user mapping for username to vnc connection for a static number of VMs

System Design

ProposedRemoteInstallationSystem layout.png

The initial system would consist of 4 parts: web interface, controller, guacamole server and virt-capable hardware for creating the VMs.

Potential Future Features

Although this proposal is only for the Minimum Viable Product, the project could eventually be expanded beyond the simplistic interface and basic support for installer testing.

General

  • Support for other types of testing (desktop environments, other GUI apps)
  • Support for demonstrating fedora features
  • Cloud integration
    • While installation testing requires access to a raw virtual machine, other types of testing may not have that requirement. It would be possible to use the same system to coordinate the creation of cloud-based (public, private) test systems with a graphical interface

Web Interface

  • Administrative Interface to add available isos, admin VMs
  • Allow for multiple VM configuration types
  • Keep track of tests run and their status
  • Allow for access to logs created during installation
  • Link to RHBZ for failed tests
  • Better handling of timeouts if user doesn't indicate test completion
  • Better integration with guacamole

Controller

  • Use an existing cloud-ish platform instead of custom scripts
    • Aeolus, OpenStack, condor-cloud ...
  • Automatically extract logs from VM before destruction

Guacamole

While some of these potential features might be customization related, others would result in modified code and would involve working with upstream.

  • Write auth plugin to support non-static logins and passwords
  • Add buttons to the web UI to indicate test completion
  • Fedora themed login screen
  • Look at using JBoss AS instead of tomcat
  • Package guacamole and it's components in Fedora