What I Hope to Get From the OpenStack Vancouver Summit

reproduced from content I wrote for SuperUser.

Matt Fischer, principal engineer at Time Warner Cable, shares survival tips for the Summit: backup plans, a beer list and a talk that he promises will be better than “Cats.”

May 11, 2015

The Vancouver summit is about a week away and so it’s time to start my prep work for the summit. This first means making a list of talks I want to go to. It also means making a list of any people I want to meet in person to talk to or people I owe a beer (or three) to. Finally, it means a list of things I want to accomplish at design sessions. If you’ve never been to a Summit before, what you get out of it really depends on how well you dig into the schedule and do some advanced planning.

So with that in mind, here’s my thinking.

Planning for Talks

I have some main focus areas for talks, things I want to come away from the summit knowing more about. These include things for which I’m the “owner” of in the Time Warner Cable OpenStack cloud, but also things I’m just curious about, so in no particular order:

Operations I always want to know how to do things differently or better, so you’ll see me around these rooms a lot. I’m specifically interested in Upgrades, CI/CD, and integrating new features into our cloud.

Heat I’m specifically interested in application catalog capabilities. Designate – I’ve worked some on this in the past few months. Neutron – I always want and need to know more about Neutron, even though it’s not my focus area.

Now with talks you can simply find the ones you like, and if you create an account and sign-in, you can add them to your personalized schedule. This is what I’d recommend to help plan your day. But, there’s a few more tricks that I’d recommend you use.

Review your schedule every morning. If you’re in Vancouver with a team you can divide up talks if you have time conflicts. You may also find that you’ve changed your mind or the schedule has changed, hence the morning review.

Have a backup talk. Sometimes talks are full or maybe you go and it’s not for you. You always need a backup talk.

Make a list of talks you want to watch later. All the talks end up on the OpenStack Foundation’s Youtube channel. Make a list of talks that you didn’t or won’t get to and watch them later. This does not work well for hands-on sessions, so I always opt to go to them.

If you can’t pick a talk by subject, pick by speaker. The speaker makes the talk sometimes more than the subject.

Don’t be afraid to have free time. The summit can be grueling. Leave a space or two in your schedule and visit the vendors or go take a nap.

Planning for People

OpenStack is community driven and the community is made of people. Take time to say “hi” to the people you’ve talked to on IRC or mailing lists.

Take the time to thank someone who fixed a bug for you or better yet buy them a beer. You cannot underestimate the value of having a beer with someone you’ve only previously met online. I cannot emphasize this enough.

Who are the lucky ones on my beer list this year? You’ll have to wait and see, hopefully I’m on yours!

Planning for Design Sessions

For the first time, OpenStack Puppet will be a real OpenStack project and so while previously we’ve had an hour to discuss stuff, this time we will have a full day for design work. Through lots of work over the past year, I’ve become core in OpenStack Puppet, and I hope to spend a good part of my day Tuesday participating in live discussions and work sessions. We have lots of stuff to discuss, the largest item which is dear to me, is when the master branch can drop support for the old stable release. If you’ve been active in other projects, you may have similar issues like this that need closure. These are usually easier to figure out in a room rather than in an IRC meeting. However, many of the design sessions are already planned so it may be too late to get something on the agenda, but it’s not too late to attend and participate. I’d recommend making a list of the things you want to cover and seeing how that lines up with the design session schedule. Please note that the Design Summit and the OpenStack Summit use different schedules hosted on different pages.

Planning for Parties

The OpenStack Summits have a large after-hours social aspect. These are valuable to attend just for camaraderie — you don’t have to drink beer to go and have fun. I generally go to as many of these as possible, they are usually pretty great.

You’re Invited!

I hope to see everyone in Vancouver, and would like to especially invite you to see some of my talks. The descriptions are pretty good, but I thought I’d say a few things about what you could expect to get out of each of them, here they are in chronological order with links so you can add them to your schedule.

Building Clouds with OpenStack Puppet Modules If you’re curious about how companies use Puppet to deploy OpenStack or about how our community works, you should attend this talk. You will get a couple different views and ideas on using Puppet from Mike Dorman and I, and hear about the community from Emilien Macchi. Monday, May 18 • 4:40 p.m. – 5:20 p.m. http://sched.co/38gd

A CI/CD Alternative to Push and Pray for OpenStack There are lots of CI talks this year, but I promise you will learn something new at this one. Clayton O’Neill and I will cover lots of topics and tools and you will see how we use these tools to get code and config from concept to production. Tuesday, May 19 • 12:05 p.m. – 12:45 p.m. http://sched.co/37lb

Getting DNSaaS to Production with Designate Have your customers been asking for DNSaaS (DNS as-a-Service)? Do you plan on having several people working on it full time as core Designate developers or would you rather just get it deployed with the minimum of pain? If the latter, then this is the talk for you. Clayton and I will cover what work is required, what work we did, and what to watch out for. One special thing that we will cover is how to write your own (or use our) Designate Sink which lets you automatically create records every time a new floating IP is assigned. Wednesday, May 20 • 9:50 a.m. – 10:30 a.m. http://sched.co/380J

Real World Experiences with Upgrading OpenStack at Time Warner Cable There are also lots of Upgrade talks at this summit. In this one, Clayton and I will be telling a story of what happened when we upgraded to Juno. Even though I wasn’t smart enough to put “beer” in the title of my upgrade talk, maybe you can learn some lessons or get some ideas from us. You’ll laugh, you’ll cry, it will be better than “Cats.” Thursday, May 21 • 2:20 p.m. – 3:00 p.m. http://sched.co/37wu

Tagged ,

Scale & Maturity: Thoughts on the OpenStack Mid-Cycle Operators Meetup

A re-post of an article I wrote last week for SuperUser.

A couple weeks back I attended the OpenStack Operators Mid-Cycle Meetup in Philadelphia.

One of the best parts of these meetups is that the agenda is all formed in public and everyone gets a say in it. Some of the things I was most concerned about made the list (RabbitMQ, packaging), some did not get on the main agenda (database maintenance, Puppet), but many side groups formed during the event and these topics were covered at lunch conversations and in the lobby.

The interesting part of this summit was hearing from other operators problems and solutions. This was more focused, yet with a larger audience, than the previous sessions in Paris. I think a real sense of camaraderie and support for shared solutions was achieved.

Puppet OpenStack Discussion at Lunch

As I was listening to people discuss their issues with OpenStack and how others had solved them, I realized that OpenStack operators have different issues at different scales and maturity levels. When I think about scale and maturity, it’s not necessarily about number of nodes or the number of customers, its more about the number of resources you have, the number of services you provide, the maturity of your processes (such as deployment), and to a some extent how many of your problems you’ve solved with automation.

Our team started at a small scale. We had four people and the goal was to stand-up OpenStack. With four people, you are limited in scope and have to judiciously focus your resources. As our team grew and we worked through forming our deployment and automation processes, we’re able to spend more time on improving our service offerings and adding more services. We can also go back and clean up technical debt which you accumulate as you build an OpenStack deployment. Before these tools and processes are fully in place (and they are never perfect), making changes can take away valuable time.

For example, when an operator finds a bug, it takes a lot of resources and time to get a fix for that bug into production. This includes debugging, filing a bug, fixing the code, pushing a fix, begging for reviews, doing a cherry-pick, begging for more reviews, waiting for or building a package, deploying the new code. Many operators stop around the “filing a bug” step of this process.

Medium-sized operators or ones with more mature processes will sometimes work on a fix (depending on the issue), and may or may not have systems in place to allow them to hold the patch locally and build local packages. On the other hand, larger operators who have good systems in place can give the issue to the Team. They may have 10 people working on it, some of them core members. They have a full continuous integration/automation team that has solved package builds and deployments for them.

Our goal has always been to increase our scale of services, not only via more resources but through automation and creating tools/processes that allow us to offer services for the same amount of resource investment. The main reason for this that is our customers don’t care about Keystone or Neutron, these are just building blocks for them, they really want services like Domain Name System (DNS,) load-balancing-as-a-service (LBaaS), firewall-as-a-service (FWaaS) and database-as-a-service (DBaaS). But until the processes and tools are solid for the core components, it’s hard to find time to work on those, because while customers may not know what Keystone is, they sure care when it doesn’t work.

So how does any of this relate to the conference besides I was daydreaming about it in the lobby? What is clear to me after the sessions is that we have some specific areas where we’re going to work on process improvements and tooling.

My top three are:

  1. RabbitMQ monitoring and tooling
  2. Speeding up and clarifying our development & deployment process
  3. Investigating alternatives to heavy-weight OS packages for deploying OpenStack code

When we revisit this again in six months at the next Mid-Cycle, I suspect that number two will remain on the list, probably forever, since you can always make this process better. I’m certain we’ll have a new number one, and I’m pretty hopeful about the options for number three.

What will these investments get us? Hopefully more time for second-level service offerings and happier customers.

Tagged , ,

Using Keystone’s LDAP Connection Pools to Speed Up OpenStack

If you use LDAP with Keystone in Juno you can give your implementation a turbo-boost by using LDAP connection pools. Connection pooling is a simple idea. Instead of bringing up and tearing down a connection every time you talk to LDAP, you just reuse an existing one. This feature is widely used in OpenStack when talking to mysql and adding it here really makes sense.

After enabling this feature, using the default settings, I got a 3x-5x speed-up when getting tokens as a LDAP authenticated user.

Using the LDAP Connection Pools

One of the good things about this feature is that it’s well documented (here). Setting this up is easy. The tl;dr is that you can just enable two fields and then use the defaults and they seem to work pretty well.

First turn the feature on, nothing else works without this master switch

# Enable LDAP connection pooling. (boolean value)

Then if you want to use pools for user authentication, add this one:

# Enable LDAP connection pooling for end user authentication. If use_pool
# is disabled, then this setting is meaningless and is not used at all.
# (boolean value)

Experimental Setup

For my experiment I used a virtual keystone node that we run on top of our cloud, pointing at a corporate AD box using ldaps. Using an LDAP user, I requested 500 UUID tokens in a row. We use a special hybrid driver that uses the user creds to bind against ldap and ensure that the user/pass combo is valid. I also changed my OS_AUTH_URI to point directly at localhost to avoid hitting the load balancer. Finally I’m using the eventlet (keystone-all) vs apache2 to run Keystone. According to the Keystone PTL, Morgan Fainberg, “under apache I’d expect less benefit” If you’re not using the eventlet, ldaps, or my hybrid driver you might get different results, but I’d still expect it to be faster.

Here’s my basic test script:

export OS_TENANT_NAME=admin
export OS_PASSWORD=password
export OS_TENANT_NAME=admin
export OS_REGION_NAME='dev02'
export OS_AUTH_STRATEGY=keystone
export OS_AUTH_URL=http://localhost:5000/v2.0/
echo "getting $1 tokens"
for i in $(eval echo "{1..$1}")
curl -s -X POST http://localhost:5000/v2.0/tokens \
-H "Content-Type: application/json" \
-d '{"auth": {"tenantName": "'"$OS_TENANT_NAME"'", "passwordCredentials": {"username": "'"$OS_USERNAME"'", "password": "'"$OS_PASSWORD"'"}}}' > /dev/null


Using the default config, It took 7 mins, 25s to get the tokens.

getting 500 tokens
real 7m25.527s
user 0m2.312s
sys 0m1.557s

I then enabled use_pool and use_auth_pool and restarted keystone, the results were quite a bit faster, a 5x speed-up. Wow.

getting 500 tokens
real 1m25.774s
user 0m2.302s
sys 0m1.539s

I ran this several times and the results were all within a few seconds of each other.

I also tried this test using the keystone CLI and the results were closer to 3.5x faster, still a respectable number.

Watching the Connections

I have a simple command so I can see how many connections are being used:

watch -n1 "netstat -an p tcp | grep :3269"

Using this simple code I can see it bounce between 0 and 1 without connection pools.

Using the defaults but with connection pools enabled, the number of connections was a solid 4. Several minutes after the test ran they died after a bit and went to 0.

I’m not sure why I didn’t get more than 4, but raising the pool counts did not change this value. Any ideas on this are welcome. This is because I have 4 workers on this node.

Tokens Are Fundamental

The coolest part of this is that this change speeds everything up. Since you need a token to do anything, I re-ran the test but just had it run nova list, cinder list, and glance image-list 50 times using the clients. Without the pooling, it took 316 seconds but with the pooling it took 231 seconds.


There are lots of ways to improve the performance of OpenStack, but this one is simple and easy to setup. The puppet code to configure this is in progress now. Once it lands, I plan to move this to dev and then to staging and prod in our environments. If I learn any other interesting things there, I’ll update the post.

Tagged , , ,

What Do Operators Do All Day?

When I was a kid, Richard Scarry’s book, “What Do People Do All Day” was one of my favorites. I saw this book at my parents house and I was thinking about trying to categorize everything I’ve worked on in the past few months, so the result of that thinking is this post. “What Do Operators Do All Day?”

Being an operator means that you need to by necessity be a jack of all trades, unless you’re at a very large provider. And so, over the past 6 months, I’ve worked on almost every piece of our cloud, and in almost all cases I learn something new and grow my skillset (which is my favorite part of working on Openstack).

Collecting My Data

Over the last 6 months or so, I’ve resolved 106 JIRA issues, and looking back at these provides a decent picture of where I spend my tracked work time. I’ve also done upstream reviews and commits, for which stackalytics will provide good details. Using this information, I’ll present where I do my work in order from most time to least.

Puppet Automation

I spend most of my time these days working on puppet modules or configuring services with puppet. Some of this work includes:

  • Fixing/configuring/enabling new features in services like Keystone/Nova/etc
  • Upgrading our puppet branches from Icehouse to master
  • Configuring build server & infra (cobbler, puppet, package repos etc)
  • Configuring/deploying Icinga, or writing new checks
  • Refactoring and cleanup, like moving all our keystone roles/users to YAML so that they’re simpler to add


A close second is Ansible automation. We use ansible to manage our internode dependencies and also to drive our deployments. One example of what we’d use ansible for is to upgrade mysql, one node at a time, managing state between nodes while doing so. Over the past six months I’ve written ansible jobs to:

  • Deploy a new hand-built version of ovs
  • Perform a live upgrade mysql from 5.5 to 5.6
  • Upgrade openstack services from I to J or J to K
  • Improve to our weekly deployment process


Some of these tasks don’t show up in Jira, but they do take a good amount of my time.

  • Travel/training: Openstack conf, RabbitMQ training, etc
  • Planning: sprint planning, feature planning, expansion planning, etc
  • Mentoring and on-boarding: we’ve grown a lot and this one cannot be underestimated. I do about 5-10 code reviews per day even when I’m not answering questions
  • Working on Ubuntu packaging for openstack, we roll (some) of our own
  • MySQL/Galera DBA-esque work

On Call/Issues

Every few months, I do an on-call rotation for a week, these can be quiet or not, depending on the shape of our monitoring and cloud. Whether it’s a good or bad on call is usually of our own doing however. Even when not on call, I deal with issues though, although we do our best, we occasionally have problems. When you get enough nodes, you’ll get failures. They could be hardware failures, kernel issues, or even simply software failures, we’ve had them all. I could do an entire post on the issues we see here, but the ones that stick out to me as focus areas for software are ovs, mysql, and rabbitmq. Those are probably the three most complex and most important pieces of our software stack, and so they get lots of my attention.


I think that the community of one of the best things about OpenStack, so I spend what little time I have left here. I participate in IRC and mailing list discussions as a part of the Operators and Puppet-Openstack community. I also do reviews and submit fixes primarily for puppet-openstack but also for Openstack itself. Although my commits to openstack itself have slowed, I’ve earned my 3rd ATC for Vancouver and I think it’s important to participate in this process.


One of my first concerns that I expressed when interviewing for this job was that we’d have Openstack setup in a year and then we’d be done. That has been far from the truth. In reality, the life of an Openstack operator is always interesting. There’s no shortages of things to fix, things to improve, and things to learn, and that’s why I love it. Although each release of Openstack generally makes things easier and more robust, they also always add more features along the edges to keep us busy.

Does this list match what everyone else spends their time on? Let me know in the comments.

Tagged ,

My Key Learning from Paris

I learned a bunch of things in Paris: French food is amazing, always upgrade OVS, but the most important thing I learned in Paris?

All operators have the same problems.

Every operator session was a revelation for me. As it turns out, I’m not the only one writing Icinga check jobs, Ansible scripts, trying to figure out how to push out updates, or fighting with ovs. These sessions not only provided by validation to let me know that we’re not doing stuff totally wrong, but also allowed everyone to share solutions. Below are some of the themes that I found particularly interesting or relevant to this premise.


One topic in which operators have a common interest was upgrades. Only a few of the operators have any real experience with this, but its been a pain point before for many. Some have resorted to fork-lift style “bring up a new cluster” upgrades, which is not nice for customers and requires extra hardware. How do we solve this? It seems that some projects have upgrade guides, but finding documentation on a holistic upgrade is difficult, especially gathering information on ordering (Cinder before Nova, for a contrived example). Issues specifically called out in the session were config changes (deprecations and new additions) and database migrations (including rollback). Rollback is especially worrying as its not well tested. There was no solution for this except a resolve to share information on upgrading via the Operators Mailing List.

Etherpad for Upgrades

CI/CD & Packaging

Another issue that operators face after an Openstack deployment is how to get fixes and new code out to the nodes. An upstream bug fix might take a few days, plus a week for a backport, plus a month for the distro to pick it up. This means that even if the operator fixes it themselves, they still have a delay in getting it releases. During this delay you might be impacting customers who may not be that patient. The solution for many is using a custom CI/CD system that builds “packages” of some sort, whether distro packages or custom built vdevs. It was interesting to hear that people have a myriad of solutions here. We use a toolchain quite similar to the upstream Openstack tool chain that outputs Ubuntu packages. However even with this method we still rely on dependencies and libraries provided by the Ubuntu Cloud Archive, as much as possible anyway.

There was a bunch of talks on this subjects, not just operator talks, here are a link to the ones I attended:

  • CI/CD Pipeline to Deploy and Maintain an OpenStack Iaas Cloud (HP)
  • CI/CD in Practice (Comcast)
  • Building the RackStack (Rackspace)
  • If you know other ones that I should go back and watch please comment here.

    Automation (Puppet)

    We use Puppet to configure and manage our Openstack deployment, so this was an area of interest to me. It was great to see a 100% full room with everyone focused on improving how Openstack is configured with puppet. From discussions on new check jobs to a conversation about how to better handle HA, it was great to see the real sense of community around Puppet.


    The second puppet session was more of a “how are you solving X” and “how could it be better”. This was also a great session with some interesting notes.

    Towards a Project?

    Finally, one of the more interesting things happened later in the week when Michael Chapman and Dan Bode grabbed me in the lobby and wanted me to preview an email that was about to go out. In brief, they were proposing an operations project. This was born of the realization that I’d also made, we’re all solving the same issues. This email led to an impromptu meeting of about 30 people in the lobby of the Meridien hotel and the beginnings of an Operations Project.

    Birth of a New Project

    Birth of a New Project

    It was not the ideal venue, but we still had a great discussion on a few topics. The first was, can we have a framework that will allow us to share code? We all agreed that this project’s purpose is not to bless specific tools (for example Icinga) but instead to allow us to share Icinga scripts alongside other monitoring tools. Although this had been tried before with a github repo it had only a couple contributions, hopefully this will improve. We then dove into all the different tools that people use for packaging and whether or not any could be adapted as general purpose. Having a good tool for Ubuntu/Debian packages seemed to be something in great demand. Adding debian support for Anvil seemed to be something worth investigating further.

    Other topics of discussion included:

  • log aggregation tools and filters
  • ops dashboarding tools
  • Ansible playbooks
  • You can see the Etherpad link below to see what options for each were discussed, but the best idea is to catch up on the mailing list threads which are still ongoing and add if you have to share anything.


    Operations Wiki

    A Path Towards Contributing (via Commits) in Open Stack

    For 2014, I had a goal of doing 12 contributions (commits) to OpenStack. I set this goal because I wanted to learn more about the different components of OpenStack and I wanted to contribute back to the project. In order to do this, I continued a pattern that I started when I first began working on Ubuntu, one which I consider to be a great way to come up to speed on and contribute to OpenStack. Sometime around May I stopped counting contributions and consider my goal to have been met(*). Since I consider that a success, I’d like to share my process with you here and hopefully it can inspire someone else.

    Step 1: Learn About the Project
    The first step was to learn more about the project, reading is interesting, but diving in and using is better, so I started with DevStack. This should be everyone’s first step. When you encounter something you don’t understand, go find a blog post or OpenStack Summit video about the subject.

    Step 2: Contributing with Bug Triage
    Once I had a basic understanding of the parts of OpenStack, I started looking at bugs. Joining BugSquad and BugControl was the first thing I did when I did community work on Ubuntu and doing triage for OpenStack is also a good first step. Start with this wikipage, especially if you’re new to Launchpad. By triaging bugs you can get an idea where the issues are and get a second level understanding of the projects. A bug report might cause you to ask yourself, why is neutron talking to nova in this way? It could be something that was not obvious from playing with DevStack. During this process you can mark bug dupes, ask follow-up questions, and perform other triage work. For details on OpenStack bug triage work, read more here. The best part about Bug Triage for new committers? There is an unlimited and never-ending supply of bugs. So which to pick? I like to focus on areas that I have a basic understanding of and interest in. Pick a few projects that make sense to you and look there.

    Step 3: Finding a Bug
    The real mission during bug triage is digging for a golden nugget, your first bug. This is more difficult than you’d think. You need to find a bug that you can fix, something relatively simple, because your goal in fixing your first bug is to learn the process. During your bug triage work you may have seen some bugs tagged with “low-hanging-fruit”, these are issues that have been identified as ones that would be simple to fix, a good first choice. If you don’t see an obvious bug tagged thusly, I’d recommend starting with the python-*client projects. I find that this code is easier to understand, easier to test, and has more unclaimed issues. You can also even just pull the source for one you like and look for FIXME notes. Another idea is unit tests, all projects love more tests. And finally, the docs can always use help.

    Step 4: Working on the Bug
    After finding your bug, get to work on fixing it. Before doing so you have some pre-work to do, like creating a launchpad account and signing the developer agreement. I’m not going to list all these steps, but it’s not too difficult. The next steps are fairly obvious, testing, reviewing, fixing, etc. A brief interlude on testing: I do all my testing during this process against DevStack or in DevStack. I have an up-to-date DevStack VM with me at all times and a git repo with my config changes for it. I’d recommend you do the same. Note, when you make your DevStack VM, give it enough RAM and disk, 2GB RAM + 4GB swap and a 20GB disk should be enough. As for code reviews, keep in mind that you will have to likely go multiple rounds on your code reviews. Most of my changes go at least 3-4 rounds, some more than 10, but don’t lose hope, it will eventually land and it will be awesome!

    Anyway that’s my process for getting to a first commit with OpenStack. Hopefully if you’re just getting started this method will work for you. Good luck finding your bug and doing your first commit! If you have some other ideas on any of the stuff I covered, please comment below.

    * – I’m including StackForge commits in my count.


    Quick Update on Stacked Auth

    A quick update on Stacked/Hybrid auth for Keystone. I spent some time this week updating the driver for Icehouse. That branch is available here and includes packaging info. I’ve been too lazy to make a non-packaging copy of the branch but it should be easy to do. During my debugging of the new driver, I realized one thing, even though this driver does a bind using the credentials of the user you are trying to authenticate, you still need a service account to bind with if you are using subtree search. The reason is that the LDAP code does an initial bind to map your user id to a dn so that then it can do the “real” bind. If you see any issues with this code please let me know!

    Tagged , ,

    Keystone: Using Stacked Auth (SQL & LDAP)

    Most large companies have an Active Directory or LDAP system to manage identity and integrating this with OpenStack makes sense for some obvious reasons, like not having multiple passwords and automatically de-authenticating users who leave the company. However doing this in practice can be a bit tricky. OpenStack needs some basic service accounts. Then your users probably want their own service accounts, since they don’t want to stick their AD password in a Jenkins config. So multiple the number of teams that may use your OpenStack by 4 or 5 and you may have a ballpark estimate on the number of service accounts you need. Then take that number to your AD team and be sure to run it by your security guys too. This is the response you might get.

    Note: All security guys wear cloaks.

    The way you can tell how a conversation with a security guy is going is to count the number of facepalms they do.

    In this setup you probably also do not have write access to your LDAP box. This means that you need a way to track role assignment outside of LDAP, using the SQL back-end (a subject I’ve previous covered)

    So this leaves us with an interesting problem, fortunately one with a few solutions. The one we chose was to use a “stacked” or “hybrid” auth in Keystone. One where service accounts live in Keystone’s SQL backend and if users fail to authenticate there they fallback to LDAP. For role Assignment we will store everything in Keystone’s SQL back-end. The good news is that Ionuț Arțăriși from SUSE has already written a driver that does exactly what you need. His driver for Identity and Assignment is available here on github and has a nice README to get you started. I did have a few issues getting it to work, which I will cover below which hopefully saves you some time in setting this up.

    The way Ionut’s driver works is pretty simple, try the username and password first locally against SQL. If that fails, try to use the combo to bind to LDAP. This saves the time of having to bind with a service account and search, so it’s simpler and quicker. You will need to be able to at least bind RO with your standard AD creds for this to work though.

    From this point forward, you probably will only have the issues I have if you have an AD/LDAP server with a large number of users. If you’re in a lab environment, just following the README in Ionut’s driver is all you need. For everyone else, read on…

    Successes and Problems

    After configuring the LDAP driver, I switched and enabled hybrid identity and restarted keystone. The authentication module seemed to be working great. I did my first test by doing some basic auth and then running a user-list. The auth worked, although my user lacked any roles that allowed him to do a user list. When I set the SERVICE_TOKEN/ENDPOINT and re-ran the user list, well that was interesting. I noticed that since I had enabled the secret LDAP debug option (hopefully soon to be non-secret) that it was doing A TON of queries and I eventually hit the server max before setting page_size=1000. Below is an animation that shows what it was like running keystone user-list:

    This isn't really animated, but is still an accurate representation of what happened.

    This isn’t really animated, but is still an accurate representation of how slow it was

    It did eventually finish, but it took 5 minutes and 25 seconds, and ain’t nobody got time for that. One simple and obvious fix for this is to just modify the driver to not pull LDAP users in the list. There are too many to manage anyway, so I made the change and now it only showed local accounts. This was a simple change to the bottom of the driver, to just return SQL users and not query LDAP.

    root@mfisch:~# keystone user-list
    | id | name | enabled | email |
    | e0ede62ebcb64e489a41f4a9b18cd63c | admin | True | root@localhost |
    | f9d76feb7081463f973eeda82c918547 | ceilometer | True | root@localhost |
    | 176e232176c74164a42e2f773695671b | cinder | True | cinder@localhost |
    | fc8007f82b7542e88ca28fab5eda1b5c | glance | True | glance@localhost |
    | 635b4022aafc4f5488c048109c7b1665 | heat | True | heat@localhost |
    | b3175fc7b62748679b4c958fe89fbdf0 | heat-cfn | True | heat-cfn@localhost |
    | 4873cd322d0d4582908002b619e3940a | neutron | True | neutron@localhost |
    | 37ef623c60474bf5a384a2047719acf4 | nova | True | nova@localhost |
    | ff07bd356b8d4959be4326a43c297db0 | swift | True | swift@localhost |

    After making this change, I went to add the admin role to my AD user and found I had a second problem. It seemed to be relying on my user being in the user list before it would assign them a role.

    root@mfisch:~# keystone user-role-add --user-id MyADUser --role-id admin --tenant-id 6031675b7618458b8bb85b92857532b06No user with a name or ID of 'MyADUser' exists.

    I didn’t really want to wait five minutes to assign or list a role, so this needed fixing.


    It was late on Friday afternoon when I started toying with some solutions for the role issue. The first solution is to add OpenStack users into a special ou so that you can limit the scope of the search. This is done via the user_filter setting in keystone.conf. If this is easy for your organization, it’s a simple fix. It also allows tools like Horizon to show all your users. If you do this you can obviously undo the change to not return LDAP users.

    The second idea that came to mind was that every time an AD user authenticated, I could just make a local copy of that user, without a password and setup in a way that they’d be unable to authenticate locally. I did manage to get this code functional, but it has a few issues. The most obvious one is that when users leave the company there’s no corresponding clean-up of their records. The second one is that it doesn’t allow for any changes to things like names or emails once they’ve authenticated. In general it’s bad to have two copies of something like this info anyway. I did however manage to get this code working and it’s available on github if you ever have a use for it. It is not well tested and it’s not very clean in the current state. With this change, I had this output (truncated):

    root@mfisch:~# keystone user-list
    | id | name | enabled | email |
    | MyADUser | MyADUser | True | my corporate email |
    | e0ede62ebcb64e489a41f4a9b18cd63c | admin | True | root@localhost |
    | f9d76feb7081463f973eeda82c918547 | ceilometer | True | root@localhost |

    Due to the concerns raised above, we decided to drop this idea.

    My feelings on this solution...

    My feelings on this solution…

    The final idea which came after some discussions was to figure out why the heck a user list was needed to add a role. I dug into the client code, hacked a fix, and then asked on IRC. It turns out I wasn’t the first person to notice it. The bug (#1189933) is that when the user ID is not a UUID, it thinks you must be passing in a name and does a search. The fix for this is to pull a copy of python-keystoneclient thats 0.4 or newer. We had 0.3.2 in our repo. If you upgrade this package to the latest (0.7x) you will need a copy of python-six that’s 1.4.0 or newer. This should all be cake if you’re using the Ubuntu Cloud Archive.

    Final State

    In the final state of things, I have taken the code from Ionut and:

    1. disabled listing of LDAP users in the driver
    2. upgraded python-six and python-keystoneclient
    3. packaged and installed Ionut’s drivers (as soon as I figure out the license for them, I’ll publish the packaging branch)
    4. reconfigured keystone via puppet

    So far it’s all working great with just one caveat so far. If users leave your organization they will still have roles and tenants defined in Keystone’s SQL. You will probably need to define a process for cleaning those up occasionally. As long as the users are deactivated in AD/LDAP though the roles/tenant mappings for them should be relatively harmless cruft.

    Tagged , , ,

    Announcing forth-keystoneclient

    Over the past few weeks I’ve been working on a new client implementation for keystone. Python is a bit bloated for nimble CLIs like keystone, and so I went back to a language I used at my first job back in 1999, Forth. Forth is interpreted like python but it’s also very simple and memory efficient. And unlike python, forth can fit on a floppy disk. This allows this client to be installed onto satellites and other memory constrained environments. For embedded systems, forth also makes a great alternative to C. Now, onto the client.

    Mastering Forth

    Mastering Forth

    As you probably know, forth is stack-based, and no real programmer likes someone else managing the stack for them. I’ve taken this paradigm into the client design. So let’s dive in. Below is an example usage so you can see how simple it is:

    First we remember the definition of what user-role-list does. Python offers the “help” and “dir” for introspection, forth has ‘ and DUMP which work just as well. First let’s make sure user-role-list is defined:

    ' user-role-list  ok

    Then let’s see what it’s doing:

    ' user-role-list 64 cells dump
    7F0A31F7F300: D5 44 40 00  00 00 00 00 - 00 00 00 00  00 00 00 00  .D@.............
    7F0A31F7F310: 25 46 40 00  00 00 00 00 - 20 DE F2 31  0A 7F 00 00  %F@..... ..1....
    7F0A31F7F320: 88 46 40 00  00 00 00 00 - 99 99 99 99  99 99 99 99  .F@.............

    As you can simply tell from the above, we need to pass in the tenant-id and user-id, so let’s make the call.

    S" de4442c6e54a43459eaab97e26dc21bc2"  ok
    S" 2ebadab9148d421287eee6d264f29736d"  ok
    user-role-list 33  
    | id | name | user_id | tenant_id |
    | 006eaf0730e44756bc679038477d3bbd | Member | 2ebadab9148d421287eee6d264f29736d | de4442c6e54a43459eaab97e26dc21bc2 |
    | 03e83b65036a4e0cbd7cff5bff858c76 | admin | 2ebadab9148d421287eee6d264f29736d | de4442c6e54a43459eaab97e26dc21bc2 |

    I’ll be handing this out on floppy disks at the OpenStack conference in Atlanta if you’re interested, come find me and I’ll make you a copy.

    Prepping for distribution at the conference

    Prepping for distribution at the conference

    A note on debugging, if you plan on installing this on satellites remember how the speed of light can interact with your token expiration timeout.

    Tagged ,

    Keystone: User Enabled Emulation Can Lead to Bad Performance

    An update on my previous post about User Enabled Emulation, tl;dr, don’t use it. It’s slow. Here’s what I found:

    I just spent parts of today debugging why keystone user-list was so slow. It was taking between 8 and 10 seconds to list 20 users. I spent a few hours tweaking the caching settings, but the database was so small that the cache never filled up, and so I realized that this was not the main issue. A colleague asked me if basic ldapsearch was slow, and no it was fine. Then I dug into what Keystone is doing with the enabled emulation code. Unlike a user_filter, Keystone appears to be querying the user list and then re-querying LDAP for each user to check if they’re in the enabled_emulation group. This leads to a lot of extra queries which slows things down. When I disabled this setting, the query performance improved dramatically to between 2-2.5 seconds, about a 4x speed-up. If you are in a real environment with more than 20 users, the gain will be pretty good in terms of real seconds.

    Disabling the enabled_emulation leaves us with no user enabled information. In order to get the Enabled field back, I’m going to add a field to the schema to emulate what AD does with the enabled users. Since this portion of Keystone was designed for AD, this blog post may help clear up what exactly it expects here from an AD point of view. Read that page to the end and you get a special treat, how to use Logical OR in LDAP, see if it makes less sense than the bf language does.

    Also to reduce my user count, I did enable a user_filter, which since it’s just part of the initial query does NOT appear to slow things down. You could skip the new field and just use the filter if you want, however it’s not clear what impact a “blank” for Enabled has, other than perhaps some confusion. If it has a real impact, PLEASE comment here!

    Tagged , , ,