[openstack-dev] [tc][appcat] The future of the App Catalog

Zane Bitter zbitter at redhat.com
Sat Mar 11 01:07:45 UTC 2017


On 10/03/17 14:30, Jay Pipes wrote:
> On 03/10/2017 01:37 PM, Zane Bitter wrote:
>> On 09/03/17 23:57, Renat Akhmerov wrote:
>>> And this whole discussion is taking me to the question: is there really
>>> any officially accepted strategy for OpenStack for 1, 3, 5 years? Is
>>> there any ultimate community goal we’re moving to regardless of
>>> underlying technologies (containers, virtualization etc.)? I know we’re
>>> now considering various community goals like transition to Python 3.5
>>> etc. but these goals don’t tell anything about our future as an IT
>>> ecosystem from user perspective. I may assume that I’m just not aware of
>>> it. I’d be glad if it was true. I’m eager to know the answers for these
>>> questions.
>>
>> Me too! There was one effort started by John Garbutt in December, a
>> technical vision for OpenStack in the form of a TC resolution in the
>> governance repo:
>>
>> https://review.openstack.org/#/c/401226/
>>
>> I wasn't a fan of the draft content, but I believe his intention was to
>> seed it with a formalised version of our de-facto historical position
>> (tl;dr legacy apps from the 90s). As long as that's a starting point for
>> the discussion and not a conclusion then I think this was a valuable
>> contribution. I commented with a non-exhaustive list of things that I
>> would expect to see at least debated in a vision for a cloud computing
>> platform, which I will reproduce here since it's relevant to this thread:
>>
>> * Infinite scaling - the ability in principle to scale from zero to an
>> arbitrarily large number of users without rewriting your application
>> (e.g. if your application can store one file in Swift then there's no
>> theoretical limit to how many it can store. c.f. Cinder where at some
>> point you'd have to start juggling multiple volumes.)
>> * Granularity of allocation - pay only for the resources you actually
>> use, rather than to allocate a chunk that you may or may not be using
>> (so Nova->containers->FaaS, Cinder->Swift, Trove->??? [RIP MagnetoDB],
>> &c.)
>> * Full control of infrastructure - notwithstanding the above, maintain
>> Nova/Cinder/Neutron/Trove/&c. so that legacy applications, highly
>> specialised applications, and higher-level services like PaaS can make
>> fully customised use of the virtual infrastructure.
>> * Hardware virtualisation - make anything that might typically be done
>> in hardware available in a multi-tenant software-defined environment:
>> servers, routers, load balancers, firewalls, video codecs, GPGPUs,
>> FPGAs...
>> * Built-in reliability - don't require even the smallest apps to have 3
>> VMs + a cluster manager to enforce any reliability guarantees; provide
>> those guarantees using multi-tenant services that efficiently share
>> resources between applications (see also: Infinite scaling, Granularity
>> of allocation).
>> * Application control - (securely) give applications control over their
>> own infrastructure, so that no part of the application needs to reside
>> outside of the cloud.
>> * Integration - cloud services that effectively form part of the user's
>> application can communicate amongst themselves, where appropriate,
>> without the need for client-side glue (see also: Built-in reliability).
>> * Interoperability - the same applications can be deployed on a variety
>> of private and public OpenStack clouds.
>
> Those are all interesting technical concepts to think about and discuss.
> However, what Kevin said originally in his response about the OpenStack
> community needing to decide what exactly it *is* and what scope
> OpenStack should pursue, is the real foundational question that needs to
> be addressed. Until it is, none of the rest of these topics have much
> contextual relevance and are just a distraction, IMHO.

Hey Jay,
I respect your opinion here, and I agree that's the question we need to 
answer. TBH I'm happy any way we can get to an answer.

I suspect however, that approaching it directly will not prove feasible 
due to a lack of shared terminology. When everyone has a different idea 
in their head (and AFAICT they do) of what "IaaS" means, discussions 
devolve quite quickly into meaninglessness.

It seems to me that having the conversation at a different level of 
abstraction, that of the technical principles we think the solution 
should embody, could potentially be more productive. I believe it's 
fairly easy to judge what is in scope (including for services we haven't 
imagined yet) by referring back to principles at this level of 
abstraction if we can agree on them first.

I'm open to other approaches though.

cheers,
Zane.



More information about the OpenStack-dev mailing list