Merge lp://staging/~chad.smith/landscape-client/swift-device-monitoring into lp://staging/~landscape/landscape-client/trunk

Add separate swift-device-info plugin as a monitor plugin which will read any available swift ring files and pull swift device information from curl to the discovered local swift-recon sevice at http://<local_ip>:<swift_service_port>/recon/diskusage.

Once swift devices are discovered, send this info back to the landscape-server which will process the new swift-device-info messages.

The provider is disabled and logs entered if:
- swift config files don't exist on the server
- no local swift recon service is advertised or running

At long last...

This branch now separates swift-storage device awareness into a separate plugin from the MountInfo plugin. Submitted for review again because we have now separated all swift-related info into separate classes and tests and there was a bit of rework necessary to persist swift_device_info.

There is a new message introduced with the following schema defining all associated swift devices and whether or not they are actively mounted in the swift cluster.

SWIFT_DEVICE_INFO = Message("swift-device-info", {
    "swift-device-info": List(KeyDict({"device": utf8, "mounted": Bool()}))
    })

  The plugin determines whether or not it needs to run by checking to see if /etc/swift/object-server.conf exists on the system.

If we determine we are running on a swift storage node, we use openstack's swift.common.Ring lib to parse a ring file to determine which service ports are active on the local node.

Then we attempt to curl against http://<local_ip>:<service_port>/recon/diskusage which tells us what mounted devices are affiliated with swift. For example:

curl -i http://10.55.63.71:6000/recon/diskusage
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 194
Date: Tue, 22 Jan 2013 21:45:07 GMT

[{"device": "loop0", "avail": 3176972288, "mounted": true, "used": 33767424, "size": 3210739712}, {"device": "loop1", "avail": 2103230464, "mounted": true, "used": 33767424, "size": 2136997888}]

There are probably better ways to test this, but I run Jerry's server branch locally to ensure landscape server could process the new client 'mount-info'... 'designated-service' messages.

Then you can build landscape-client; cd src/landscape-client/your-branch; make package;

and scp the debs to you vm instance, pointing /etc/landscape/client.conf back at your public IP address where the server is running, wait about 10 mins and you should see updated mount_info and free_space tracking of available MB of storage on the devices.

Jerry's branch for reference: https://code.launchpad.net/~jseutter/landscape/swift-storage-2