Translating Between RDO/RHOS and Upstream OpenStack releases

There is a straight forward mapping between the version numbers used for RDO and Red Hat Enterprise Linux OpenStack Platform release numbers, and the upstream releases of OpenStack. I can never keep them straight. So, I write code.

UPDATE: missed Juno before…this is why we code review


upstream = ['Austin', 'Bexar', 'Cactus', 'Diablo', 'Essex', 'Folsom',
            'Grizzly', 'Havana', 'Icehouse', 'Juno', 'Kilo', 'Liberty',
            'Mitaka', 'N', 'O', 'P', 'Q', 'R', 'S']

for v in range(0, len(upstream) - 3):
    print "RHOS Version %s = upstream %s" % (v, upstream[v + 3])

RHOS Version 0 = upstream Diablo
RHOS Version 1 = upstream Essex
RHOS Version 2 = upstream Folsom
RHOS Version 3 = upstream Grizzly
RHOS Version 4 = upstream Havana
RHOS Version 5 = upstream Icehouse
RHOS Version 6 = upstream Juno
RHOS Version 7 = upstream Kilo
RHOS Version 8 = upstream Liberty
RHOS Version 9 = upstream Mitaka
RHOS Version 10 = upstream N
RHOS Version 11 = upstream O
RHOS Version 12 = upstream P
RHOS Version 13 = upstream Q
RHOS Version 14 = upstream R
RHOS Version 15 = upstream S

I’ll update one we have names for N and O.

Leadership in Software Development Part 3

Principle #7 – Keep Your Team Informed

Communication is the key to any operation. In the Army, they taught that an Infantry Soldier needs to do three things in order to succeed: Shoot, move, and communicate. Well, there should be very little gun fire in open source development, so shooting is less essential. Movement to, since most things happen via network. But communication is paramount. Tell people what you are going to do. A great decision left not communicated is no decision. In the absence of information, people will make assumptions. It is easier to correct mistakes early, and to identify them requires review and correction.

Continue reading

Leadership in Software Development Part 2

Principle #6 – Know Your Personnel and Look Out for Their Well Being

In an Open Source software project, who are “your people?” Your people are your community. Whether they are a fellow developer from your own company, the guy that pops in once every couple of months to make a typo fix, or someone that just reports bugs, they are all the people that lead to the success (or lack thereof) of your project.

Continue reading

Leadership in Software Development Part 1

I’ve been in and out of leadership roles from High School onward. For the past decade and a half, I’ve been a professional software developer. During that time, I’ve been in a leadership position roughly a third of the time. Recently, I was asked to evaluate my Leadership Philosophy (more on that later). I’ve also had to do the annual counselling that My company formalizes.

One tool we learned in the Army was the list of Leadership principals. As part of my evaluation, I want to see how I think they apply to what I do: Software Development in an Open Source project space. Here’s what I’ve come up with so far:

Continue reading


While I tend to play up bug 968696 for dramatic effect, the reality is we have a logical contradiction on what we mean by ‘admin’ when talking about RBAC.

In early iterations of OpenStack, roles were global. This is reflected in many of the Policy checks that only look for the global role. However, prior to the Keystone-Light rewrite, role assignments became scoped to tenants. This shows up in the Keystone git history. As this pattern got established, some people wrote policy checks that assert:

role==admin and tenant_id=resource.tenant_id

This contradicts the global-ness of the admin roles. If I assign

(‘joeuser’, ‘admin’,’mytenant’)

I’ve just granted them the ability to perform all of the admin operations.

Thus, today we have a situation where, unless the user rewrites the default policy, they have to only assign the role admins to users that are trusted to be admins on the whole deployment.

We have a few choices.
Continue reading


OpenStack is a big distributed system. FreeIPA is designed for security in distributed system. In order to develop and test each of them, separately or together, I need a distributed system. Virtualization has been a key technology for making this kind of work possible. OpenStack is great of managing virtualization. Added to that is the benefits found when we “fly our own airplanes.” Thus, I am using OpenStack to develop OpenStack.

Steve Okay took this while waiting for a flight to LAS

Early to Rise
757-200 lifts off Rwy 1 at SFO at sunrise. Credit Steve Okay. Used With Permission

Continue reading