[Openstack-operators] [osops] OSOps Meeting Notes from Summit
Steven Dake (stdake)
stdake at cisco.com
Tue May 10 04:17:09 UTC 2016
From: Joseph Bajin <josephbajin at gmail.com<mailto:josephbajin at gmail.com>>
Date: Monday, May 2, 2016 at 8:06 PM
To: OpenStack Operators <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: [Openstack-operators] [osops] OSOps Meeting Notes from Summit
I wanted to provide some updates to the OSOps Operators Meeting that was held last week.
You can find the etherpad located here. 
The highlights of the meeting were the following:
- People see OSOps as an advocation group for patches, tools, and features that operators need to get done.
- The OSOps group should pick a topic and work on getting that issue resolved for the Operator community to help kick off the group's work.
Feel free to borrow our defaults for all the services we implement. They are conditional and have variable replacement at present, and I'm not sure how we could make them not-so in Kolla itself and still have a functional system. One option for you to consider is to just keep them as jinja2 files and define the variables to replace. We have a policy of not adding a bunch of variables to our system so this wouldn't become onerous for you. See:
An example set of configuration files is here for keystone:
Feel free to reach out to the kolla community on irc at #openstack-kolla if you have questions, comments, or concerns with our defaults. I'd like to see this effort produce a common set of defaults all the projects could use. I think OSAD also has some good pre-defined defaults which could be borrowed and merged in.
If you have an irc channel formed, let me know, and I'll put it in our topic for other interested in deployment operations.
- The repo's that OSOps maintains can be used to help in a few different ways. One primary one mentioned was configuration files. Providing bare minimum configuration files to use as a sanity check. The Kolla project can help produce a few of these to jumpstart the project.
- Documentation Issues - Help facilitate the update of missing documentation.
- Provide packaging examples that could eventually work into a framework for operators to use to pull upstream and apply patches. We are not talking about finding one method, but providing options for operators to choose.
Lots of great feedback in both sessions. The first session was around how OSOps can help the provide information to and from projects for them to review. The second half was held to find other ways that OSOps can help and utilize the current repo's to give Operators more tools to better manage their environments.
Anyone with additional feedback or would like to help is welcome to join the upcoming OSOps Meeting.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators