Open Stack

This thread is an extraction of:

http://lists.openstack.org/pipermail/openstack-dev/2017-March/thread.html#113362

And is a start of someideas for what we as a group want our vision to 
be. I'm going to start by taking what Zane put up (see above thread) 
already and mutate it.

* Infinite scaling (kept the same as); be nice to target this, although 
it may be a bit abstract with the definition I saw, but meh, that's ok, 
gotta start somewhere.

* Granularity of allocation (kept as is).

* Be opinionated; let's actually pick *specific* technologies based on 
well thought out decisions about what we want out of those technologies 
and integrate them deeply (and if we make a bad decision, that's ok, we 
are all grown ups and we'll deal with it). IMHO it hasn't turned out 
well trying to have drivers for everything and everyone so let's umm 
stop doing that.

* Leads others; we are one of the older cloud foundations (I think?) so 
we should be leading others such as the CNCF and such, so we must be 
heavily outreaching to these others and helping them learn from our 
mistakes (in all reality I don't quite know why we need a openstack 
foundation as an entity in the first place, instead of say just joining 
the linux foundation and playing nicely with others there).

* Granularity of allocation (doesn't feel like this should need 
mentioning anymore, since I sort of feel its implicit now-a-days but 
fair enough, might as well keep it for the sake of remembering it).

* Full control of infrastructure (mostly discard it); I don't think we 
necessarily need to have full control of infrastructure anymore. I'd 
rather target something that builds on the layers of others at this 
point and offers value there. If it is really needed provide a 
light-weight *opinionated* version of nova, cinder, neutron that the 
upper layers can use (perhaps this light-weight version is what becomes 
of the current IAAS projects as they exist).

* Hardware virtualization (seems mostly implicit now-a-days)

* Built-in reliability (same as above, if we don't do this we should all 
look around for jobs elsewhere)

* Application control - (securely) (same as above)

* 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).

    - Ummm maybe, if this creates yet another ecosystem where only the 
things inside that ecosystem work with each other, then nope, I veto 
that; if it means the services created work with other services over 
standardized APIs (that are bigger than a single ecosystem) then I'm ok 
with that.

* Interoperability - kept as is (though I can't really say how many 
public clouds there are anymore to interoperate with).

* Self-healing - whatever services we write should heal and scale 
themselves, if a operator has to twiddle some settings or get called up 
at night due to something busting itself, we failed.

* Self-degradation - whatever services we write should be able to 
degrade there functionality *automatically* taking into account there 
surroundings (also related to self-healing).

* Heavily embrace that fact that a growing number of users don't 
actually want to own any kind of server (including myself) - amazon 
lambda or equivalent may be worth energy to actually make a reality.

* Move beyond copying what others have already done (ie aws) and develop 
the equivalent of a cross-company research 'arm?' that can utilize the 
smart people we have to actually develop leading edge solutions (and be 
ok with those solutions failing, cause they may).

* More (as I think of them I'll write them)....

-Josh