Jump to: navigation, search

Difference between revisions of "Operations"

m (Documentation)
(Fix the link to the operations guide)
Line 12: Line 12:
* [http://docs.openstack.org/ops/ OpenStack operations guide], a must-read
* [https://docs.openstack.org/operations-guide/index.html OpenStack operations guide], a must-read
* [http://docs.openstack.org/arch-design/content/ OpenStack architecture design guide]
* [http://docs.openstack.org/arch-design/content/ OpenStack architecture design guide]
* [http://docs.openstack.org/security-guide/content/ OpenStack security guide]
* [http://docs.openstack.org/security-guide/content/ OpenStack security guide]

Latest revision as of 21:47, 12 September 2018

So you're an operator using OpenStack. This page is an attempt to collect recommendations for how to have a good experience running OpenStack.


There is a dedicated mailing list for operators, go to http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators to subscribe. You can also dig the archives which contain plenty of valuable information.

There is the #openstack-operators channel on IRC for live conversations. There is also a biweekly team meeting. (ancient meeting logs here)

Since Juno, operators gather during the Design summit for an official Operators meetup, and somewhere mid-cycle. They can discuss together as well as with OpenStack developers and contributors. Check the Operations/Meetups page for more information.

There are also a number of working groups you can participate in.


Use Cases

Operators have a variety of things they need to do on a day to day basis. Tracking and classifying these will offer important insight for the developers. Check them on Operations/UseCases.


A list of tools developed to help with day-to-day OpenStack Operations tasks.


There have been a few discussions specifically about Monitoring at the Operations/Meetups.

Working Groups

These working groups are specific to Operators and function.

Bug reporting

First check the Bugs#Reporting page. It is often hard for developers to help with bugs filed from operations staff unless they include as much information about the problem experienced. You'll also find that your bug will get more attention if you use the right tags so that its visible to the developers.


  • please include the version you're running (both OpenStack release, and where you got the packages from if relevant).
  • tag the bug with the "ops" tag. When reporting a new bug, you need to expand the "extra options" field to add a tag (see image). For an existing bug, the "Add tags" link is right after the bug's description (see image).
  • if you think the bug is trivial, for example a log message emitted at the wrong level, please tag it as "low-hanging-fruit" as well.
  • include any logs which seem relevant.
  • describe your production environment -- what database you use, approximately how many machines, and so on.
  • subscribe the 'openstack-ops' Launchpad team to the bug.
  • If you know that other people are also affected by the bug, encourage them to go to the Launchpad bug page and click on the "Does this bug affect you?" link (see image). This will increase the "heat" of the bug which is an indication of importance for developers.

See Operations/Bugs to get the list of bugs tagged with 'ops'.

Example Configs

The OSOPS Git repository has a selection of real configs you can look at : http://git.openstack.org/cgit/openstack/osops-example-configs