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
__________________________________________________________________________
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
