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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
