[xen-tools] Argo reworking ..

[Steve Kemp]

  Over the past few months I've made various comments about Argo
 being dead, and depreciated pending a redesign/rewrite.

  Now its time to start working upon it in a serious manner.
  Here are my current thoughts, prior to writing any code.  Here
 is a good time to:
 
   - Tell me to use another list.
   - Help me pick a name.
   - Offer suggestions, criticisms, or other comments.
   - Volunteer to write some/all/part of the code.



Goal
----

  The goal of a Xen monitoring and admin solution is for an
 administrator to be able to gain a global view of a number of
 Xen hosts (dom0), and manipulate the Xen guests (domU) running 
 upon them.

  The individual guests should allow basic actions to be 
 carried out upon them:

         - starting, stopping, rebooting.
         - uptime reporting, traffic reporting, disk size reporting.

  More primitives could be added such as "migration", "remote consoles",
 etc.  However I can live without them initially/indefinitely.

  The key thing is that there should either be a graphical "admin console"
 or a web interface which may be executed anywhere within the LAN 
 talking to the Xen hosts.


Considerations
--------------

  The system must be able to control multiple dom0  so there must
 be some form of communication between the control panel and the
 actual servers.

  There are two ways this could work:

   a)  Each dom0 is contacted individually by the control panel/software.
       Pros:  Conceptually simple.
       Cons:  Could be hard to implement.

   b)  Each dom0 broadcasts to a "master server", which
      is in turn controlled by the control panel/software.
       Pros:  Each dom0 would be "registered" and lack of "pings" mean it is dead.
       Pros:  The control panel doesn't have to link to N hosts, just one.
       Cons:  Additional complexity.

  I think I'm sold on "b".


Security
--------


  Previously Argo used plain-text logins and a simple "plaintext"
 protocol for communication between a single dom0 and a console /
 GUI / PHP client.

  This was flawed.  Few people commented on implementation, however
 everybody that did do so complained about plain-text passwords.
 (I guess some might have been happy with MD5(passwd) but clearly
 security is important.)

  Since my current plan involves three pieces of software it is
 good to get the design right.  I see the following components
 communicating with each other:

   dom0 <-> central-server <-> control panel/software.

  That is:

   - Each dom0 will talk to the central server, giving status
     information and executing commands.

   - The central server will be the single point of contact for
     any graphical control applications, or a web GUI.
  
  I figure that two-way key exchange between the central server and
 the dom0 agents will be required.

  I also assume that the communication between the central server,
 and the control GUI will be SSL wrapped.


Implementation
--------------


  We require three things:

  1.  A piece of software upon each dom0 which will respond to commands
     from the central server.  Such as:
          - start domU foo
          - list domU
          - stop all domU

  2.  The central server itself.  This will respond to commands from the
     control panel such as:
          - list *all* domU, regardless of host.
          - list all domU on host bar.

  3.  The control panel / graphical management software.
          - login to the central server and do things.

  The first two pieces I'm expecting to implement as *tiny* Ruby
 daemons.  Almost certainly sending and receiving their commands
 over XML::RPC (+SSL).

  The control panel could be implemented in anything, but my preference
 would be perl + gtk, or something else "fast" and graphical.  A web
 control panel might be released as a proof of concept, but I am 
 personally uninterested in its development.


Steve
-- 
http://www.steve.org.uk/