*In Progress NOT complete*
{section: Introduction}
This wiki page contains information about how to allow an administrator to schedule and manage services using HTCondor (IaaS).

{section: Configuration Options}

{subsection: 1.) Local Resources}

{subsubsection: Virtual Machine }
The most obvious solution to this problem now-a-days is to configure a virtual machine, or "appliance", whose sole purpose is to provide a service to a IT infrastructure.  This virtual machine can then be accessed and spun on demand

*:http://research.cs.wisc.edu/condor/manual/v7.7/2_11Virtual_Machine.html
*:http://research.cs.wisc.edu/condor/manual/v7.7/3_3Configuration.html#SECTION004329000000000000000

For these types of application it is relatively easy to configure a virtual machine with a hypervisor of your choosing and configure your appliance.  There are a couple of extra settings you may wish to add to your submission which will help in managing your appliances.

{code}
#############################
# Submission additions for services
#############################
# For resilient services where they can not go down
# logs should be routinely investigated for activity
on_exit_remove=false
periodic_release=true

# Any attributes which will be useful in administration
+HTTPD_IP=TARGET.MachineIP
{endcode}


{subsubsection: Chroot jobs}
Another way to achieve this is through the use of chroot jail.  By using your package management system you can install just the desired dependencies to a location which is idea for infrastructure.

*:http://prefetch.net/articles/yumchrootlinux

This solution has a couple of trade offs the administrator should take into account.  It does come with the added performance boost of being native but there are several configuration issues which need to be taken into account:

*: Consistent UID's into images (recommend using service ID's for consistency)
*: Firewall configurations.

Once your chroot image is created you will need to configure

{code}
##########################################
# Could be shared via NFS, or transferred
NAMED_CHROOT= httpd=/your/chroot/loc
{endcode}

Once your startd's have been configured you can run jobs.

{code}
executable=your_scriptwrapper_to_kick_httpd_in_chroot.sh
log=$(cluster).$(process).log.txt
output=$(cluster).$(process).out.txt
error=$(cluster).$(process).err.txt

should_transfer_files = YES
when_to_transfer_output = ON_EXIT

RequestMemory = 256M
+RequestedChroot="httpd"

queue 1
{endcode}

{subsection: 2.) Remote Resources}
{subsubsection: Grid/EC2 Jobs}

TODO: Update 7.7 series docs with ec2 refs.

{section: References}

*:http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/creating-loopback-s3-linux.html.html

Other refs:
*: http://lxc.sourceforge.net/