Open Stack

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.

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.

-Jon

:That's what I got tonight. hve a great weekend.
:
://adam
:
:
:*Adam Lawson*
:
:Principal Architect
:Office: +1-916-794-5706
:
:On Thu, Sep 21, 2017 at 11:23 AM, Clint Byrum <clint at fewbar.com> wrote:
:
:> Excerpts from Jeremy Stanley's message of 2017-09-21 16:17:00 +0000:
:> > On 2017-09-20 17:39:38 -0700 (-0700), Clint Byrum wrote:
:> > [...]
:> > > Something about common use cases and the exact mix of
:> > > projects + configuration to get there, and testing it? Help?
:> > [...]
:> >
:> > Maybe you're thinking of the "constellations" suggestion? It found
:> > its way into the TC vision statement, though the earliest mention I
:> > can locate is in John's post to this ML thread:
:> >
:> > http://lists.openstack.org/pipermail/openstack-dev/2017-
:> April/115319.html
:> >
:>
:> Yes, constellations. Thanks!
:>
:> __________________________________________________________________________
:> 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


--