Zane, Thanks. You have managed to articulate my concern where I've failed so far. +1 :)
Kevin ________________________________________ From: Zane Bitter [zbit...@redhat.com] Sent: Thursday, July 21, 2016 3:04 PM To: openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ 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
