Last week, the OpenStack Austin user group discussed what we’d like to see at the upcoming OpenStack Design Summit. We had a strong turnout (48?!).
- To get the meeting started, Marc Padovani from HP (this month’s sponsor) provided some lessons learned from the HP OpenStack-Powered Cloud. While Marc noted that HP has not been able to share much of their development work on OpenStack; he was able to show performance metrics relating to a fix that HP contributed back to the OpenStack community. The defect related to the scheduler’s ability to handle load. The pre-fix data showed a climb and then a gap where the scheduler simply stopped responding. Post-fix, the performance curve is flat without any “dead zones.” (sharing data like this is what I call “open operations“)
- Next, I (Rob Hirschfeld) gave a brief overview of the OpenStack Essex Deploy Day (my summary) that Dell coordinated with world-wide participation. The Austin deploy day location was in the same room as the meetup so several of the OSEDD participants were still around.
- The meat of the meetup was a freeform discussion about what the group would like to see discussed at the Design Summit. My objective for the discussion was that the Austin OpenStack community could have a broader voice is we showed consensus for certain topics in advance of the meeting.
At Jim Plamondon‘s suggestion, we captured our brain storming on the OpenStack etherpad. The Etherpad is super cool – it allows simultaneous editing by multiple parties, so the notes below were crowd sourced during the meeting as we discussed topics that we’d like to see highlighted at the conference. The etherpad preserves editors, but I removed the highlights for clarity.
The next step is for me to consolidate the list into a voting page and ask the membership to rank the items (poll online!) below.
Brain storm results (unedited)
Stablity vs. Features
API vs. Code
- What is the measurable feature set?
- Is it an API, or an implementation?
- Is the Foundation a formal-ish standards body?
- Imagine the late end-game: can Azure/VMWare adopt OPenStack’s APIs and data formats to deliver interop, without running OpenStack’s code? Is this good? Are there conversations on displacing incumbents and spurring new adoption?
- Logo issues
Documentation Standards
- Dev docs vs user docs
- Lag of update/fragmentation (10 blogs, 10 different methods, 2 “work”)
- Per release getting started guide validated and available prior or at release.
Operations Focus
- Error messages and codes vs python stack traces
- Alternatively put, “how can we make error messages more ops-friendly, without making them less developer-friendly?”
- Upgrade and operations of rolling updates and upgrades. Hot migrations?
If OpenStack was installable on Windows/Hyper-V as a simple MSI/Service installer – would you try it as a node?
- Yes.
Is Nova too big? How does it get fixed?
- libraries?
- sections?
- make it smaller sub-projects
- shorter release cycles?
nova-volume
- volume split out?
- volume expansion of backend storage systems
- Is nova-volume the canonical control plane for storage provisioning? Regardless of transport? It presently deals in block devices only… is the following blueprint correctly targeted to nova-volume?
https://blueprints.launchpad.net/nova/+spec/filedriver
Orchestration
- Is the Donabe project dead?
Discussion about invitations to Summit
- What is a contribution that warrants an invitation
- Look at Launchpad’s Karma system, which confers karma for many different “contributory” acts, including bug fixes and doc fixes, in addition to code commitments
Summit Discussions
- Is there a time for an operations summit?
- How about an operators’ track?
- Just a note: forums.openstack.org for users/operators to drive/show need and participation.
How can we capture the implicit knowledge (of mailing list and IRC content) in explicit content (documentation, forums, wiki, stackexchange, etc.)?
Hypervisors: room for discussion?
- Do we want hypervisor featrure parity?
- From the cloud-app developer’s perspective, I want to “write once, run anywhere,” and if hypervisor features preclude that (by having incompatible VM images, foe example)
- (RobH: But “write once, run anywhere” [WORA] didn’t work for Java, right?)
- (JimP: Yeah, but I was one of Microsoft’s anti-Java evangelists, when we were actively preventing it from working — so I know the dirty tricks vendors can use to hurt WORA in OpenStack, and how to prevent those trick from working.)
CDMI
Swift API is an evolving de facto open alternative to S3… CDMI is SNIA standards track. Should Swift API become CDMI compliant? Should CDMI exist as a shim… a la the S3 stuff.
Rob Hirschfeld 