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.
Anyway, the review was abandoned and moved to an etherpad (sans
comments... sigh):
https://etherpad.openstack.org/p/AtlantaPTG-SWG-OpenStackVision
Then the whole discussion was shelved, pending a resolution of the
preceding discussion about a vision for the TC - IOW the TC had to
decide whether anybody ought to care about the Technical Committee's
technical vision for OpenStack (my 2c: it's right there in the name)
before it could decide what that vision was. Of course you can't not
decide - not deciding is a quieter way of deciding to stick with the
status quo. Though given the amount of pushback they got against the
relatively simple idea of moving off the imminently-EOL Python 2 runtime
in a co-ordinated rather than ad-hoc fashion, I guess you couldn't
really blame them.
*That* discussion (the TC vision one) was scheduled to happen in the
Stewardship Working Group meeting at the PTG in Atlanta:
https://etherpad.openstack.org/p/AtlantaPTG-SWG-TCVision
Then it was cancelled because it became clear that most of the TC
members didn't plan to show up due to scheduling conflicts.
Looking through the TC mailing list, it appears it was rescheduled to
happen this week at a joint TC/Board meeting in Boston. This looks to be
one of the outputs:
https://etherpad.openstack.org/p/ocata-12questions-exercise-board
Hopefully we'll hear more in the next few days, since this _just_
happened. But progress toward a technical vision can't come fast enough
for me - we needed this 3 years ago, and we don't *have* another year to
figure it out.
cheers,
Zane.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
