Difference between revisions of "Design Summit/Folsom/DevOps"
< Design Summit | Folsom
(added notes from duncan and matt) |
|||
Line 3: | Line 3: | ||
== Mail List Input == | == Mail List Input == | ||
− | * | + | |
+ | 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 == | == Proposed Tracks == |
Revision as of 17:41, 10 April 2012
DevOps at the Folsom OpenStack Design Summit
Mail List Input
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.
- maybe we can see some integration with groups like the IEEE
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