Nick Yeates wrote:
Josh, thanks for pointing this out and in being hospitable to an outsider.
Of course!
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
http://docs.openstack.org/developer/heat/architecture.html doesn't
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
docs).
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!
-N
On Feb 3, 2016, at 3:05 PM, Joshua Harlow<[email protected]> 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...).
Thanks,
-Nick Yeates
IRC: nyeates (freenode)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
