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. __________________________________________________________________________ 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