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