Open Stack

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



-- 
Cheers,
~Blairo