[Most of this originally appeared in a thread on the openstack-dev mailing list but seemed interesting enough to repost here.] It is TC election season again in OpenStack-land and this time around a few days gap has been included between the self-nomination period and the actual election for those standing for election to be quizzed on various topics. One of these questions[0] was the usual "what is OpenStack?" between One Big Thing and Loosely Familiar Many Things. I started with a smart-alec response to ttx's comparison of OpenStack to Lego (which I still own more of than I care to

or How I Learned to Love the Lack of Environment Variables Previously I posted a preview of my favorite new feature of OpenStackClient, support for cloud configuration files and the new --os-cloud global option. Who knew it would take six months to get it done and released? There is some merely adequate documentation of the Client Cloud Configuration (or CCC) operation in the OSC Configuration docs, but this is too good to leave to official docs alone. CCC was actually introduced in OSC release 1.1.0, which is the basis for compatibility with Liberty dependency requirements. But like the rest of

I was looking forward to writing a bit about OpenStackClient becoming the first project added to OpenStack under the 'big yurt' [1] governance model. It was even mostly written and set to publish right after the QA Code sprint article when Nebula did what so many startups do, which is to abruptly cease to exist. On April 1 no less. So instead I'll rehash this as a note on OSC's third birthday, based on the first repo commit. Looking Backward I don't want to spend too much energy looking at where we have been, except to note that a lot

Last week (Mar 25-27) a handful of OpenStack QA Team members gathered at HP's Chelsea office to Get Some Code Written and Merged. We had a small list of priorities and some amazement at the amount of stuff the morning caterer could fit into a single box. [Note to self: get a magic catering box to store oversized project todo list] I was focused primarily on DevStack although some discussion took place around some future direction on Grenade plugins (see below). Much actual work was accomplished by others present in spite of Matt's attempts to feed us into submission. Dang,

OpenStackClient has had plugin support for a while now and it is being used by real-world OpenStack project clients such as Congress. I've also been using it as an entry point (ha!) for some of my experimental command setups, and so can you. osc-debug I've spent a lot of time debugging OSC lately in preparation for my favorite new feature yet-to-come, support for the new --os-cloud option that takes advantage of os-client-config's cloud configuration file abilities. Much of this debugging is necessarily around authentication and it became obvious to me that a built-in way to see what OSC was using

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.