Open Stack

Excerpts from Doug Wiegley's message of 2016-06-20 10:40:56 -0600:
> So, it sounds like you’ve just described the job of the TC. And they have so far refused to define OpenStack, leading to a series of derivative decisions that seem … inconsistent over time.
> 
> How is this body going to be different?
> 
> How will it have any teeth, and not just end up with the standard entrenched projects ignoring it?
> 

Hi Doug, thanks for your candid reply. I understand that there is a
concern and I want to address it. However, I feel like answering this
directly will start this working group out on the wrong foot.

We shouldn't need teeth. This isn't an adversarial working group that
will be challenging engineers any more than an architect of a building
challenges the builders while they work. An architect that ignores their
engineers is not going to complete many projects. Of course, engineers
may disagree on the cost of an architectural decision. But to disagree,
first we need to actually _make_ a decision on a design.

The goal of this group would be to provide a detailed architecture and
plans for the way the system should work and fit together as a whole. Like
any complex system, during implementation, things that architects weren't
aware of come to light. Something that seems simple turns out to be
complex. Something that seemed absolutely necessary can be factored out.

Nobody is suggesting designing OpenStack from the ground up, just that
where there isn't an agreed upon design, let's write down how the system
works now, and then make a design and a plan to actually improve it.

Engineers have no effective place to turn to right now when there is
a lack of design. The TC could of course do it, but what I want to do
is have a more open and free-flowing group that are laser focused on
providing support for the design of the system. I want to work out with
the community at large how we add weight to the designs we choose, and
one good option is for the Architecture Working Group to make proposals
to the openstack-specs repo, which the TC would ultimately approve.
That's not a new process, we already have it:

http://docs.openstack.org/project-team-guide/cross-project.html

I'm just suggesting a group that actually _focuses_ on the design
aspects of that process.

Without this, we are designing in real time and taking the shortest path
to achieve short term goals. This has positive and negative effects. I
think we've reached a point in OpenStack's evolution where the positive
effects of that are mostly realized, and now we should work to pay
down some of the negative effects by adopting some designs and beginning
refactoring of the system. It's not a fast process, so the longer we wait,
the longer we pay interest on that debt.