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.orge...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev