OpenStack Juno Mid-Cycle Policy Summit

[This post was written by Tim Hinrichs, with contributions from Pierre Ettori, Scott Lowe, Sean Roberts, and Alex Yip.]
A couple of weeks ago (Sept 18-19) we hosted a 2-day summit focused on policy in OpenStack.  The goal was to give policy-minded people the opportunity to get together, learn about what others were doing, and brainstorm about how we could improve the future of policy in OpenStack.  We had 80+ participants from 30 different organizations.

The first day aimed at level-setting–giving everyone a chance to learn about the policy capabilities of several different OpenStack projects.  We had leads from each of the following projects speak and answer questions about the current and future state of policy for their project.  We have made an archive of the slides that were presented. Notes on the talks are also in the etherpad

  • Nova (compute): Joe Gordon,
  • Swift (storage): John Dickinson
  • Group-based Policy (networking): Sumit Naiksatam
  • Heat (applications/orchestration): Clint Byrum
  • Congress (policy): Tim Hinrichs

We broke for dinner in downtown Palo Alto. We made point of enjoying ourselves while talking business as little as possible. Good food, drink, and company carried the evening.

The second day began with Rao Mikkilineni from C3DNA gave a lightning talk on policy.  Rao described his team’s approach to the policy problem and distributed policy objects.

Martin Casado then joined us to reprise parts of his policy keynote from the OpenStack Silicon Valley event a few days before.  Here is the full video of his talk from the OpenStack Silicon Valley community event.

He began this talk by describing how the policy problem has been around since the dawn of the datacenter. The main issues that have prevented Datalog-based systems from implementing automating policy are device canonicalization, distributed state management, and the need to have policies that are independent of network topology. Since OpenStack goes a long way toward solving all three problems, it makes it possible for the first time to automate the policy problem by reducing it to a language problem.

After Martin’s keynote, we entered the brainstorming portion of the summit, where we aimed to take what we had learned from lectures and Q&A to help us understand holistically how OpenStack could provide rich, cogent policy support in the future.  We began by thinking about OpenStack from the perspective of its users and built a policy-centric use case that required all the projects discussed on the first day to interoperate.  The use case was based on the premise that there are many different users/personas/stakeholders that all have different policies they want enforced:

  • Application-developer: My 2-tier PCI app (database tier and web tier)can be deployed either for production or for development.  When deployed for production, it needs
    • solid-state storage for the DB tier
    • all ports but 80 closed on the web tier
    • no network communication to DB tier except from the web tier
    • no VM in the DB tier can be deployed on the same hypervisor as another VM in the DB tier; same for the web tier
  • Cloud operator
    • Applications deployed for production must have access to the internet.
    • Applications deployed for production must not be deployed in the DMZ cluster.
    • Applications deployed for production should scale based on load.
    • Applications deployed for development should have 1 VM instance per tier.
    • Every application must use VM images signed by an administrator
  • Compliance officer
    • No VM from a PCI app may be located on the same hypervisor as a VM from a non-PCI app.

Then we broke out into different groups, each of which tweaked the use case and looked at how particular policy efforts would need to interact in terms of workflow, architecture, algorithms, protocols, etc. to realize that use case.  We ended up with four groups:

  • Networking (which further divided into 2 subgroups, focused on different levels of abstraction for writing policy about network traffic)
  • Compute/Storage/Applications
  • Security

At the end of a lively and engaging second day, each group had identified action items (most of which were writing specs–feature requests) and volunteers for writing them up.  We’re in the process of following up on those action items right now.

All told, the event was a great success.  The level of engagement on the second day was truly exciting.  It was a smart, passionate group of people who showed up to help make OpenStack policy-aware, and we’re looking forward to continuing that work.  For more details, you can look through the etherpad notes

OpenStack Kilo Summit Talks

These are talks I am involved in. I ask that you help vote them up as they represent important topics for the OpenStack community.

Congress defines the desired state of a cluster. Join us to work on this important project.
Congress:Policy as a Service

Developers have managers that define what they work on. It’s in our best interest to get the managers synched with what the developers sign up for at the summits. Let’s discuss ways of improving this.
Hidden Infuencers

Hear from from the organizers from successful user groups.
Panel: Tips and Tools for Building a Successful OpenStack Group

OpenStack Ambassadors represent the user groups from around the world. Find out what’s planned to increase the community involvement and spread OpenStack farther and wider.
Meet the OpenStack Ambassadors

An update on the OpenStack Community Training project. What has worked and what is planned.
OpenStack training – Open Source training an enablement for OpenStack

Why I left Yahoo for VMware

I work in the open source community with OpenStack. This gives me the freedom to do my work at Yahoo or any of the other great companies that are doing work in this field. It’s a role I relish and have a lot of fun doing. I have not always been this committed to open source and its ideals. I thank Joshua McKenty, Jonathan Bryce, Mark Collier, Lauren Sell, and the other great people of the OpenStack community for my conversion. Now that I am of the converted, I have a long list of ideas and projects I want to develop and work on. Yahoo was a good place for me to start, but it is time for me to move on to be able really focus on OpenStack.

That being said, I love working at Yahoo. If I could go back in time and change things, I would not. The sometimes bumpy path has allowed me to grow and learn. Many of the friends and colleagues I have now are a direct result of the indirect path I have taken. Yahoo has changed my life in many positive ways. I know Yahoo will continue to grow and thrive. Since Marissa Mayer has taken the helm, we the employees have felt and believed in the surge in pride and enthusiasm.  There are many good people at Yahoo that I will be leaving behind. It’s been a great 4+ years and it’s time for me to take on some new challenges.

Preeti Somal will be taking over representing Yahoo on the OpenStack board. She will be a strong voice on the board and I welcome her. I will move to VMware working with Martin Casado and other Nicira people. VMware and Nicira have a long history of development and innovation. I will be part of a new chapter focusing on open source and OpenStack. I am looking forward to being a strong partner with OpenStack.

I will continue to support the same training and congress projects in my new role with developers and code. The support of the SFBay OpenStack user group, OpenStack Ambassadorship, and the leadership of the community training guides will go with me to VMware. I am firmly committed to making OpenStack world-class and moving to VMware will allow me to focus on doing just that.

Feel free to comment here.

OpenStack is turning 4

It’s a birthday, so we are throwing a party! Join us 7-10pm, 30 July 2014, at the 111 Minna Gallery in San Francisco to celebrate the event. Speakers will include Randy Bias, Joshua McKenty, Monty Taylor, Chris Kemp, Alex Freedland, and Sean Roberts. Light food and drinks will be served.
There is limited room, so you must RSVP at

See you there!

OpenStack Operators Mid-Cycle Summit

The Operators Summit is all about getting the implementors input into the development cycle. We ran the first one about six months ago and was a great success. Come and join us, but be prepared to interact with the group. This is very much a round table discussion, rather than a series of talks. If you run an OpenStack cloud, join us at Rackspace on August 25 & 26 in San Antonio, Texas. If you do not run a cloud, then we will catch you next time at either one of the many OpenStack user group meetings or at the Paris Summit.

We need to finalise the agenda and start advertising it very soon. If you’re interested in running a session, edit and add your name under volunteers.

Register by 29 July at

For additional details reach out to and

Widening the Engagement of the Hidden OpenStack Influencers

This is a follow-up post to the OpenStack Hidden Influencers post.

After the OpenStack July Gold Membership meeting today, the problem of engaging the developer community line management seemed a bit clearer to me.

The Enterprise / OpenStack User Committee research that Intel has been spearheading is a useful model to copy for other verticals like Telecommunications and High Performance Computing. I expect we will see more focus on these other areas soon. Requirements for Enterprise adoption are being gathered for the summit. These requirements will go to the development teams. The communication will be through specs/blueprints and design sessions. Including the OpenStack Mid-Cycle Operators Summit. We need to also get the requirements to the development line management. Can it be as simple as a mailing list? I think so.

These all seem like known mechanisms that will be easy to explain and follow. New areas of focus like OpenStack and Media Production, copy what the Enterprise / User Committee did. New companies and new groups of developers getting involved, get on the mailing lists and projects just like normal. Full coverage without any new process or stuff. I will be following up on the OpenStack Community mailing list and through my comrades Allison Randal and Rob Hirschfeld. Unless something changes, expect a new mailing list for the developer line management by the end of the week.

Hidden Influencers

After the summit (#afterstack), a few of us compared notes and found a common theme in an underserved, but critical part of the OpenStack community.  Sean Roberts, Allison Randal, and Rob Hirschfeld committed to expand our discussion to the broader community.  Instead of sharing a single post, we wanted to bring our individual perspectives to you and start a dialog. See Rob’s post http://robhim/2014/07/01/hidden-influencers and Allison’s post

Besides a long, productive week followed with an afterparty that resulted in domain procurements and a few drinks imbibed, we found a gap. There is a gap between the release management and the business outreach. It is something akin to a strategic technical leadership and product management. The coordination of multi-release, cross-project, cross company work is critical for openstack momentum. Building on the discussions from the Atlanta Summit, Rob Hirschfeld and myself dug deep during an OpenStack user group meeting the night of 05 June 2014 and we developed these thoughts on the strategic gap. These thoughts explain different aspects of getting their line management inline with OpenStack.

The “Hidden Influencers” or line management for the OpenStack committers are generally left out of the summit plans that the committers and Project Technical Leads make at each design summit. This means the intent of the committers to work is not inline with the people who are responsible for actually committing the time. This lack of alignment between committers and their line management throws a wrench into getting a timely release with the features and code promised. It important to note, that as the summit energy and collaboration happens the committer enthusiasm is high. Even if the committer line management is out of the loop, the committer will plan on using his/her own time. This is means the committer have the best of intentions to follow through and hit the milestones as promised. Reality is though, as the release cycle wears on it is harder to keep the enthusiasm up. Including the committer line management into the release cycle demands and commitments of the developers, will insure that we get more of the follow through efforts required to land the code by the milestones.

Uncovering OpenStack’s Hidden InfluencersThe “Flow” of the projects and their features happens due to the public OpenStack release management cycle. The developers need to get their line management in-sync with the cycle of OpenStack so the flow of effort and code does not get out of phase. The diagram is my way describing my desire to do great work and get all of my ideas to “paper”, but the reality is that between the summits my enthusiasm gets sapped by the day-to-day grind of getting things done. If my line management isn’t there helping me with that daily grind, it makes it all that much harder. Even worse, my line management may start tasking me with differently things that take me even further from success. I want my line management to be supportive and understand that I need help during the middle months in order to meet my milestone commitments.

Understanding the “time to ingest the upstream community” efforts for any company requires the line management to be involved during the very early stages of the release cycle. The line management can then understand that during the public OpenStack release cycle, when they will be able to land the features for their own distributions and releases. As a involved OpenStack committer, I should be steeping my line management as soon as possible in the features and how we can take advantage of them. This is a possible task for all of us post summit. I know I try. But recognize that the summit intents meet the lag of first post month. It may not follow through as expected. The line management will understand the process and the fall out of features that didn’t make the cut if they are involved at the very early stages of the release.

I have made a stab at explaining who has been left out of the OpenStack release management process. I then cut up the problem into a few pieces to explain why I think it is important. I also fed you some ideas on how and when to fix the problem. In summary, I believe that we can improve and balance our enthusiasm and effort by involving our line management in the OpenStack release cycle.