Austin OpenStack Meetup: Keystone & Knife (2/20 notes via Greg Althaus)

I could not make it to the recent Austin OpenStack Meetup, but Greg Althaus generously let me post his notes from the event.

Background

• Sponsors: Canonical & Dell
• Speakers:  Joseph George – Dell, Ameet Paranjape - Canonical, Matt Ray – Opscode, Ziad Sawalha – Rackspace
• Attendance: 30 people
• Videos: Jeff Kramer > http://www.jeffkramer.com/2012/02/17/openstack-austin-meetup-videos/

Matt Ray talks about Chef

Matt Ray from Opscode presented some of the work with Chef and OpenStack. He talked about the three main chef repos floating around. He called out Anso’s original cookbook set that is the basis for the Crowbar cookbooks (his second set), and his final set is the emerging set of cookbooks in OpenStack proper. The third one is interesting and what he plans to continue working on to make into his public openstack cookbooks. These are an amalgamation of smokestack, RCB, Anso improvements, and his (Crowbar’s).

He then demoed his knife plugin (slideshare) to build openstack virtual servers using the Openstack API. This is nice and works against TryStack.org (previously “Free Cloud”) and RCB’s demo cloud. All of that is on his github repo with instructions how to build and use. Matt and I talked about trying to get that into our Crowbar distro.

There were some questions about flow and choice of OpenStack API versus Amazon EC2 API because there was already an EC2 knife set of plugins.

Ziad Sawalha talks about Keystone

Ziad Sawalha is the PLT (Project Technical Lead) for Keystone. He works for Rackspace out of San Antonio. He drove up for the meeting.

He split his talk into two pieces, Incubation Process and Keystone Overview. He asked who was interested in what and focused his talk more towards overview than incubation.

Some key take-aways:

• Keystone comes from Rackspace’s strong, flexible, and scalable API. It started as a known quantity from his perspective.
• Community trusted nothing his team produced from an API perspective
• Community is python or nothing
  • His team was ignored until they had a python prototype implementing the API
  • At this point, comments on API came in.
• Churn in API caused problems with implementation and expectations around the close of Diablo.
  • Because comments were late, changes occurred.
  • Official implementation lagged and stalled into arriving.
• API has been stable since Diablo final, but code is changing. that is good and shows strength of API.
• Side note from Greg, Keystone represents to me the power of API over Code. You can have innovation around the implementation as long all the implementations have a fair ground work to plan under which is an API specification. The replacement of Keystone with the Keystone Light code base is an example of this. The only reason this is possible is that the API was sound and documented.  (Rob’s post on this)

Ziad spent the rest of his time talking about the work flow of Keystone and the API points. He covered the API points.

• Client to Keystone, Keystone to Client for initial auth token
• Client to Middleware API for the services to have a front.
• Middleware to Keystone to verify and establish identity.
• Middleware to Service to pass identity

Not many details other then flow and flexibility. He stressed the API design separated protocol from actions and data at all the layers. This allows for future variations and innovations while maintaining the APIs.

Ziad talked about the state of Essex.

• Planned
  • RBAC (aka Role Based Access Control)
  • Stability
  • Many backends
• Actual
  • Code replacement Keystone Light
  • Stability
  • LDAP backend
  • SQL backend

Folsum work:

• RBAC
• Stability
• AD backend
• Another backend
• Federation was planned but will most likely be pushed to G
  • Federation is the ability for multiple independent Keystones to operate (bursting use case)
  • Dependent upon two other federation components (networking and billing/metering)