Author Archives: chmouel

Swift and quotas in upcoming 1.8.0 (Grizzly) release.

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.

The commit for the container quotas is here :

Basic container quotas

and account quotas commit :

Account quotas

Enjoy.

 

emacs anything with magit

I have been using quite a bit the anything-mode for Emacs, it’s basically a Quicksilver/Alfred or Gnome-do for Emacs and allow to configure a lot of different sources to complete some chosen ‘source’with different actions.

With my work on OpenStack I have found myself jumping a lot between git directories and due configured the variable ‘magit-repo-dirs for easy access to most of them easily.

Plugging those two just seemed natural I had already this in my emacs to quickly open those magit repository directories :

(global-set-key (read-kbd-macro "C-S-o") '(lambda ()(interactive) (dired (magit-read-top-dir nil))))

But going with anything is much nicer and I can add another action for openning the source to  magit so I quickly came up with this magit source :

so now I open my different OpenStack Swift projects quickly with only a few keyboard touch (I bind my custom anything function to C-z) which shows graphically like this :

anything switch to magit dirs.

as always my full emacs config is available here:

http://github.com/chmouel/emacs-config

Upload to OpenStack Swift via CORS/HTML5 request.

One of our client at eNovance had a need to be able to upload to Swift directly from a web browser without going via a PHP proxy.

Things in browser-land are not exactly the same as what we have in user-land, it is a bit more restricted to ensure the end-user security and there is a few hoops to jump through to get it working.

To be able to do a xmlrpc upload to another server (swift in this case) there is a ‘standard/recommendation’ document made by W3C about it located here :

http://www.w3.org/TR/2013/CR-cors-20130129/

Basically what happen when in Javascript we do :

request.open("POST", "http://swift/AUTH_account/container/");
request.setRequestHeader('X-Auth-Token', myToken);
request.send();

The browser just before the request will send an OPTIONS request to check with the server if the request is allowed by the server. This look like this when uploading to Swift :

Screen Shot 2013-02-01 at 12.29.50

The Options request that the browser does is literally asking for the server (swift) to know if this domain where it’s uploading from is allowed to upload directly via xmlrpc. The request looks like this :

Screen Shot 2013-02-01 at 12.39.50It says, hello there: my Origin: is this IP and I want to be able to access with this method ‘PUT’, can I do it ? The server will reply something along (if it’s allowed), yeah sure please feel free to send this headers along and those methods and Origin are actually what I am allowing.

Thanks to the work of Adrian Smith this is supported since Swift version 1.7.5 (and improved in 1.7.6), you can do  at server level config or with headers on container easily see the full detailled documentation here:

http://docs.openstack.org/developer/swift/cors.html

While working on this I could not find a clear example to test it, I only found a great article on this page :

http://www.ioncannon.net/programming/1539/direct-browser-uploading-amazon-s3-cors-fileapi-xhr2-and-signed-puts/

that was targetted to amazon s3 and I adapted it to use with OpenStack Swift.

You can find it here and use it as an example for your application :

https://github.com/chmouel/cors-swift-example

My running and cycling stats of 2012

And here is another year finishing and I am looking back how did I do with my fitness.

I have not done well with regard to my class A running race, I wasn’t able to make to the Jerusalem marathon due of passport problem of my kid and had to easy my running due of a bad ankle since February, but I still did a 1h32 half marathon by March and a 1h38 in L.A in Septembre, just in time to hit over 1000km by this year :

  Running stats 2012

I have instead did much more cycling finishing a easy sportive in wales of 130km and a pretty hard one in south of france of 160km with a lot of mountains climbed. I made it to 5000Km (for my racing bike not counting my city bike which has around 500km on it) :

Cycling Stats 2012

I would have done much more if I didn’t have a bad upper shine when I was in australia where I was going to do a month of cycling.

This year looks promising with the Madrid Marathon in april (going for around 3h20) and probably some pretty good cycling trips during the summer if shin/ankle get sorted, I am looking forward to 2013.

Emacs and nosetests

Sometime you just need a long trans atlantic flight and a stupidly long stop-over in a random city to do some of those task that can improve your day to day but you never take some time to do it.

When using emacs I wanted a simple way to launch a nosetests on the current function my cursor is in Emacs. The syntax on nosetests is a bit tricky and I actually always have to look at my shell history to know the proper syntax (nosetests directory/filename.py:Class.function).

I created a simple wrapper for emacs for  that which allow to just hit a key to copy the nosetests command to feed to your shell or to use it for the compile buffer.

It’s available from here :

https://github.com/chmouel/emacs-config/blob/master/modes/nosetests.el

I have binded those keys for my python mode hook :

(local-set-key (kbd "C-S-t") 'nosetests-copy-shell-comand)
(local-set-key (kbd "C-S-r") 'nosetests-compile)

Happy TDD!!!!

UPDATE: There was an another nose mode already that does much more available here : https://bitbucket.org/durin42/nosemacs/

Using python-novaclient against Rackspace Cloud next generation (powered by OpenStack)

With the modular auth plugin system merged into python-novaclient it is now very easy to use nova CLI against the Rackspace Public Cloud powered by OpenStack.

we even have a metapackage that would install all the needed bits. This should be easy as doing this :

pip install rackspace-novaclient

and all dependencies and extensions will be installed. To actually use the CLI you just need to specify the right arguments (or via env variable see nova –help) like this :

nova –os_auth_system rackspace –os_username $USER –os_tenant_name $USER –os_password $KEY

on RAX cloud, usually the username is the tenant name so this should match.

For the UK Cloud you just need to change the auth_system to rackspace_uk like this :

nova –os_auth_system rackspace_uk –os_username $USER –os_tenant_name $USER –os_password $KEY

swift.common.client library and swift CLI has moved to its own project

Historically if you wanted to write software in python against OpenStack swift, people would have use the python-cloudfiles library or swift.common.client shipped with Swift.

python-cloudfiles was made mostly for Rackspace CloudFiles before even Swift existed and does a lot of extra stuff not needed for OpenStack Swift (i.e: CDN).

swift.common.client was designed for OpenStack Swift from the ground up but is included with Swift which made people having to download the full Swift repository if they wanted to use or tests against it. (i.e: OpenStack glance).

As yesterday we have now removed swift.common.client wth the bin/swift CLI and moved it to its own repository available here :

https://github.com/openstack/python-swiftclient

This should be compatible with swift.common.client with only difference being to import swiftclient instead of importing swift.common.client

At this time we are using the same launchpad project as swift so feel free to send bugs/feature request under the swift  project in launchpad :

https://bugs.launchpad.net/swift/+filebug

and add the tag python-swiftclient there.

S3 emulation to OpenStack Swift has moved

A little note about swift3 the S3 emulation layer to OpenStack Swift

As from this review we have removed it from Swift since the decision[1] was made that only the official OpenStack API would be supported in Swift. The development will be continued in fujita’s repository on github at this URL :

https://github.com/fujita/swift3

Feel free to grab the middle-ware or report issue from fujita’s repository.

[1] Globally for OpenStack not just for Swift.