Design Summit/Folsom/DevOps

DevOps at the Folsom OpenStack Design Summit

Mail List Input

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