Configuring DevStack for development use is a trail of Google searches and devstack.org reading and all sorts of things. In my experience, the best and hardest source of what to do is experience. And we all know how experience is the bridge between Bad Judgement and Good Judgement.[] local.conf This is DevStack's configuration file. It will never be modified by DevStack. localrc Now just a section in local.conf, localrc used to be the main config file. References to it should be mentally translated to local.conf [[local|localrc]] section. I also tend to carry a number of config bits commented out to

One of the coolest (IMHO) new features [1] recently added to OpenStackClient is its leveraging of a new-ish feature of Keystone's client library, authentication plugins. As that name implies, this allows for Keystone client to be able to use an extendable set of authentication backends for validating users. At press time (keypress time for the pedantic) the freshly released python-keystoneclient 0.11.2 includes the traditional password method, a new variant on the token method and a recent addition supporting SAML2. Happily, the master branch of OpenStackClient has learned how to take advantage of these plugins, plus any additional ones written for

OpenStack Terms and You I think we need to start from the beginning to know a bit about where we really are...and to do that we need to speak the same language. This doesn't mean we must agree on the actual terms used, but that their definition and evidence of need are spelled out and can inform the following steps and discussion. In some cases, the bikeshed will simply be in primer with placeholders until we converge an appropriate terms. The Technical Committee Charter refers to some terms that should be clarified early in this process. Official Programs - The

So back in the old days I started throwing around different terminology to describe some of the technical relationships between OpenStack projects because it was useful to sort out things like startup order requirements in DevStack and other semi-obvious stuff. And wow have things happened since then. To recap, oh nevermind, I'm just going to take back the term layer for technical use and propose anything else other than layer 1 (there is no other layer?) for the rest of the conversation. The various alternate approaches all boil down to a nucleus with a cloud (heh) of projects with probabilistic

The current Python library situation for OpenStack is, sorry to say, a mess. Cleaning it up requires essentially starting over and abstracting the individual REST APIs to usable levels. With OpenStackClient I started from the top and worked down to make the CLI a better experience. I think we have proved that to be a worthwhile task. Now it is time to start from the bottom and work up. The existing libraries utilize a Manager/Resource model that may be suitable for application work, but every project's client repo was forked and changed so they are all similar but maddeningly different.