On 06/20/2016 08:07 PM, Clint Byrum wrote: > Excerpts from Jesse Cook's message of 2016-06-20 16:58:48 +0000: >> +1 >> >> The points about the PWG and TC are worth some consideration. >> >> From my perspective, I think it would make sense for the PWG to define the >> expected behaviors of the system, which would be an input to the >> architecture group. The architecture group would define both prescriptive >> (where we'd like to be) and descriptive (where we actually are...roughly) >> architectures. This would provide both the vision for the future state and >> understanding of current state that is necessary for us to all swim in the >> same general direction instead of constantly running into each other. I >> don't see the architecture as something you push down, but rather something >> that helps each contributor ask, "Does that get us closer to where we are >> trying to go?" I absolutely think this is something that would provide a >> huge benefit to the organization. >> > > That sounds about right Jesse. Thanks for bringing up the PWG. I > definitely don't think an Architecture WG would want to answer "what > is OpenStack" alone. More like "What should the OpenStack we described > actually look like?".
IMHO, the group shall get a global state view first, which is to collect and process (and perhaps do a *lot* of reverse engineering and asking developers AND users many questions) implicit knowledge hidden in OpenStack components and libraries. Then answer the question "What *does* the OpenStack actually look like?". The answer may have a form of established contracts and behaviour models - expected vs actual, and corner cases. Yes, SLA, timeouts, failure modes, and patterns. Not generic things the projects already have being auto-generated in dev docs, but very specific reverse engineered and collected as a feedback or testing discovered, *whitespaces*. Examples: which DB patterns each of the project/common library do leverage in code? Sounds simple, but will require a huge amount of reverse engineering. How much of those are NOT ready to be used with A/A read/write transactions? And for messaging patterns and failure modes and corner cases handling - like lost or duplicated or racing data. Retrying, timeouts - exposed in API and implcit/hardcoded. Failure detection for stateful components like conductors/schedulers? What are locking expectations (strong or relaxed) for the projects that do leverage DLM? So, those and many more firstly to be brought to the light then set in stone. Only after that the group may proceed with the question "What should the OpenStack we described actually look like?" in order to a) fit unexpected or unclear behaviour into the contracts and document them as well, b) improve. > > __________________________________________________________________________ > 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 > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ 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
