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/%';
Restart Keystone.
And you can use the command:
export OS_AUTH_URL=http://127.0.0.1:5000/v3 export OS_USERNAME=admin export OS_PASSWORD=freeipa4all export OS_TENANT_NAME=admin 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.
How can I delegate the ability to delegate?
Keystone’s Roles are the primary indicator of authority in an Open Stack system; the roles a user has determine what operations they can perform. The primary function of Keystone is to map a user to a role in a project. In a system with millions of users, one person, or even a small subset of people, cannot be responsible for assigning all roles to all people. I want to be able to delegate the authority to assign people to roles.
The following article walks through the process of assigning roles to users, and adjusting policy to perform more specific checks in an Open Stack service. To work through this example, all you will need is a working Keystone server.
Third of three articles: Examples. More Examples.
My previous example showed how to create a user using the V3 API. But what if you don’t even have an admin user in your database? How are you going to perform admin operations in a bootstrap scenario? Here’s how to do operations with no user in the database, and to get the database up to the point where you can perform operations directly.
We want your patches for OpenStack, Keystone. Just don’t be surprised when it gets a minus one rating.
Continue reading