Random and probably boring stuff from me.

Cloud

There is two new nifty middlewares for doing quotas in upcoming Swift release 1.8.0 called container_quotas and account_quotas.

Those are two different middlewares because they are actually addressing different use cases.

container_quotas is typically used by end users the use case here is to let user to specify a limit on one of their container.

Why would you want to restrict yourself you may ask ? This is because when you allow a public upload to a container for example with tempurl or/and formpost you want to make sure people are not uploading a unlimited amount of datas.

The headers to configure for the container quota are :

X-Container-Meta-Quota-Bytes – The Maximum size of the container, in bytes.X-Container-Meta-Quota-Count – Maximum object count of the

The account_quotas is more the typical quota implementation. A “super
user” with the reselleradmin group/role can set a byte limit for
an account and the account will not be able to have new
objects/containers until someone cleanups his account to get under the
limited quotas.

The headers to configure the account quotas are :

X-Account-Meta-Quota-Bytes – The Maximum size of the account in bytes.

Currently in Rackspace-Cloud when you are shutting-down your Cloud Servers you are still paying for it.

The reason is that when the Cloud Server is shut-down your CloudServer is still sitting on the hyper-visor and still use resources on the Cloud and then get you billed for it.

There is a way to get around it by having the CloudServer stored as an image into CloudFiles.

The caveat with this solution is that every-time you are creating a server out of the stored image you are getting a new IP and in certain cases you would need to make a change in your application with the new IP.

If you only use domain names instead of IP in your application you are not dependent of the IP change, to update the domain with the new IP after creating the VM you can either :

– Have a dynamic DNS or ‘Cloud DNS’ updated just after you created your server out of the image.

– Have a script going into your server and update the IP directly in /etc/hosts.

In programming words this is the steps you would do. I am using the python-nova binding which allow you to connect to RackSpace Cloud.

At first I am going to create an object which we are going to authenticate

cx is going to be the object from where we can do things on it. Let’s first find the server server that we want, assuming your server is called test you would get the server like this :

server = cx.servers.find(name='test')

The variable ‘server’ contain our server ‘object’ and we can get its ID out of it :

server_id = server.id

We got the function cx.images.create to create an image from a server which accept as first argument the image name and the second the server id we just got. this would start the creation of the image :

cx.images.create("backup_server", server_id)

The server has started to get backed-up into your Cloud Files account, you can see it directly into the “My Server Images” tab of Hosting => Cloud Servers section :

You can now delete the server since it’s ‘backuped’ into cloud files ;

server.delete()

At this time you are not billed for your Cloud Servers anymore and only for the storage usage in Cloud Files.

When you want to restore the image as a server, you would first get the id of your image :

image = cx.images.find(name='backup-test')
image_id = image.id

and create the server out of this image :

CNX.servers.create(image=image_id,
flavor=1,
name="test",
)

The flavor argument is the type of image you want, 1 the minimal 256M flavor. The full list is :

When the server has created it should be exactly the same as what you have before created in image. You can now run a script using SSH with SSH keys to log into servers and do adjustment with the new IP.

Sometime ago I wrote a FTP proxy to RackSpace Cloud Files which expose Rackspace Cloud Files as a FTP server acting as a proxy.

Thanks to the OpenSource community a user on github took it and add support OpenStack and all the latest features available in Cloud Files.

It is now pretty robust and works pretty well via nautilus even with the pseudo hierarchical folder feature. The fun part here is that it allow you to effectively have a Cloud Drive where you can easily store your files/backup from your Linux desktop via nautilus built-in ftp support.

One of the last library I didn’t documented in my earlier post was php-cloudfiles. You need to have at least the version 1.7.6 released to have support to different auth_server and when you have that you can do it like this to get access to cloud files via the library :

It seems that my post about using duplicity to backup your data on Rackspace CloudFiles got popular and people may be interested to use with the newly (Beta) released Rackspace Cloud UK. You would just need to have a environnement exported at the top of your backup script like this :

Check the documentation of your Operating System to install python-cloudfiles, usually it is very easy to do it via pip (pip install python-cloudfiles)

When you have installed duplicity and checkout the script (see the github page for documentation how to do it) you can start configuring it.

At the top there is a detailled explanation of the different variables that need to be configured. You can change it in the script or you can have them configured in an external configuration file in your home directory called ~/.dt-cf-backup.conf, this is an example :