Open Stack

Do you have any specific suggestions on things our community can do to
encourage adoption? I hear lots of complaints but not many specific
suggestions.

-jay

On Sep 23, 2017 3:07 AM, "Adam Lawson" <alawson at aqorn.com> wrote:

> 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
>
>
> *Adam Lawson*
>
> Principal Architect
> Office: +1-916-794-5706 <(916)%20794-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-Apri
>> l/115319.html
>> >
>>
>> Yes, constellations. Thanks!
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170924/ef530b27/attachment.html>