On 20/07/16 18:41, Clint Byrum wrote:
Excerpts from Fox, Kevin M's message of 2016-07-20 20:12:48 +0000:
And maybe this raises an interesting defininition mismatch in the conversation.
There is archetectural stuff like, do we support 7 different web frameworks, or
do we standardize on flask... python vs go.
Yeah meh, that's developer centric implementation details and I think
not very interesting. To me the architectural questions are deeper. "How
do we do locking?", "How should we enable inter-process and inter-host
communication?", "How do we handle distributed transactions?" and "What
concurrency model should we use?".
Theres also the architectural stuff at the, what interactive surface do you
expose to users/operators. How consistant is it. Does it have all the features,
no matter where they are implemented to do work.
I believe this is the goal of the API-WG. But again, they're not there
to compel, they're there to advise, assist, and work. Ultimately, if an
API is created and is poor, like Linus, the community can definitely say
"No" and refuse to use that API.
No, the API-WG is pretty much just about coming up with standards for
how individual REST APIs look. Kevin (IIUC) is talking about something
at least as different from that as 'which web framework?' is from your
list of architecture questions. It's questions like: How can
applications running in the cloud authenticate themselves to the cloud?
How can the user limit their authorisation to a minimal surface? How can
the cloud notify applications of events? How can the user configure the
cloud to respond to events without having to write their own service to
process them? How should guest agents communicate with the cloud?
If we're not to end up with 20 different answers to the those questions,
we'll need some cross-project co-ordination and part of that will
involve depending on various projects for functionality instead of
implementing multiple different one-off solutions. Pick an asynchronous
message transport (Zaqar). Pick an event source (Ceilometer?
Searchlight?). Maybe pick an event sink (just Mistral? or lots of sinks?).
So it's architecture, but it is in a sense "user-space" architecture,
figuring out how services fit together into a cohesive whole, as opposed
to the questions you're talking about which are more
engineering-focused. I'd be very interested to know if you consider this
stuff in scope for your architecture group or if you think it should
have its own separate working group.
cheers,
Zane.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
