On Mon, Oct 3, 2016 at 11:33 AM, Clay Gerrard <clay.gerr...@gmail.com> wrote:
> > > On Thu, Sep 29, 2016 at 8:34 PM, John Griffith <john.griffi...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ 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