Open Stack

You are talking about OpenStack being hard because it's complex and at
the same time you're talking about using "non-linux-mainstream" tools
around. It's either flexibility or ease guys... Prescriptive is easy,
flexible is hard. When you want to learn about linux you're not
starting from compiling gentoo, you're installing ubuntu, click "next"
until it's finished and just trust it's working, after some time you
grow skills in linux and customize it to your needs.

We are talking about software that runs physics, hpc-like clusters,
mobile phone communication and wordpresses across thousands of
companies. It won't ever be simple and prescriptive. Best we can do is
as you said, hide complexity of it and allow smoother entry until
someone learns complexity. No tooling will ever replace experienced
operator, tooling can make easier time to gain this experience.

You mentioned Kubernetes as good example, Kubernetes is still
relatively young project and doesn't support some of things that you
yourself said you need. As it grows, as options becomes available, it
too will become more and more complex.

On 5 May 2017 at 14:52, Octave J. Orgeron <octave.orgeron at oracle.com> wrote:
> +1
>
> On 5/5/2017 3:46 PM, Alex Schultz wrote:
>>
>>
>>> Sooo... I always get a little triggered when I hear that OpenStack is
>>> hard to deploy. We've spent last few years fixing it and I think it's
>>> pretty well fixed now. Even as we speak I'm deploying 500+ vms on
>>> OpenStack cluster I deployed last week within one day.
>>>
>> No, you've written a complex tool (that you understand) to do it.
>> That's not the same someone who is not familiar with OpenStack trying
>> to deploy OpenStack. I too could quickly deploy a decently scaled
>> infrastructure with some of the tools (fuel/tripleo/puppet/etc), but
>> the reality is that each one of these tools is inherently hiding the
>> complexities of OpenStack.  Each (including yours) has their own
>> flavor of assumptions baked in to make it work.  That is also
>> confusing for the end user who tries to switch between them and only
>> gets some of the flexibility of each but then runs face first into
>> each tool's short comings.  Rather than assuming a tool has solved it
>> (which it hasn't or we'd all be using the same one by now), how about
>> we take some time to understand why we've had to write these tools in
>> the first place and see if there's something we improve on?  Learning
>> the tool to deploy OpenStack is not the same as deploying OpenStack,
>> managing it, and turning it around for the true cloud end user to
>> consume.
>>
>
>
> __________________________________________________________________________
> 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