Open Stack

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.