Jump to: navigation, search

Difference between revisions of "Design Summit/Folsom/DevOps"

 
(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.

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

Accepted Tracks