Merging back cernvm and cloud_scheduler changes

Hey Henrik,

By your suggestion I tried rebasing my changes onto your master.  Unfortunately I merged (53bc7e9b5ad18841f0b77f426969f81c9bab4a95) some small changed from the cernvm branch just after forking my repository.  As a result I could not figure out how to rebase.  I realize that this makes this merge a bit messy and I will take more care to keep my repository in line with yours in the future.  Since my commit messages are very terse let me shed some more light on what happened in this merge.

cvmfs configuration
----------------------------
The changes in b17646ff650efc65bb5b7d9e0d1bc481f66f534c put the cvmfs serves in order, preferring the Canadian ones as well as adding some squid proxies.  We are working on this project [shoal] [1] shoal to dynamically assign squid caches to allow the VM configuration based on it's network connectivity to those caches.  The cvmfs cache size is necessary such that our VMs don't exceed their resource allocations.  Finally the grid software stack needs to be available

[1]: https://github.com/hep-gc/shoal   "Shoal"

cernvm configuration
-----------------------------
You'll notice a new module without much content at fae95030a0b805f8566dc56b7b06a0f63ebc5724.  CernVM has a configuration directory entirely independent from the configuration of cvmfs.  Right now this is a bare metal module configuring this CernVM for atlas use.  I will need to upgrade this when I get a chance to allow this the flexibility to configure the CernVM for other experiments as well.

condor configuration
-----------------------------
Here we are going to run into some problems because different clouds interact with VMs differently and cloud scheduler runs VMs on a couple of different cloud types.  First of all let me point out that condor needs some credentials to talk to the condor server, these are supplied as a hostkey and a hostcert written into the directory structure created by the grid-security manifest I added in f410b14ac5ccb45c1d45033a87f87786e5492c17.  These get written in during the VM boot, but that is only possible if the proper directory structure exists.  As it turns out it is this very same mechanism that also creates the cloud_type file we use for the fact a68170d9b3c65cdb375985cdbbfdfaf0535b478c.

The technicality of adding these files causes a chicken or the egg problem on OpenStack: the information is written by [context] [2] a service provided by the cloud scheduler.  When using puppet to install the service f64cef0cc2463d076c5b335b266299cabf3c57b9, facter can't determine the cloud_type since the context service has not yet run when puppet starts.  So I installed this service independently and removed the configuration from puppet at 9cb81778231ea85482d066fc0607297abb5f9f5c.  This will require some tweaking with the GCE, since their metadata server resides in a different location that on an OpenStack cloud,  Mike and I have started looking into this and would love to give things a whirl tomorrow.

[2]: https://github.com/hep-gc/cloud-scheduler/tree/dev/scripts/ec2contexthelper "context"

The last commit relevant to the condor configuration concerns how cloud scheduler contextualizes the condor central manager.  Once again this is done by the context service from the previous paragraph.  The fact created here e5a4317cb7984c19a519a4fe3928b3d7f7de61ef should be illuminating.

Network tuning
---------------------
The source for these runing parameters is [fasterdata] [3] This will likely be useful to other operating systems and any node that needs to push/pull a lot of data.  I added this configuration in 5807d2164bf8f4cbef2a104f958ffaa2d6ef67b2 then commented them out in d9805736ee2f48d6a9ce9f30595cedabf2b0f503.  You probably recall the email exchange we had ont he cernvm-talk email list.  Originally I had just pulled the [sysctl module] [4]  from thias'  github because the puppet version on CernVM did not support module installation. Then I followed your instructions to update puppet on the CernVM, removed the module I checked out from git and added it the puppet way, finally enabling it again later.

In closing, I'd like to apologize again for this ugly merge.  This is the first time I'm actually collaborating with someone using git/github so this is much of a learning process for me.  I will make sure to rebase future versions of my repo to yours more diligently.

Cheers,
-Frank

[3]: http://fasterdata.es.net/host-tuning/linux/ "linux tuning"
[4]: https://forge.puppetlabs.com/thias/sysctl "sysctl module"