Open Stack

FWIW, I think this is a great approach to evolving our thinking of the projects and ecosystem around OpenStack. I’m far too removed these days from the details of the day-to-day running of the programs and projects to comment on details. But, I’ve long felt a need to go beyond the simple core + everyone else thinking. This is moving in the right direction IMHO.

Troy

> On Sep 22, 2014, at 5:49 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> 
> 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.
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev