Open Stack

On 22/07/16 10:04, Zane Bitter wrote:
> If we're not to end up with 20 different answers to the those 
> questions, we'll need some cross-project co-ordination and part of 
> that will involve depending on various projects for functionality 
> instead of implementing multiple different one-off solutions. Pick an 
> asynchronous message transport (Zaqar). Pick an event source 
> (Ceilometer? Searchlight?). Maybe pick an event sink (just Mistral? or 
> lots of sinks?).
>
> So it's architecture, but it is in a sense "user-space" architecture, 
> figuring out how services fit together into a cohesive whole, as 
> opposed to the questions you're talking about which are more 
> engineering-focused. I'd be very interested to know if you consider 
> this stuff in scope for your architecture group or if you think it 
> should have its own separate working group.
>

Well said, Zane.

I 100% have felt and continue to feel the pain that Kevin originally mentioned with simply being blocked on progress because the projects are often silo’d and there is no high level architecture group essentially saying it is okay for project X to have a dependency on project Y.

I know at least on Horizon, that summit after summit, cross cutting features that could really enhance the end user experience are rejected out of fear of adding any additional dependency (even if optional). I probably can’t even begin to count the number of times people have asked to add additional dynamic user preference customizations but been blocked because Horizon doesn’t want to add any kind of a dependency on any kind of a persistence mechanism.

Another problem I see is that project A has a high priority need to land a relatively simple patch in project B, but due to the extremely limited amount of time to actually get any reviews for non-priority features in project B, that only a few weeks into the release cycle you get blocked with -2 and a “better luck next time” message. Which effectively means you are barely a month or two into the current release and now are faced with the reality that it will be *at least* 9 months before you can hope to see your patch be released in the next “alphabet letter of your choice” release. In the meantime, the people paying the salaries of the developers working on OpenStack decide that progress is too slow and pull their people off all together. But don’t worry, the community elitists will just declare these to be drive by contributions and are happy to essentially pat themselves on the back for preventing those people from contributing code.

I am a core reviewer on a couple projects and I can honestly say that I believe the core reviewer teams are also a huge part of the bottleneck. This certainly isn’t due to cores being lazy, quite the contrary, but that perhaps it is too much to expect of core reviewers to essentially perform the product management role, the project management role, the architecture role, the evangelist role, the developer roles, and finally the quality assurance role (you know, the actual code review thing).

One of the most beautiful things about OpenStack is that the developers are empowered in a way that they simply are not within the confines of large proprietary enterprise software shops.  However, the inability to make progress from release to release whenever it comes to cross project integration and dependencies is an Achilles heel that I fear may be the downfall of OpenStack.