[openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

Zane Bitter zbitter at redhat.com
Thu Jul 21 22:04:44 UTC 2016


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.



More information about the OpenStack-dev mailing list