My take on OpenStack projects, Congress

This is the first of a ten part series on OpenStack projects. There are critical OpenStack projects that get a bit lost in the noise. I aim to highlight why these projects are important and how you can get involved.

I am starting with the policy management project named Congress. Tim Hinrichs and Peter Balland are leading this effort. It was semi-formally kicked off at an Icehouse unconference this last November 2013. Those early etherpad notes can be found here.

The project provides a governance tool for OpenStack through business logic described by application affinity. It uses a high level declarative language based on Datalog. The language is to be as close to english as possible. It is meant to work for any collection of cloud services. Congress policy management will work with the OpenStack projects policy management equivalents to either proactively or reactively implement said policies. Proactive examples would be Nova querying Congress before scheduling an instance or Keystone intercepting API calls to prevent policy violations. Reactive examples would be a software upgrade when a new code is available or RabbitMQ reporting on message bus traffic.

Nova, Keystone, Heat, and Neutron all have some blueprints and functionality that Congress can coordinate with right now. I am most interested in Neutron. I will explain further in a future post on Neutron.

If you are interested in OpenStack policy management, then you need to get involved. Your participation can range from providing background on what operators need in the bi-weekly meetings and/or to contributing code. This project is still in its early stages, but it represents a critical function for OpenStack clusters to support state management and SLAs. Right? If you are an operator and you can only contribute a bit of your time, then this is the project for you to get involved in.