[openstack-dev] [docs][all] Software design in openstack
harlowja at fastmail.com
Thu Feb 4 19:51:00 UTC 2016
Nick Yeates wrote:
> 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.
Specs are somewhat like blueprints, but with a review, feedback and
commentary system that doesn't suck/not work very well.
> 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?
Yes I think that's a good summary, the harder parts to quantify are the
common architecture patterns that repeatedly pop up in openstack
(sometimes for better, sometimes for worse). These ones are probably
what u are looking for right? If so I think we can try to document them
somewhere (if that's what u are after) since I don't know of any
analysis that exists of these kinds of things in a more formal place
(maybe one exists somewhere). Btw some projects have attempted to
document there architecture, some haven't (although IMHO most haven't),
developer priorities and all never seem to focus on this and/or keeping
it up to date (for worse IMHO).
Not to pick on anyone but IMHO
really provide a architecture of heat, but is more the goal of heat
(maybe there is a better doc somewhere and I just didn't find it in the
> What artifacts were you going to send me at?
So a few ideas, the MQ RPC pattern is common in openstack for doing
things across systems (and add in object versioning here also). This has
coalesced into oslo.messaging for most projects that wish to do this
kind of stuff. So that could be one artifact (but a low-level one), the
state-machine library in oslo also is getting more usage (but its also a
low-level artifact), taskflow can also be in this same group (although
its not as low-level but imho low->mid level artifact).
Others also @ https://wiki.openstack.org/wiki/Oslo#Libraries
Depends on how high-level or low-level u are thinking :)
> I have still yet to find a good encompassing architecture diagram or white paper.
Ya I bet, see above and/or lack of diagrams of this kind of stuff :)
> Thanks again!
>> On Feb 3, 2016, at 3:05 PM, Joshua Harlow<harlowja at fastmail.com> wrote:
>> Nick Yeates wrote:
>>> I have been scouring OpenStack artifacts to find examples of what
>>> encourages good software design / patterns / architecture in the wider
>>> system and code. The info will be used in teaching university students.
>>> I suppose it would be good for new developers of the community too.
>>> I found hacking.rst files, along with blueprints and bugs and code
>>> reviews, but cant piece together a full picture of how good architecture
>>> and design are encouraged via process and/or documents.
>>> - Architecture descriptions (ex: http://www.aosabook.org/en/index.html )?
>>> - Code standards?
>>> - Design rules of thumb?
>>> I see the Design Summits, but have not yet found in-depth design
>>> recommendations or a process.
>> Perhaps oslo is a good start? It starts to feel that good patterns begin either there or in projects, and then those good patterns start to move into a shared location (or library) and then get adopted by others.
>> As for a process, the spec process is part of it IMHO, organically it also happens by talking to people in the community and learning who the experienced folks are and what there thoughts are on specs, code (the review process) but that one (organic) is harder to pinpoint exactly when it happens.
>>> Does it come from Developers personal experience, or are there some sort
>>> of artifacts to point at? I am looking for both specific examples of
>>> design patterns, but more a meta of that. What encourages or describes
>>> good design in OpenStack?
>> As an oslo core, I can point u at artifacts, but it depends on having more information on what u want, because 'good design' and what encourages it or discourages it is highly relative to the persons definition of the word 'good' (which is connected itself to many things, experience, time in community... prior designs/code/systems built...).
>>> -Nick Yeates
>>> IRC: nyeates (freenode)
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev