Category Archives: Openstack

Translating Between RDO/RHOS and Upstream OpenStack releases

Posted on by
3

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

UPDATE1: missed Juno before…this is why we code review
UPDATE2: had RDO using the version numbers, but it in sync with upstream.

#!/usr/bin/python
 
upstream = ['Austin', 'Bexar', 'Cactus', 'Diablo', 'Essex', 'Folsom',
            'Grizzly', 'Havana', 'Icehouse', 'Juno', 'Kilo', 'Liberty',
            'Mitaka', 'Newton', 'Ocata', 'Pike', 'Queens', 'Rocky',
            'Stein', 'Train', 'Ussuri', 'V','W','X','Y','Z']
 
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 Newton
RHOS Version 11 = upstream Ocata
RHOS Version 12 = upstream Pike
RHOS Version 13 = upstream Queens
RHOS Version 14 = upstream Rocky
RHOS Version 15 = upstream Stein
RHOS Version 16 = upstream Train
RHOS Version 17 = upstream Ussuri
RHOS Version 18 = upstream V
RHOS Version 19 = upstream W
RHOS Version 20 = upstream X
RHOS Version 21 = upstream Y
RHOS Version 22 = upstream Z

UPDATE: I’ve edited the list.

Admin

Posted on by
Reply

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 →

Ossipee

Posted on by
1

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 →

Template for a KeystoneV3.rc

Posted on by
Reply

If you are moving from Keystone v2 to v3 call, you need more variables in your environment. Here is a template for an update keystone.rc for V3, in jinja format:

export OS_AUTH_URL=http://{{ keystone_hostname }}:5000/v3
export OS_USERNAME={{ username }}
export OS_PASSWORD={{ password }}
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
export OS_PROJECT_NAME={{ project_name }}
export OS_IDENTITY_API_VERSION=3