Open Stack

> On Sep 25, 2017, at 22:44, Adam Lawson <alawson at aqorn.com> wrote:
> 
> Hey Jay,
> I think a GUI with a default config is a good start. Much would need to happen to enable that of course but that's where my mind goes. Any talk about 'default' kind of infringes on what we've all strived to embrace; a cloud architecture without bakes in assumptions. A default-anything need not mean other options are not available - only that a default gets them started. I would never ever agree to a default that consists of KVM+Contrail+NetApp. Something neutral would be great- easier said than done of course.
> 
> Samuel,
> Default configuration as I envision it != "Promoting a single solution". I really hope a working default install would allow new users to get started with OpeStack without promoting anything. OpenStack lacking a default install results in an unfriendly deployment exercise. I know for a fact the entire community at webhostingtalk.com ignores OS for the most part because of how hard it is to deploy. They use Fuel or other third-party solutions because we as a OS community continue to fail to acknowledge the importance of an easier of implementation. Imagine thousands of hosting providers deploying OpenStack because we made it easy. That is money in the bank IMHO. I totally get the thinking about avoiding the term default for the reasons you provided but giving users a starting point does not necessarily mean we're trying to get them to adopt that as their final design. Giving them a starting point must take precedence over not giving them any starting point.
> 

I’ll pick on my own second job for a moment, Chef. We have an amazing single node deployment strategy, and we have a so-so multinode deployment strategy for the simple fact that the orchestration story for every configuration management flavor equates to a dumpster fire in the middle of a tire fire. Let me be clear up front: I say ‘we’ a lot, but in many cases, the ‘we’ comes down to really just me. Not to discredit my teammates, I sleep a _lot_ less.

I've said it in the past, but Chef consist of nothing but part-timers with much more pressing issues at $dayJob[0]. If the README.md doesn’t get updated, it’s because none of us have the time to dedicate to evangelism. We talked about spreading the word back when we were still having IRC meetings, but it all boiled down to E_NOTIME.

As time has gone on, the roles in the Chef OpenStack project have been changing from less facilitator to more circus barker. It’s coming down to almost begging people for feedback, if we can find them. What I can do is provide a means to get to OpenStack about 80-90% of the way, provided the consumer can grok the tooling, key phrase. That said, we don’t teach people to use Chef, merely how one might OpenStack with it should they choose to kick the tires. The problem is, those potential downstream consumers, for some reason or other, don’t file bugs or even communicate back with the maintainers to get an idea if their problem would/could be addressed. They just move on, sight unseen and a bit grumpier. I can’t change that by doing more work.

If I shift gears to working on an installation method abstracted behind a GUI, am I now expected to bring in bits of Xorg simply so I can run that installer from my remote systems? Are your security people okay with Xorg on servers? Will the bootstrapping now take place entirely from a laptop/workstation, outright ignoring existing development workflows and pipelines? Who’s writing this code? Is there a GitHub repo where I can start testing this pièce de résistance?

If you’ll excuse the morning snark and “poisonous” words, as you put it a few days ago, I don’t necessarily see how bundling the install process into a graphical installer would help. If anything, it might prove more distraction than it’s worth because now there have to be graphical installer experts within whatever team(s) may be doing this effort.

Maybe it’s because I’ve been using Chef, the tool, for as long as I have, but it isn’t exactly a mash of random, disparate tooling that we’re using over here. We use community-standard tooling bundled in the ChefDK for the basic building blocks, even to our detriment at times. For integration testing, we used chef-provisioning until it rotted away, now being replaced by test-kitchen and InSpec. If anything, we were the ones lagging behind because we number so few and are beholden to E_NOTIME. Is there a knowledge barrier to entry? Sure is, and you do have to be this tall to ride. Those that do find the IRC channel and stick around long enough for one of us to respond generally get the assistance they need, but we’re not omnipresent.

As an operator in the deployment space, my whole point of contributing back is to make things less complicated. As PTL, my job isn’t to make Chef, the software, less complicated, but how to get to OpenStack, via Chef, in a less complicated manner for the times. Keeping in mind, the Chef team consists entirely of volunteers.

Call me biased, but my proposition would be to further support the existing deployment efforts and embrace them as an extension of OpenStack, not simply as an adjunct holdover from the vestiges of the Big Tent/StackForge. This smells like a deployment-focused SIG brewing to me because we’re clearly not going to solve the problems in this thread or even on this ML.

-sc

> Jonathan,
> "I'm not going to adopt something new that requires a new parallel management tool to what I use." I would hope not! :) I don't mean having a tool means the tool is required. Only that a user-friendly deployment tool is available. Isn't that better than giving them nothing at all?
> 
> //adam
> 
> 
> Adam Lawson
> 
> Principal Architect
> Office: +1-916-794-5706
> 
> On Mon, Sep 25, 2017 at 5:27 PM, Samuel Cassiba <s at cassiba.com> wrote:
> 
> > On Sep 25, 2017, at 16:52, Clint Byrum <clint at fewbar.com> wrote:
> >
> > Excerpts from Jonathan D. Proulx's message of 2017-09-25 11:18:51 -0400:
> >> On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:
> >>
> >> :Lastly, I do think GUI's make deployments easier and because of that, I
> >> :feel they're critical. There is more than one vendor whose built and
> >> :distributes a free GUI to ease OpenStack deployment and management. That's
> >> :a good start but those are the opinions of a specific vendor - not he OS
> >> :community. I have always been a big believer in a default cloud
> >> :configuration to ease the shock of having so many options for everything. I
> >> :have a feeling however our commercial community will struggle with
> >> :accepting any method/project other than their own as being part a default
> >> :config. That will be a tough one to crack.
> >>
> >> Different people have differnt needs, so this is not meant to
> >> contradict Adam.
> >>
> >> But :)
> >>
> >> Any unique deployment tool would be of no value to me as OpenStack (or
> >> anyother infrastructure component) needs to fit into my environment.
> >> I'm not going to adopt something new that requires a new parallel
> >> management tool to what I use.
> >>
> >
> > You already have that if you run OpenStack.
> >
> > The majority of development testing and gate testing happens via
> > Devstack. A parallel management tool to what most people use to actually
> > operate OpenStack.
> >
> >> I think focusing on the existing configuration management projects it
> >> the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
> >> know set of "constellations" in an opinionated would make deployment
> >> easy (for most people who are using one of those already) and ,
> >> ussuming the opionions are the same :) make consumption easier as
> >> well.
> >>
> >> As an example when I started using OpenStack (Essex) we  had recently
> >> switch to Ubuntu as our Linux platform and Pupept as our config
> >> management. Ubuntu had a "one click MAAS install of OpenStack" which
> >> was impossible as it made all sorts of assumptions about our
> >> environment and wanted controll of most of them so it could provide a
> >> full deployemnt solution.  Puppet had a good integrated example config
> >> where I plugged in some local choices and and used existing deploy
> >> methodologies.
> >>
> >> I fought with MAAS's "simple" install for a week.  When I gave up and
> >> went with Puppet I had live users on a substantial (for the time)
> >> cloud in less htan 2 days.
> >>
> >> I don't think this has to do with the relative value of MASS and
> >> Puppet at the time, but rather what fit my existing deploy workflows.
> >>
> >> Supporting multiple config tools may not be simple from an upstream
> >> perspective, but we do already have these projects and it is simpler
> >> to consume for brown field deployers at least.
> >>
> >
> > I don't think anybody is saying we would slam the door in the face of
> > people who use any one set of tools.
> >
> > But rather, we'd start promoting and using a single solution for the bulk
> > of community efforts. Right now we do that with devstack as a reference
> > implementation that nobody should use for anything but dev/test. But
> > it would seem like a good idea for us to promote a tool for going live
> > as well.
> 
> Except by that very statement, you slam the door in the face of tons of existing
> knowledge within organizations. This slope has a sheer face.
> 
> Promoting a single solution would do as much harm as it would good, for all it’s
> worth. In such a scenario, the most advocated method would become the only
> understood method, in spite of all other deployment efforts. Each project that
> did not have the most mindshare would become more irrelevant than they are now
> and further slip into decay. For those that did not have the fortune or
> foresight to land on this hypothetical winning side, what for their efforts,
> evolve or gtfo?
> 
> I'm not saying Fuel or Salt or Chef or Puppet or Ansible needs to be the
> 'winner', because there isn't a competition, at least in my opinion. The way I
> see it, we're all working to get to the same place. Our downstream consumers
> don’t really care how that happens in the grand scheme, only that it does.
> 
> >
> > __________________________________________________________________________
> > 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
> 
> 
> __________________________________________________________________________
> 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
> 
> __________________________________________________________________________
> 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