Libcloud now supports OpenStack Identity (Keystone) API v3

I have recently pushed support for OpenStack Identity API v3 to Libcloud trunk. In this blog post I’m going to have a look at the motivation for that, changes which were involved and show some examples of how you can utilize those changes and newly available features.

What is OpenStack Keystone / Identity service?

OpenStack Keystone is an OpenStack project that provides identity and authentication related features to OpenStack projects such as Nova.

The project started as a simple service which only provided basic authentication features, but it has since grown into a fully fledged and powerful identity management service.

The latest version supports advanced user management, multiple projects, complex ACLs and more.

Future release will also include a Keystone to Keystone federation feature which will makes things such as a seamless cross-cloud authorizations possible.

Motivation

Support for OpenStack Nova was first added to Libcloud back in 2011. First version only included support for a simple token based authentication.

Since then a lot has changed and new (and more flexible) OpenStack Keystone versions have been released. We have been pretty good at following those changes and support for authenticating against Keystone API v2.0 has been available in Libcloud for a long time.

Those changes worked fine, but the problem was that not much thinking went into them and support for multiple Keystone versions was added after the fact. This means that the code was hacky, inflexible, hard to re-use and extend.

Luckily, those things were (mostly) hidden from the end user who just wanted to connect to the OpenStack installation. They only became apparent if you wanted to talk directly to the Keystone service or do anything more complex with it.

For one of the features we are working on at DivvyCloud, we needed support authenticating and talking to OpenStack Keystone API v3. Since Libcloud didn’t include support for this version yet, I decide to go ahead and add it.

All of the “hackiness” of the existing code also became very apparent when I wanted to add support for API v3. Because of that, I have decided to spend more time on it, do it “the right way” and refactor the existing code to make it more re-usable, extensible and maintainable.

Refactoring the existing code

Before my changes, all of the logic for talking to Keystone, handling of the token expiration, re-authentication, etc. was contained in a single class (OpenStackAuthConnection).

To authenticate, there was one method per Keystone API version (authenticate_1_0, authenticate_1_1, authenticate_2_0_with_apikey, authenticate_2_0_with_password). This means there was a lot of duplicated code, the code was hard to extend, etc.

I went ahead and moved to a “base class with common functionality” + “one class per Keystone API version” model. This approach has multiple advantages over the old one:

  • the code is easier to re-use, maintain and extend
  • version specific functionality is available via methods on the version specific class
  • less coupling

Some other notable changes are described bellow.

All of the identity related code has been moved from libcloud.common.openstack to a new libcloud.common.openstack_identity module.

This module reduces coupling between general OpenStack and Identity related code and makes code re-use and other things easier.

Before my changes, parsed service catalog entries were stored in an unstructured dictionary on the OpenStackServiceCatalog class. To make things even worse, the structure and the contents of the dictionary differed based on the Keystone API version.

Dynamic nature of Python can be a huge asset and can make development and prototyping faster and easier. The problem is that when it’s abused / overused it makes code hard to use, maintain and reason about. Sadly, that’s pretty common in the Python world and many times, people tend to over-use dictionaries and base their APIs around passing around unstructured dictionaries.

I refactored the code to store service catalog entries in a structured format (a list of OpenStackServiceCatalogEntry and OpenStackServiceCatalogEntryEndpoint objects).

Now only the code which parses service catalog responses needs to know about the response structure. The user itself doesn’t need to know anything about the internal structure and the code for retrieving entries from the service catalog is API version agnostic.

In addition to the changes mentioned above, OpenStackIdentity_3_0_Connection class now also contains methods for performing different administrative related tasks such as user, role, domain and project management.

Examples

This section includes some examples which show how to use the newly available functionality. For more information, please refer to the docstrings in the openstack_identity module.

Authenticating against Keystone API v3 using the OpenStack compute driver

This example shows how to authenticate against Keystone API v3 using the OpenStack compute driver (for the time being, default auth version used by the compute driver is 2.0).

from pprint import pprint

from libcloud.compute.types import Provider
from libcloud.compute.providers import get_driver

cls = get_driver(Provider.OPENSTACK)
driver = cls('<username>', '<password>',
             ex_force_auth_version='3.x_password',
             ex_force_auth_url='http://192.168.1.100:5000',
             ex_force_service_type='compute',
             ex_force_service_region='regionOne',
             ex_tenant_name='<my tenant>')

pprint(driver.list_nodes())

Obtaining auth token scoped to the domain

This example show how to obtain a token which is scoped to a domain and not to a project / tenant which is a default.

Keep in mind that most of the OpenStack services don’t yet support tokens which are scoped to a domain, so such tokens are of a limited use right now.

from pprint import pprint

from libcloud.common.openstack_identity import OpenStackIdentity_3_0_Connection
from libcloud.common.openstack_identity import OpenStackIdentityTokenScope

driver = OpenStackIdentity_3_0_Connection(auth_url='http://<host>:<port>',
                                          user_id='admin',
                                          key='<key>',
                                          token_scope=OpenStackIdentityTokenScope.DOMAIN,
                                          domain_name='Default',
                                          tenant_name='admin')

driver.authenticate()
pprint(driver.auth_token)

Talking directly to the OpenStack Keystone API v3

This example shows how to talk directly to OpenStack Keystone API v3 and perform administrative tasks such as listing users and roles.

from pprint import pprint

from libcloud.common.openstack_identity import OpenStackIdentity_3_0_Connection
from libcloud.common.openstack_identity import OpenStackIdentityTokenScope

driver = OpenStackIdentity_3_0_Connection(auth_url='http://<host>:<port>',
                                          user_id='admin',
                                          key='<key>',
                                          token_scope=OpenStackIdentityTokenScope.PROJECT,
                                          tenant_name='admin')

# This call doesn't require authentication
pprint(driver.list_supported_versions())

# The calls bellow require authentication and admin access
# (depends on the ACL configuration)
driver.authenticate()

users = driver.list_users()
roles = driver.list_roles()

pprint(users)
pprint(roles)

A quick note on backward compatibility

If you only use OpenStack compute driver, those changes are fully backward compatible and you aren’t affected.

If you use OpenStackAuthConnection class to talk directly to the Keystone installation, you need to update your code to either use the new OpenStackIdentityConnection class or a version specific class since OpenStackAuthConnection class has been removed.

Libcloud at ApacheCon NA, 2014 in Denver, Colorado

This is just a quick heads up that I will be attending ApacheCon North America, 2014 in Denver, Colorado next month.

I will be giving two talks. First one is titled 5 years of Libcloud. This is retrospective talk where I will tell a story of how Libcloud grew from a small project originally developed for the needs of Cloudkick product into a fully fledged and relatively popular Apache project.

I will go into details on some of the challenges we faced, what we learned from them and how we grew the community and the project.

Second one is titled Reducing barriers to contribution to an Apache project.

To give you some context, I first need to say that I’m a person who loves to move fast and loves lean and efficient approaches and teams. On top of that, I also have zero tolerance for unnecessary / useless processes and deep and mostly useless hierarchies.

All of that means I don’t see myself a big company person, where having useless processes, which among many other things, slow innovation down is usually the norm.

Apache is a relatively big organization which means it has it’s own fair share of (useless) proceses. A lot of “new era” developers who grew up with Github also consider Apache as slow, inflexible and place where projects go to die1.

In this talk I will go into details why this is not totally true and how Apache is (slowly) becoming more flexible and changing to adopt those new work-flows.

On top of that, I will also give some examples on how you can adopt those new work-flows, iterate fast and still receive all the benefits from being an Apache project. Those examples will be taken directly from the things we have learned at the Apache Libcloud project.

Depending on how many people will attend the talk, I think it would also be very interesting to turn this into a panel where other people can contribute their ideas and we can discuss how to reduce barriers even further and make Apache more attractive for “new-era projects”.

Besides my talks, Sebastien Goasguen, a long time contributor to the project who has recently joined the PMC is also giving a talk titled Apache Libcloud.

If you are around, you should stop by to listen to those talks and contribute your ideas to my second talk.


  1. Citation needed. I’m kinda lazy and tired atm, but you can Google it up.

Libcloud Google Summer of Code 2014 Call for Participation

This is call for participation / proposals for all the students who are interested in working on Apache Libcloud project during the Google Summer of Code 2014 program.

Before diving further, I just want to give a short disclaimer. We (Apache Software Foundation and Libcloud as a project) haven’t been accepted into Google Summer of Code 2014 yet, but we will apply, cross our fingers and hope we get a spot.

We will know if we have been accepted on February 24th when Google publishes a list of the accepted mentoring organizations.

What is Google Summer of Code?

Google Summer of Code is a program where Google sponsors students from around the world to spend their summer working on open-source projects. Student is paid 5500$ if they successfully complete all of their evaluations. More information about the program can be found on the project website.

This year is also special, because it’s a tenth anniversary of the program. To celebrate the anniversary, Google is, among other things, giving out 5500$ for successfully completed projects instead of the usual 5000$.

Google Summer of Code and Libcloud

Apache Software Foundation is not a stranger to Google Summer of Code since it has already participated in this program multiple times over the past years.

We (as in Libcloud project) have also participated in GSoC 2014 with one project. I have mentored a student Ilgiz Islamgulov from Russia who has worked and successfully completed (yeah, software is never really done, but in this case completed refers to him passing all the GSoC evaluations) a project called Libcloud REST interface.

If you want to know more about his project and our GSoC 2012 participation, you should check the following links:

Why should I participate / What do I get out of participating in GSoC?

Before looking at our call for proposals, let’s have a look at why you might want to participate in Google Summer of Code program.

For a moment, lets forget about the money and have a look at a couple of other reasons why participating in GSoC is great for you:

  • Instead of spending your summer flipping burgers (or similar) you can spend summer flipping bits (fun!)
  • You will learn how open source projects and communities work
  • You will get experience with working in distributed / remote teams
  • You will get experience with working across different timezones
  • You will make new friends in the open source community
  • It’s a great thing for your C.V. You will be able to show potential employers some concrete things you have worked on.

Libcloud Google Summer of Code 2014 Call For Proposals

This is the part where you, dear students come in. We would like to invite all the students who are interested in participating to start thinking about the things they could work on and start reaching out to the community.

It doesn’t matter if you are already using or contributing to the project or not, everyone is welcome (people who have or are already contributing to the project have a slight advantage though since we already know what they are capable of)!

Only pre-requisite is a good knowledge of Python, HTTP, REST APIs and a basic familiarity with different cloud services such as Amazon EC2 and others.

As noted in the opening paragraph, we haven’t been accepted yet and the student applications will open in about a month. The reason I’m already posting this is because we want to give potential candidates plenty of time to get familiar with the project and the community.

If you would like to participate, now is the right time to start exploring the existing ideas (you are also more than welcome to propose your own ideas), start thinking about the things you could work, getting familiar with the code base and start reaching out to the community.

Other links you might find useful:

New Libcloud website is now live

I’m happy to announce that a new Libcloud website is now live at libcloud.apache.org.

Design and layout wise, previous website hasn’t really changed since 2009 so a makeover was long overdue.

New website.

The new website includes many new features and improvements. One of the more important ones is a new and fully responsive design which means that the content can now also more easily be consumed on devices with smaller resolutions such as mobile phones and tablets.

On top of that the new website is now powered by Jekyll (same as my blog) which makes adding content and many other things easier.

Without further ado, I encourage you to go check out the new website and read the announcement blog post.

Say hello to Živa

This week I made a big decision. I finally decided to get a dog. In this blog post I’m going to introduce you to my new 24kg / 52 lbs heavy fluffy meatball friend called Živa.

Živa on the way to her new home.

Why get a dog in the first place?

First I need to say that I do like cats, but I was always more of a dog person. I always wanted my own dog, but haven’t really had a chance before.

When I still lived at my parents place, I couldn’t do it because we lived in an apartment and my parents didn’t allow it.

Later on when I moved to the US I was thinking of getting a dog again, but after some more thought I decided it would be irresponsible for me to do it. I did have a nice apartment with a patio, but the problem is that dogs need a lot of attention and I wasn’t really planning in staying in the US for the long term. I was working a lot and leaving the dog at home by itself for a half day or more just seems irresponsible to me.

On top of that, finding an apartment and landlord in San Francisco which allows larger dogs is quite hard and makes moving very painful.

Another opportunity showed itself again recently when I moved back to Slovenia. I decided that I want to stay in Europe for the foreseeable future and work from home. On top of that, my landlord here in Ljubljana has no problem with me having a dog inside the apartment.

Working from home means I can dedicate enough attention and love to the dog and that is also one of the main reasons why I decided to get it.

Adopting a dog from a shelter

A lot of people today buy puppies from local dog breeders. The problem is that all puppies are cute and a lot of people don’t realize that dogs are a big responsibility, especially when they grow up. Usually this leads to a lot of dogs being dumped once they grow up.

I’m not like that so I decided to adopt a slightly older dog. In top of that, I believe that dogs living in the shelters need more help so I decided to adopt one from a local shelter.

Before visiting the shelter in person, I have visited the website and immediately fell in love with a lovely young female called Živa. I know that dogs are very similar to people and outside look is not everything so I didn’t keep my hopes too high.

Luckily, when I visited the shelter in person it turned out that she’s one of the friendliest dogs there. Unlike other dogs, she was very friendly, didn’t bark and simply stuck her nose through the fence to greet me.

After getting to know her a little better, I came back on Monday and decided to adopt her.

Živa

Without further ado, lets get to know this lovely (not so) little creature.

Živa is a mixed breed (looks very much like a German shepherd) ~10 months old female which weighs around 24 kg / 52 lbs. She was found on the street and arrived in the shelter about two months ago. Her name is in Slovenian and stands for lively / playful / cheery. She got this name at the shelter and I decided to keep it since it describes her temperament really well.

Resting.

She is a very friendly, quiet and a kind dog, but she also has almost unlimited energy and needs a tons of play time.

Tummy rub time.
Tummy rub time.

Even though she is very friendly she is currently still afraid of a lot of things including moving vehicles, bridges, stairs and so on. Interesting enough, she is not afraid of other people and dogs. She loves to jump on and kiss people :-)

Dat look.

I don’t know her history, but being afraid of so many thing probably means that her previous owner didn’t socialize her much / enough.

First day with a dog

First day was very happy, but also very stressful for both of us. We both didn’t get a lot of sleep (she was constantly checking on me and I was checking on her) and there were some potty accidents. Potty accidents were mostly my fault because I didn’t recognize that she needs to go to the toilet (I thought she just wants to play).

Deer antler is nom nom.
Mmm, bone marrow...

Plans for the future

First couple of days were great, but there is still a tons of things to do in the future. She needs more socializing, I need to train her not to pull and she needs to be trained to not be so afraid of many things.

As far as the pulling goes, I tried some manual approaches without much success. I’ve ordered an anti pull harness which goes around her front legs and doesn’t hurt her. Hopefully that will help.

On top of that, I also plan to take her to the dog school. The dog school is actually more for me than her (this is my first dog).


For older posts, visit the Archive page.