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

Fox, Kevin M Kevin.Fox at pnnl.gov
Thu Jul 21 22:52:19 UTC 2016


Zane, Thanks. You have managed to articulate my concern where I've failed so far. +1 :)

Kevin
________________________________________
From: Zane Bitter [zbitter at redhat.com]
Sent: Thursday, July 21, 2016 3:04 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

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



More information about the OpenStack-dev mailing list