LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
State of the Stack v4 - OpenStack in All It's Glory
CCA - NoDerivs 3.0 Unported License - Usage OK, no modifications, full attribution*
* All unlicensed or borrowed works retain their original licenses
State of the Stack
May 20th, 2015
OpenStack Summit, Spring 2015
With signiﬁcant help from many Cloudscalers and EMCers. Thank you!
The Randy Bias
• Built big clouds; production clouds
• An OpenStack Original
• part of launch in 2010, on Foundation Board since formation
• built some of the largest and earliest OpenStack clouds
• Top <insert number here> cloud/twitter/pioneer/visionary
• you pick…
Fastest Growing Open Src Community
TOTAL DEVELOPERS AVERAGE MONTHLY
TOTAL CODE CONTRIBUTIONS
3,654 >600 125,000+
502 TOP 10 COUNTRIES
United States, India, China, United
Kingdom, France, Russia, Canada,
Germany, Japan, Australia
Infrastructure as a Service
Advanced Services (Consume IaaS)
Image Management: Glance
Common/Shared: Identity: Keystone Common Libraries: Oslo
UI API CLIKilo
– Me / Ako / Moi / Yo *
“OpenStack is at risk of
collapsing under its own weight.”
Lots of Improvements
• Product WG formed
• Create an aggregation point for longer term planning, bring user
feedback into process, prioritization of blueprints, lobbying TC and
PTLs for work queues, “funding” of key blueprints, etc.
• Integrated release & 6-month cycle reformed to “Big Tent”
• No more forced 6-month integration, more project autonomy,
encouragement of 3rd party integration testing of drivers, tagging for
Product Working Group
N+3 members: 3 selected by the board, the TC and an additional nominated representative. An additional N
members elected by the user community.
Focused teams to gather user requirements from
segments and represent them
Telco / OPNFV
API Working Group
Working Groups to address a particular requirement set.
These WGs should have a target set of deliverables and
conclude when those are met. Maintenance should be a
function of the regular workflows.
Product Working Group
Gather requirements from both sets of WGs (Segment and Requirement Oriented) above in the form of user
stories, work with cross-project team to populate blueprints from user stories across projects, work to identify
developers to help complete blueprints, communicate with project PTLs and core team to collect feedback on
future directions, and compile this data into a multi-release roadmap that is publicly available. In summary,
facilitate a feedback loop between projects, user community, and working groups.
“Big Tent” Release Cycle Reform
Solving for “How do we allow for the additional projects in the future without breaking down?”
(Current) Tag Categories:
integrated-release Frozen tag, not given to new projects. Identiﬁes projects that were integrated prior to Kilo.
release: indepdent Projects with this tag “release as needed” and don’t have to coordinate with other projects.
Projects that commit to being a part of a coordinated release every 6 months. They can still have intermediate
releases independent of the 6 month cycle “ﬁnal” release.
release: has-stable-branches Projects that have stable branches (from the last release in the cycle)
release: managed Projects that agree to follow the processes/timelines outlined by the OpenStack Release Management Team
This tag shows that the developer team for the project is from a diverse set of organizations (1 < 50% and 2 < 80%).
This is tested every 6 months.
Details at http://governance.openstack.org/reference/tags
How Do We Know?
• Growing skepticism from analysts, reporters, and pundits
• Growing dissatisfaction with certain aspects of OpenStack
• Lots of failures in the ﬁeld, enough to be worrisome
• Peak OpenStack?
• 6K+ attendees, early signs of slow down in adoption?
• Decide for yourself; I could be calling it early
The Growing Skepticism
Linthicum believes that despite the fact that OpenStack has "the only game in
town" for open source, the implementation hasn't met up to all of the hoopla since
OpenStack can run a ﬁne private cloud, if you have lots of people to throw at the
project and are willing to do lots of coding, according to Alan Waite, a research
director at Gartner.
OpenStack has the following drawbacks as a platform on which to build a private cloud*:
1 Difﬁculty of implementation
2 Shortage of skills available in the market
3 Conﬂicting or uncoordinated project governance
4 Weak spots in some projects
5 Integration with existing infrastructure *Recent Q1’2015 Gartner Report
OpenStack Self-Improvement Survey
• determine if and where project dissatisfaction exists
• report back to provide perspective on where we need to change
• After 10 days:
• 65+ respondents w/ 30 months average time with OpenStack
• Survey: http://tinyurl.com/improve-openstack [ TAKE ME! ]
How Would Your Characterize Your Participation in
OpenStack End-User (MIA)
Pundit, Analyst, Reporter, OpenStack Evangelist, or Groupie
Average Time Working With OpenStack:
What is Your MOST favorite OpenStack Project?
0 4 8 12 16
What is Your LEAST favorite OpenStack Project?
0 4 8 12 16
User Survey Feedback
• “Neutron is a lot more complex and harder to provide real HA” – Survey
• “Complexity, availability and scalability remain some of the concerns [ of
the operators during the Operator Meetup in March ]” – User Survey
• “adoption has not been rising as quickly as expected … dozens of
comments related to stability and reliability, particularly at scale.” – User
Technology Adoption Curve 101
Need to get here!!
Path to the Plateau of Productivity
Plan Item Objective
#1) Streamlining Governance Model
empower projects, scale TC, focus Product WG, focus
Board and Foundation on marketing and interoperability
#2) Allow Competition
force poor projects to evolve or die, allow other projects,
particularly non-Python to come under our “big tent”
#3) Conform to Well Known APIs
don’t create new APIs in places where they exist (e.g.
#4) Testable Reference Architectures
allow for vertical and horizontal-speciﬁc OpenStack
reference implementations and separate infrastructure from
#5) Ruthless Simpliﬁcation
downloadable “OpenStack Basic IaaS” should be 1-click
download and install to run a POC/trial on a simple stack (1
switch, 10 servers)
18 Categories (including retired), 252 Projects
The ASF Scales
To Manage This… You Need This.
Allow Competing Projects & Multiple Languages
• Competition is good; pretending our shit doesn’t stink is bad
• Poor projects must die; survival of the ﬁttest works
• There is already leeway for this:
• “Where it makes sense, the project cooperates with existing projects rather than
gratuitously competing or reinventing the wheel.”*
• i.e. Competitive projects are OK as long as they have good reason
• Python isn’t good for everything
• A bigger tent means allowing non-Python projects
• Swift is already experimenting with re-writing pieces in Go Language (golang)
–Thierry Carrez, Chairman of the TC, Foundation Release Manager
“OpenStack is about community, common values, and a common
• Seriously … WTF?
• There are dozens of well known, documented, scalable, tested, standard APIs for
• OAuth1/2, SAML, Kerberos
• There is no excuse for creating something from whole cloth
• Google is secure as hell and they use OAuth 2.0
• You aren’t better at security than the Google team; sorry
• We don’t apply this standard to our community (completely new Nova API anyone?)
Example Reference Architectures
OpenStack Interop Standard RA “Key” Components
1+ of Nova/Magnum/Ironic
OAuth 2.0 Server (Keystone or other)
OpenStack Basic IaaS
Neutron (or an alternative?)
OAuth 2.0 Server (Keystone or other)
Zaqar, Trove, Designate, OAuth2.0 Horizon
Heat, Murano, Mistral, Horizon, OAuth2.0 Horizon
OpenStack for NFV
Pluggable SDN Controller w/ Neutron APIs
OpenStack Public Cloud
Advanced IaaS + OpenStack App Svcs +
OpenStack App Mgmt
ec2api, gce-api, etc.
How it Might Work
Interoperability Test Suite
Infrastructure Team &
TC, Board, Vertical/Horizontal
Working Groups, Community, &
PTLs & key committers/reviewers
(more like Apache PMC??)
We Are t3h Borg. You Will Be Assimilated.
“Maybe I’m an idiot, but I have no idea what anyone is talking about.
What is it? It’s complete gibberish. It’s insane. When is this idiocy
going to stop?”
Larry Ellison on Cloud
ComputerWorld, July 2000
"This 'telephone' has too many shortcomings to be
seriously considered as a means of
communication. The device is inherently of no value
to us.”, Western Union internal memo, 1876.
Decca Records rejected the Beatles, saying
"guitar groups are on the way out" and "The
Beatles have no future in show business,"
We Can Do It!
• Interrelated, but not interdependent projects
• Testable reference architectures that are interoperable
• Streamline governance
• Survival of the ﬁttest project and programming language
• OpenStack is not speciﬁc code or APIs, it’s:
• Community, common values, and common governance