[openstack-dev] [ptg] Simplification in OpenStack

Adam Lawson alawson at aqorn.com
Sat Sep 23 07:05:38 UTC 2017

Quick note (started quick anyway) since I haven't been as active on this
list as I have in the past.

Two things:

   1. Great topic and addresses a historical, persistent well-known problem
   with OpenStack - complexity. Technology is useless if it's so complex new
   organizations can't get it to work easily or reliably.

   2. I'm gonna call it as I'm seeing it: it makes me sick to read
   statements/replies by some members taking the time to itemize every single
   suggestion by another member to simplify OpenStack with one snarky remark
   after another. Thankfully (hopefully?) the influence of those individuals
   will lessen over time. It's literally poisonous to read and holds no value.

Okay aside from that, as an OpenStack architect now increasing my focus on
AWS/GCP as well as OpenStack, I would suggest there are two key areas with
OpenStack that desperately need to be simplified: the architecture and the
implementation. I never hear people say the architecture is too complex so
while that can see some improvements, what I hear over and over and over
again is how hard it is to deploy OpenStack on more than one machine
quickly and easily. I think that has to be the priority. Until deployments
are easy and stable and 'just work', that's a missed opportunity and
OpenStack will continue to scare away potential new users -- like we need
any more of that. OpenStack is deep in the trough of disillusionment (my
perception) whether others recognize it or not so anything that makes
OpenStack adoption easier should be our Numero Uno goal.

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.

That's what I got tonight. hve a great weekend.


*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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170923/c490229d/attachment.html>

More information about the OpenStack-dev mailing list