The maximum header size between a HTTPD and an WSGI process is fixed at 8 Kilobytes. With a sufficiently large catalog, the token in PKI format won’t fit. Compression seems like it would be such an easy solution. But the there is a Hobgoblin or two hiding in the shadows.
Akai recently released a USB version of their Electronic Wind Instrument (EWI) which I was able to purchase for under $200. I was fairly quickly able to get it running using QJackCtl and QSynth. But then I wanted to understand what was happening. That involved spelunking into the four subsystems that make up the title of this post.
The majority of web service calls in OpenStack require token validation. Checking a token ID against a list is a cheap hashtable lookup. Comparing a token to a set of events is more expensive. How can we keep costs down?
To make things easier for your code reviewer, each patch should be small, and hold one well defined change. I break this rule all the time, and it comes back to bite me. What happens is that I get heads down coding, and I have a solution that involves changes to wide number of files and subsystems, new abstractions, etc. Here is how I am currently dealing with breaking down a big patch.
OpenStack Milestone Icehouse 2 (I2) is due this Tuesday. The gate is deep and the penalty for messing it up is costly. I recently had to update a patch that depends on three patches that are approved but but not merged to master. Using the git review command line, all 5 patches would get resubmitted. This was too high a risk for me.
“Sitting is the new smoking.” –Unattributed quote making the rounds.
Lower back pain is part of what has been termed “Silicon Valley Syndrome,” the side effect of using too much technology. I’ve been battling lower back pain for years.
Much of the future work we need to do on Keystone falls into issued of scope. I’m going to merely try and define the problems here, and avoid talking about solutions. I’ll try to address more specific aspects in future posts. Continue reading
My last post showed how to load the user data using curl. This is only interesting if you love curl. Its pretty easy to do the same thing from the command line. Now, we at Keystone central hate responsibility. We have no desire to do more than we have to. That includes wrint the Command Line Client.
There is an effort afoot to move to a unified command line. Here is a sneak peek:
To get this to work took a little finagling: When a user gets a token, it contains the URL for the Keystone admin port, and the CLI uses this to perform the user create action. There is work going to to do better discoverability (figure out which version of the API is supported), but until then, you can do the following hack (not recommended for production)
Edit the database
mysql --user keystone --password=keystone keystone
Make the admin URL V3 specific:
update endpoint set url='http://127.0.0.1:35357/v3' where url like 'http://127.0.0.1:35357/%';
And you can use the command:
openstack --os-identity-api-version=3 user create testname2 --password=testme --project=demo --domain=default
So my previous example would be reduced to:
while read USERNAME ; do openstack --os-identity-api-version=3 user create $USERNAME --password=changeme --project=demo ; done < usernames.txt
In the past I have created scripts for loading test data into FreeIPA. I’ve started doing the same thing for Keystone, using the Web API. Here is the first. It uses a list of usernames generated from my FreeIPA sample data, based on first initial-last name of a bunch of the most popular names in the country. The list is here. Here is the script I use to load it. Once again, I use jq to parse the JSON.
Note that HTML hates heredocs: I had to replace the here doc double-less-than-sign with a comment:
#insert two less than signs here#
To make this format correctly. Reverse this change before running this file, or fetch the clean source from here.
Keystone explicitly lists the token identifiers for the revoked tokens if the token revocation lists. This lends itself to simple revocation checking: is the ID on the list? No? Token is still good. However, the number of drawbacks in this approach overwhelm the simplicity of it, and indicate a need for a better solution.