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 <mar...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev