How Operators Can Get Involved in Kilo OpenStackSummit

I participated on Monday in the Ops Summit: How to get involved in Kilo, and as these sessions are not recorded I wanted to convey the messages that were conveyed at the session.


But first, the Ops Summit is a mini 2-day set of sessions that were introduced at the previous summit to get the feedback of the people actually using OpenStack and their problems and issues that they are encountering. A great and formidable initiative on the part of the Foundation – still it is one that I think should be done before you start developing code, but that is only my humble opinion.

There were a lot of the PTL’s and TC members there, showing that they are serious and listening to the community – not the developer community, but rather the Operators.

I raised the following question in the session.

Being an operator – a guy that uses, deploys, manages, troubleshoots and supports OpenStack. I do not have developer experience, I do not have a team of developers at my disposal.

How would you (“Openstack”) want us to contribute?

The feedback was that they would like hear the problems we are having, submit the user stories, the issues, the pain points back to the developer community. This can be done by submitting bugs, by asking the questions on or on the IRC channels.

Tell your stories, publish what you have achieved, and even post the problem that you encountered, and answer your own question if you solved it. The receives a lot of Google traffic so it makes things easier for others to find.

Another item that was raised was that the TC would like to see more Operator feedback on the specs that are being added for each cycle. There is a new portal where all the proposed blueprints are being published – in a nice and collated fashion.


They are organized per project and will point you to blueprint in question. They ask that you leave your feedback. I actually find this to be misleading. Where do I leave feedback? On that page? On the blueprint? On the Gerrit discussion?

There was some feedback towards the PTL’s and the TC from the audience regarding the fact when people do submit blueprints and bug fixes (especially newbies) the probability of receiving negative reviews (-1’s) on the submission – for what ever reason - is very high. Something that perhaps could be addressed and make the process more “welcoming”.

The one thing that I found was missing – and again it is a recurring theme here that I am coming across, throughout the summit. And I think that this is a major flaw in the way these things are being done at the moment.

No-one said – give us feedback as to what you are interested in getting into OpenStack,
before we actually start writing the code.

Not after the code has been written.

This does not mean that it will be implemented – but at least you are developing for a use case. An actual use case.

Will someone use what is being written? Is the code actually going to be useable? If not what is missing to make it an adopted feature?

More on this in following posts.