About Adam Young

Once upon a time I was an Army Officer, but that was long ago. Now I work as a Software Engineer. I climb rocks, play saxophone, and spend way too much time in front of a computer.

Splitting a patch

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.

Continue reading

Using the Openstack common client with Keystone

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=''  where url like '';

Restart Keystone.

And you can use the command:

export OS_AUTH_URL=
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 

Load up the Keystone User Table

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.

Continue reading

Policy Enforcement in OpenStack

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.

Continue reading