Open Stack

> 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