[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 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
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.
I've been playing with OpenWRT since
- and have enjoyed building some of the smallest Linux images around. While targeted at low-end home router platforms, it also runs on a wide variety of small SoC boards including the near-ubiqutious Raspberry Pi and my fave BeagleBone Black. I've also been using an incredibly tiny OpenWRT instance on my laptop for years now to work around the 'interesting' network configuration of VirtualBox. Building a set of VMs that need to talk to each other and to the outside world shouldn't be hard, so I added a router just like I have at
Next Page »