Barely Functional Keystone Deployment with Docker

My eventual goal is to deploy Keystone using Kubernetes. However, I want to understand things from the lowest level on up. Since Kubernetes will be driving Docker for my deployment, I wanted to get things working for a single node Docker deployment before I move on to Kubernetes. As such, you’ll notice I took a few short cuts. Mostly, these involve configuration changes. Since I will need to use Kubernetes for deployment and configuration, I’ll postpone doing it right until I get to that layer. With that caveat, let’s begin.
Continue reading

JSON Home Tests and Keystone API changes

If you change the public signature of an API, or add a new API in Keystone, there is a good chance the Tests that confirm JSON home layout will break.  And that test is fairly unfriendly:  It compares a JSON doc with another JSON doc, and spews out the entirety of both JSON docs, without telling you which section breaks.  Here is how I deal with it:

Continue reading

Translating Between RDO/RHOS and upstream releases Redux

I posted this once before, but we’ve moved on a bit since then. So, an update.

#!/usr/bin/python

upstream = ['Austin', 'Bexar', 'Cactus', 'Diablo', 'Essex (Tag 2012.1)', 'Folsom (Tag 2012.2)',
 'Grizzly (Tag 2013.1)', 'Havana (Tag 2013.2) ', 'Icehouse (Tag 2014.1) ', 'Juno (Tag 2014.2) ', 'Kilo (Tag 2015.1) ', 'Liberty',
 'Mitaka', 'Newton', 'Ocata', 'Pike', 'Queens', '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 (Tag 2012.1)
RHOS Version 2 = upstream Folsom (Tag 2012.2)
RHOS Version 3 = upstream Grizzly (Tag 2013.1)
RHOS Version 4 = upstream Havana (Tag 2013.2)
RHOS Version 5 = upstream Icehouse (Tag 2014.1)
RHOS Version 6 = upstream Juno (Tag 2014.2)
RHOS Version 7 = upstream Kilo (Tag 2015.1)
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 R
RHOS Version 15 = upstream S

Tags in the Git repos are a little different.

  • For Essex though Kilo, the releases are tagged based on their code names
  • 2011 was weird.  We don’t talk about that.
  • From 2012 through 2015, the release tags  are based on the date of the release.  Year, the release number.  So the first release in 2012 is 2012.1.  Thus 2012.3 does not exist. Which is why we don’t talk about 2011.3.
  • From Liberty/8 the upstream  8 matches the RDO and RHOS version 8. Subnumbers are for stable releases, and may not match the downstream releases; Once things go stable, it is a downstream decision when to sync.  Thus, we have tags that start with 8,9, and 10 mapping to Liberty, Mitaka, and Newton.
  • When Ocata is cut, we’ll go to 11, leading to lots of Spinal Tap references

Distinct RBAC Policy Rules

The ever elusive bug 968696 is still out there, due, in no small part, to the distributed nature of the policy mechanism. One Question I asked myself as I chased this beastie is “how many distinct policy rules do we actually have to implement?” This is an interesting question because, if we can an automated way to answer that question, it can lead to an automated way to transforming the policy rules themselves, and thus getting to a more unified approach to policy.
Continue reading