[openstack-dev] TC Candidacy

John Griffith john.griffith8 at gmail.com
Tue Oct 4 04:50:59 UTC 2016


On Mon, Oct 3, 2016 at 11:33 AM, Clay Gerrard <clay.gerrard at gmail.com>
wrote:

>
>
> On Thu, Sep 29, 2016 at 8:34 PM, John Griffith <john.griffith8 at gmail.com>
> wrote:
>
>>
>>
>> I think what's more important and critical is the future and where
>> OpenStack is going over the course of the next few years.
>>
>
> I think this is a really important topic right now!  Do you see any
> dangerous road blocks coming up!?
>
​I don't know if I'd call them "road blocks", what I do worry about though
is becoming irrelevant (ok maybe that's harsh), but I do think stagnation
is a potential.  It's a great big world out there and there are other Open
Source efforts out there moving really fast and doing some pretty cool
stuff.  More importantly they're creating things that are ACTUALLY
CONSUMABLE by mere mortals!  Some are solving real problems in a novel way,
and they're doing it in a way that people can actually use them as a
foundation and build value on top of them.  That's what I always envisioned
happening with OpenStack.  The fact is though if you're not offering
something unique and providing the ability for people to easily solve
problems, then they'll move on to the next solution.

​To be clear, I'm not discrediting OpenStack, the community or any of the
folks that have led efforts in the past.  I am saying that time is
changing, we have to grow up at some point and that things either evolve or
die.​

>
>
>>
>> Do we want our most popular topic at the key-notes to continue being
>> customers telling their story of "how hard" it was to do OpenStack?
>>
>
> No ;)
>
>
>>
>> It's my belief that the TC has a great opportunity (with the right
>> people) to take input from the "outside world" and drive a meaningful and
>> innovative future for OpenStack.  Maybe try and dampen the echo-chamber a
>> bit, see if we can identify some real problems that we can help real
>> customers solve.
>>
>
> I think this is where we *all* should be focused - do you think the TC can
> offer specific support to the projects here - or is more about just
> removing other roadblocks and keeping the community on target?
>
​The problem currently in my view is not whether the TC offers this support
or not, but rather I don't think it's currently intended or viewed as
fulfilling this obligation.  I think it should though, the trick is that
it's not something that just one or two newly elected members of the TC can
do.  This is something that really needs significant mind-share, and of
course has to find a way to balance the needs and wishes of the community
at the same time.

Really above all, I've had this feeling the past few years that the
OpenStack development community served itself, that being the vendors that
sponsor the developers, or even in some cases just groups of developers
inside the community itself.  If that's the way things go, then that's
fine, but I'd really like to see a true shift towards a focus on solving
new problems for actual users.​


>
>
>> I'd like to see us embracing new technologies and ways of doing things.
>> I'd love to have a process where we don't care so much about the check
>> boxes of what oslo libs you do or don't use in a project, or how well you
>> follow the hacking rules; but instead does your project actually work?  Can
>> it actually be deployed by somebody outside of the OpenStack community or
>> with minimal OpenStack experience?
>>
>> It's my belief that Projects should offer real value as stand-alone
>> services just as well as they do working with other OpenStack services.
>>
>
> Very controversial (surprisingly?)!  Why do you think this is important?
> Do you think this is in conflict with the goal of OpenStack as one
> community?
>
​Which soap box should I get on top of here :)
​* New technologies

Same thing I mentioned before, evolve or die.  If there are better tools
that are easier, better, more advanced that can be used to solve a problem
then by all means they should be used.  Frankly I don't care so much if a
project uses oslo's version of XYZ vs implementing their own thing so long
as what they implement works and people can consume it.  I'm not saying
anything negative about oslo or any libraries that exist under that
project, just saying that maybe the lowest common denominator, one size
fits all lib isn't always the best or only answer.  If folks feel strongly
and have what for them is a better implementation, good for them.  At the
same time I'd hope we're all professionals and build a new wheel for
everything just because it's the cool thing to do.

* Real value as stand-alone services

This one is really interesting to me, and really until recently there's
only been on OpenStack project (I'm looking at you Swift) that's managed to
do that.  As a result I think that Swift is better for it.  More
importantly however, I think OpenStack is better for it as well.  I've
noticed other projects starting to try and shift that direction, Neutron,
Ironic and of course Cinder.  I don't know how successful or unsuccessful
these efforts might be but I do think there's a lot to be learned when you
step back and look at the big picture.  The big picture in my opinion here
is that the world is made up of more than Nova controlling KVM
hypervisors.  I also think that by working towards something that's useful
outside of OpenStack you will also end up picking up outside ideas that
make a service better inside of OpenStack at the same time.

>
>
>
>>
>> Feel free to ask me about my thoughts on anything specific, I'm happy to
>> answer any questions that I can as honestly as I can.
>>
>
> Don't mind if I do ;)
>

​I'm glad you did, good questions!​


>>
>

> -Clay
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161003/ed9d8842/attachment.html>


More information about the OpenStack-dev mailing list