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 https://drive.google.com/folderview?id=0Bxy1qS0O_cnlbGFaVXd3RzMtQ2c&usp=sharing of the slides that were presented. Notes on the talks are also in the etherpad https://etherpad.openstack.org/p/juno-midcycle-policy-summit.

• 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.

http://youtu.be/7m9q1aOhDbo?

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 https://etherpad.openstack.org/p/juno-midcycle-policy-summit.