Open Stack

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.

Best,
-jay