Open Stack

Thank you for making it more clear, Zane. I totally agree with you at here.

IMHO, as a cloud computing platform, it should be an ecosystem just like 
the others. That said, not only looking from bottom to top, but also 
looking from top to bottom. It should looks like an unified platform. In 
other words, we need to understand what are the app developer need. I'm 
sure except a good VM creation, they also need something else. To avoid 
it turns to be another chicken/egg problem, we could/should to eat our 
dog food, instead of just "waiting" a service get matured by itself, we 
could provide some support/help. Therefore, I think plugins for all 
could be a good start.

My 0.02

On 22/07/16 10:04, Zane Bitter wrote:
> 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

-- 
Cheers & Best regards,
Fei Long Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--------------------------------------------------------------------------