OpenStack has had a global reach since the early days but the Design Summits have always been a US-based affair. Last week we finally took the every-six-month roadshow off-continent and ventured out to Hong Kong. Of course the Conference is co-located and concurrent but I didn't make it to any of those sessions this time and only knew it was there by going to lunch in the expo hall and seeing some familiar vendor faces. We begin with the projects most subject to my attention, DevStack, Grenade and OpenStackClient. DevStack This is the first summit where DevStack has program status

Update! Update! Update! A while back I started documenting the image build process I've been using for building OpenStack cloud images: A Fedora 18 Image for OpenStack A CentOS 6 Image for OpenStack Note that Ubuntu is missing from that list, due mostly to their published UEC images being generally good enough as a starting point. Fedora 19 finally has a similar image published, let's see how different it is and if it is useful for my purposed... Also, all of these images have rng-tools added as it is useful on clouds that provide a usable virtualized /dev/random in their

[Updated 10 Oct 2013 to reflect the released state of ``local.conf``] DevStack has long had an extremely simple mechanism to add arbitrary configuration entries to nova.conf, EXTRA_OPTS. It was handy and even duplicated in the Neutron configuration in a number of places. However, it did not scale well: a new variable and expansion loop is required for each file/section combination. And now the time has come for a replacement... Requirements localrc has served well in its capacity of the sole container of local configuration. Being a single file makes it easy to track and share known working DevStack configurations. Any

Updated 06Nov2014: I've updated my thoughts on the layers to take into account both things I learned since this was originally written. OpenStack is, as it name implies, a stack of services to provide "components for a cloud infrastructure solution". [1] There are layers of services, some interdependent on each other, some only dependent on the layers below it. For some time there has been a PC dance around 'labelling' projects that may or may not be at a layer that it wants to be in. Back in the day, the term 'core' was thrown around to identify the services

OpenStack Client Projects The developers of OpenStack maintain a series of library projects which are the Python interfaces to the OpenStack REST APIs and also include command-line clients: python-ceilometerclient python-cinderclient python-glanceclient python-heatclient python-keystoneclient python-novaclient python-quantumclient python-swiftclient Each project is managed through the same development process as the integrated OpenStack projects so you can expect to find the latest source on GitHub. The master branch in the project repositories should theoretically never be 'broken,' but realistically they are not tested between releases with the same vigor as the core projects. The bug and feature tracking happens on Launchpad; each of the