Open Stack

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.