Design Summit/Folsom/DevOps

DevOps at the Folsom OpenStack Design Summit

Mail List Input

From Tim Bell:

Splitting monitoring into

1. Gathering of metrics (availability, performance) and reporting in a standard fashion should be part of OpenStack.
2. Best practice sensors should sample the metrics and provide alarms for issues which could cause service impacts. Posting of these alarms to a monitoring system should be based on plug ins
3. Reference implementations for standard monitoring systems such as Nagios should be available that queries the data above and feeds it into the package selected

Each site does not want to be involved in defining the best practice. Equally, each monitoring system should not have to have an intimate understanding of OpenStack to produce a red/green light. The components for 1 and 2 fall under the associated openstack component. Component 3 is the monitoring solution provider.

From David Kranz:

• cluster health and monitoring
  • I did a bunch of stuff with Swift before turning to nova
  • really appreciated the way each swift service has a "healthcheck" call that can be used by a monitoring system
  • I don't think providing a production-ready monitoring system should be part of core OpenStack
  • However, it is the core architects who really know what needs to be checked
  • it would be a big improvement for deployers if:
    • each openstack service provided healthcheck apis
    • these were based on expert knowledge of what is supposed to be happening inside
    • this would also insulate deployers from changes in the code that might impact what it means to be running properly

From Matt Joyce:

• security governance in openstack
  • "encrypt all REST APIs" is not really acceptable
  • there needs to be some standardization of what is supported as an encryption procedure
  • important for people developing hooks into those APIs
  • this is not a problem with the APIs; it's a problem with security governance
• poorly defined procedure for proposing, discussing, and approving a standard
  • we need something akin to an RFC model
  • possibly based on PEP approach?
  • current process is a mix of
    • developer specific conversations
    • no single authoritative source for information clearly identified
    • on the rare occasion there is, it changes fairly quickly
• seems to be a lot of "act first, ask for input later" going on in development
  • maybe we can see some integration with groups like the IEEE
    • for specifying some standards for cloud orchestration, e.g.

From Duncan McGreggor:

• API pains
• changes to existing tools
• the creation of new tools
• the proposal of a new sub-project around operational and host

Proposed Tracks

• Common image properties
• OpenStack and Operations: Input from the Wild - needs to be split up into multiple sessions
• High Availability in OpenStack
• Federated Zones—meta-affinity with ServiceCatalogs
• Making the configuration of openstack easier
• Base Packaging Guidelines
• Efficient metering for Nova and Swift

Accepted Tracks

• Common image properties
• High Availability in OpenStack
• Federated Zones—meta-affinity with ServiceCatalogs
• Making the configuration of openstack easier
• Base Packaging Guidelines
• Efficient metering for Nova and Swift