Clint Byrum wrote:
Excerpts from Nick Yeates's message of 2016-02-03 21:18:08 -0800:
Josh, thanks for pointing this out and in being hospitable to an outsider.

Oslo is definitely some of what I was looking for. As you stated, the fact that 
there is an extensive review system with high participation, that this alone 
organically leads to particular trends in sw design. I will have to read more 
about ‘specs', as I don’t quite get what they are and how they are different 
from blueprints.

When I said "What encourages or describes good design in OpenStack?”, I meant, 
what mechanism's/qualities/artifact's/whatever create code that is well-received, 
well-used, efficient. effective, secure… basically: successful from a 
wider-ecosystem standpoint. It sounds to me like much is built into 1) the detailed 
system of reviews, 2) an informal hierarchy of wise technicians, and now 3) 
modularization efforts like this Oslo. Did I summarize this adequately?

What artifacts were you going to send me at?
I have still yet to find a good encompassing architecture diagram or white 
paper.


Hi Nick.

The specification process is pretty mature at this point, but it varies
a bit from project to project. You may want to browse around this:

http://specs.openstack.org/

And look at ongoing reviews for the various -specs repositories here:

https://review.openstack.org/

These contain high level specs for features and refactoring work going
on in OpenStack. They are as close to we have as a "good design" process
in OpenStack. Note that we get together in a physical meeting space
every 6 months to discuss these specs face to face.

https://www.openstack.org/summit/

Note that many of us have lamented the lack of an agreed upon
"architecture" in OpenStack. While Josh is right that Oslo often
facilitates many of our agreed upon technology choices, it doesn't really
shape the overall picture. We also have recently starting doing some
detailed cross-project sessions to discuss overall themes, but these
aren't necessarily architectural decisions, they're just optimizations
of similar concerns.

Agreed, it's why also a ARB (or something with a different name) might be useful in the future somehow... Not saying I like more process/red-tape but yes many of us have lamented and I'm not sure of a better way to stop lamenting. Such a ARB (architecture review board) could at least start off being a ADB (architecture documenting board?) and fill in the gaps in documentation/understanding of what the (shared?) architectures actually are (with the help of PTLs I hope).

Do note I tried to use as many 3 letter acronyms as I could, ha.


__________________________________________________________________________
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

__________________________________________________________________________
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

Reply via email to