I've been watching this thread and I think we've already seen an excellent and uncontroversial suggestion towards simplifying initial deployment of OS - that was to push towards encoding Constellations into the deployment and/or config management projects.
On 26 September 2017 at 15:44, Adam Lawson <alaw...@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. > > 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...@cassiba.com> wrote: >> >> >> > On Sep 25, 2017, at 16:52, Clint Byrum <cl...@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-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 > -- Cheers, ~Blairo __________________________________________________________________________ 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
