Open Stack

Hey

On Thu, 2014-09-18 at 11:53 -0700, Monty Taylor wrote:
> Hey all,
> 
> I've recently been thinking a lot about Sean's Layers stuff. So I wrote
> a blog post which Jim Blair and Devananda were kind enough to help me edit.
> 
> http://inaugust.com/post/108

Lots of great stuff here, but too much to respond to everything in
detail.

I love the way you've framed this in terms of the needs of developers,
distributors, deployers and end users. I'd like to make sure we're
focused on tackling those places where we're failing these groups, so:


 - Developers

   I think we're catering pretty well to developers with the "big tent"
   concept of Programs. There's been some good discussion about how
   Programs could be better at embracing projects in their related area,
   and that would be great to pursue. But the general concept - of 
   endorsing and empowering teams of people collaborating in the
   OpenStack way - has a lot of legs, I think.

   I also think our release cadence does a pretty good job of serving 
   developers. We've talked many times about the benefit of it, and I'd 
   like to see it applied to more than just the "server projects".

   OTOH, the integrated gate is straining, and a source of frustration 
   for everyone. You raise the question of whether everything currently 
   in the integrated release needs to be co-gated, and I totally agree 
   that needs re-visiting.


 - Distributors

   We may be doing a better job of catering to distributors than any 
   other group. For example, things like the release cadence, stable 
   branch and common set of dependencies works pretty well.

.  The concept of an integrated release (with an incubation process) is
   great, because it nicely defines a set of stuff that distributors
   should ship. Certainly, life would be more difficult for distributors
   if there was a smaller set of projects in the release and a whole 
   bunch of other projects which are interesting to distro users, but 
   with an ambiguous level of commitment from our community. Right now, 
   our integration process has a huge amount of influence over what 
   gets shipped by distros, and that in turn serves distro users by 
   ensuring a greater level of commonality between distros.


 - Operators

   I think the feedback we've been getting over the past few cycles 
   suggests we are failing this group the most.

   Operators want to offer a compelling set of services to their users, 
   but they want those services to be stable, performant, and perhaps 
   most importantly, cost-effective. No operator wants to have to
   invest a huge amount of time in getting a new service running.

   You suggest a "Production Ready" tag. Absolutely - our graduation of 
   projects has been interpreted as meaning "production ready", when 
   it's actually more useful as a signal to distros rather than 
   operators. Graduation does not necessarily imply that a service is
   ready for "production", no matter how you define "production".

   I'd like to think we could give more nuanced advice to operators than
   a simple tag, but perhaps the information gathering process that
   projects would need to go through to be awarded that tag would 
   uncover the more detailed information for operators.

   You could question whether the TC is the right body for this 
   process. How might it work if the User Committee owned this?

   There are many other ways we can and should help operators, 
   obviously, but this "setting expectations" is the aspect most 
   relevant to this discussion.


 - End users

   You're right that we don't pay sufficient attention to this group.
   For me, the highest priority challenge here is interoperability. 
   Particularly interoperability between public clouds.

   The only real interop effort to date you can point to is the 
   board-owned DefCore and RefStack efforts. The idea being that a
   trademark program with API testing requirements will focus minds on
   interoperability. I'd love us (as a community) to be making more
   rapid progress on interoperability, but at least there are no
   encouraging signs that we should make some definite progress soon.

   Your end-user focused concrete suggestions (#7-#10) are interesting,
   and I find myself thinking about how much of a positive effect on 
   interop each of them would have. For example, making our tools 
   multi-cloud aware would help encourage people to demand interop from 
   their providers. I also agree that end-user tools should support 
   older versions of our APIs, but don't think that necessarily implies 
   rolling releases.



So, if I was to pick the areas which I think would address our most
pressing challenges:

  1) Shrinking the integrated gate, and allowing per-project testing 
     strategies other than shoving every integrated project into the 
     gate.

  2) Giving more direction to operators about the readiness of our 
     projects for different use cases. A process around awarding 
     "Production Ready" tags sounds interesting, but I suspect the 
     information uncovered by the process might be as interesting to 
     operators as the tag itself. Consider whether it makes sense for 
     the User Committee to own this process, rather than the TC.

  3) Driving towards concrete and measurable progress on interop. 
     Establishing the defcore/refstack process is great, but I'm super 
     anxious to see it make a tangible difference to end users.

Thanks,
Mark.