Its easier to convince the developers employer to keep paying the developer when their users (operators) want to use their stuff. Its a longer term strategic investment. But a critical one. I think this has been one of the things holding OpenStack back of late. The developers continuously push off hard issues to operators that may have other, better solutions. I don't feel this is out of malice but more out of lack of understanding on what operators do. The operators are starting to push back and are looking at alternatives now. We need to break this trend before it accelerates and more developers can no longer afford to work on OpenStack. I'd be happy as an operator to work with developers to identify pain points so they can be resolved in more operator friendly ways.
Thanks, Kevin ________________________________________ From: Ben Nemec [openst...@nemebean.com] Sent: Friday, September 29, 2017 6:43 AM To: OpenStack Development Mailing List (not for usage questions); Rochelle Grober Subject: Re: [openstack-dev] [ptg] Simplification in OpenStack On 09/26/2017 09:13 PM, Rochelle Grober wrote: > Clint Byrum wrote: >> Excerpts from Jonathan Proulx's message of 2017-09-26 16:01:26 -0400: >>> On Tue, Sep 26, 2017 at 12:16:30PM -0700, Clint Byrum wrote: >>> >>> :OpenStack is big. Big enough that a user will likely be fine with >>> learning :a new set of tools to manage it. >>> >>> New users in the startup sense of new, probably. >>> >>> People with entrenched environments, I doubt it. >>> >> >> Sorry no, I mean everyone who doesn't have an OpenStack already. >> >> It's nice and all, if you're a Puppet shop, to get to use the puppet modules. >> But it doesn't bring you any closer to the developers as a group. Maybe a few >> use Puppet, but most don't. And that means you are going to feel like >> OpenStack gets thrown over the wall at you once every >> 6 months. >> >>> But OpenStack is big. Big enough I think all the major config systems >>> are fairly well represented, so whether I'm right or wrong this >>> doesn't seem like an issue to me :) >>> >> >> They are. We've worked through it. But that doesn't mean potential users >> are getting our best solution or feeling well integrated into the community. >> >>> Having common targets (constellations, reference architectures, >>> whatever) so all the config systems build the same things (or a subset >>> or superset of the same things) seems like it would have benefits all >>> around. >>> >> >> It will. It's a good first step. But I'd like to see a world where >> developers are >> all well versed in how operators actually use OpenStack. > > Hear, hear! +1000 Take a developer to work during peak operations. Or anytime really. One of the best experiences I had was going on-site to some of our early TripleO users and helping them through the install process. It was eye-opening to see someone who wasn't already immersed in the project try to use it. In a relatively short time they pointed out a number of easy opportunities for simplification (why is this two steps instead of one? Umm, no good reason actually.). I've pushed for us to do more of that sort of thing, but unfortunately it's a hard sell to take an already overworked developer away from their day job for a week to focus on one specific user. :-/ > > For Walmart, that would be Black Firday/Cyber Monday. > For schools, usually a few days into the new session. > For others....each has a time when things break more. Having a developer > experience what operators do to predict/avoid/recover/work around the normal > state of operations would help each to understand the macro work flows. > Those are important, too. Full stack includes Ops. > > < Snark off /> > > --Rocky > >> >> __________________________________________________________ >> ________________ >> 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 > __________________________________________________________________________ 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
