Xen, application servers and going forward

[Mike McGrath]

I'm working on getting our first production xen instance up and running 
for things like koji, smolt, bodhi and the package database.  Here are 
some guidelines I'd like to put on the wiki as well as some changes I'd 
like to make.


1) xen dom0 - RHEL5 (its just a black box, lets set it up and forget 
about it)
2) after we update our RHEL4 boxes to RHEL5 We will maintain two types 
of servers, RHEL5 and FC6 (this is because not all required packages are 
in EPEL, and ultimately the FC6 boxes will probably become FC7,8,9 
boxes.  I'd like to keep just two types so we can create an appa[1-9] 
and an appb[1-9].  I'd like to put appa and appb behind a vip that gets 
balanced 1-9 RR.  This will allow us to choose where we want to put our 
apps, stable environments vs cutting edge.
3) test and production xen guests will exist only on test and production 
xen hosts.  (basically no mixing of production and test).  Obviously 
emergencies are one thing but in general this is just for organizational 
purposes and because we may create a test network later and they won't 
be able to mix.
4) xen instances will be named by hostname.  Naming by purpose is 
getting confusing.
5) We will probably start mixing hardware.  Unlike before where we had 
builder hardware and app hardware, we'll be bluring this line as the 
need requires.  I plan on building out a few more wiki instances before 
the F7 release.
6) Kickstarts - I'm working on a xen-host and xen-guest kickstart 
script.  All of our boxes will be based off of one of these two scripts 
(they'll be sent to the list soon for examination / suggestions).  
Beyond that configuration will happen with puppet.  Note: puppet can 
pull in config files, install packages and restart services.
7) Monitoring - I'm working on a monitoring piece (basically a web page) 
that will list exactly what xen guests are running on what xen hosts, if 
they are pingable, etc.

What do you guys think?


    -Mike