Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando