Open Stack

+1 for Kolla (and yes, I realize I just suggested Packstack).  It certainly
is much easier to _operate_ once you get it up and running.

On Wed, Apr 13, 2016 at 1:40 AM, Steven Dake (stdake) <stdake at cisco.com>
wrote:

> A suggestion to give Kolla a spin inside…
>
> From: Rayson Ho <raysonlogin at gmail.com>
> Date: Tuesday, April 12, 2016 at 1:58 PM
> To: Emilien Macchi <emilien at redhat.com>
> Cc: "openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] [puppet] Multi-node installation
>
> On Tue, Apr 12, 2016 at 4:17 PM, Emilien Macchi <emilien at redhat.com>
> wrote:
> > If you need to start a composition layer from scratch, you'll need to
> > compose the manifests yourself.
> > Puppet OpenStack is not an opinionated project like TripleO, Fuel,
> > Kolla. We're a library of Puppet modules that you can use at wish.
> > You need to be a bit familiar with Puppet.
> > But if you look at wat we do in puppet-openstack-integration, you're
> > missing a few parameters to make it work in multi-node, it should not
> > be hard.
>
> Thanks for the the prompt reply, Emilien! (And hello from Toronto!)
>
> I am just trying to install OpenStack on a cluster of 3 CentOS machines. I
> tried the OpenStack Ansible installation, but there are 2 showstoppers:
>  - OpenStack Ansible works great on Ubuntu, but doesn't support RHEL (we
> have RHEL licenses, we use CentOS and Oracle Linux for R & D. Our
> production machines will be running RHEL so Ubuntu doesn't cut it.)
>
>
> Rayson,
>
> Kolla deploys multinode with high availability.  Kolla is an opinionated
> deployment management tool unless the Operator has opinions of their own.
> Kolla offers complete customization of any OpenStack parameter via
> augmentation files which override the defaults specified by Kolla.  This
> permits an Operator to have something working right out o the box, but
> change things around as the Operator's experience grows with OpenStack.
> Its essentially the best of both worlds :)
>
>
>  - If we install OpenStack behind an HTTP Proxy & firewall, then some
> parts of OpenStack setup do not work well with the proxy. So we install
> OpenStack outside the firewall and then bring them into the datacenter.
> However, with the OpenStack Ansible setup, every time the nodes boot up,
> they try to contact the package servers again to check for newer versions,
> and thus they would get errors as they need to go through the proxy.
>
>
> Kolla will work well for what I think you desire.  To upgrade kolla, you
> run "kolla-ansible upgrade".  There is no runtime automatic checking for
> new stuff.  Oracle also ships Kolla 1.0.0 as part of their OpenStack
> implementation.
>
>
>
> I use Puppet OpenStack because it works well on RHEL-based OSes & the
> installation doesn't seem to contact the outside world once it is
> configured. And I used Puppet a few years ago (mainly for basic
> provisioning in AWS/EC2), so that's another plus for Puppet. A few weeks
> ago I looked at Packstack, which calls the Puppet installation internally,
> but last time I used it I encountered other issues. However, as it supports
> multi-node installations, I think I will look at how it calls the Puppet
> manifests.
>
> If there is an easier way to install OpenStack (ideally 14.0, and we would
> like to stay as close to the official OpenStack source as possible) on
> RHEL, without trying to download newer packages once the installation is
> done, and runs on more than 1 machine, please let me know!
>
>
> I feel Kolla is pretty easy for operators to use and get their heads
> around.  I always ask new Operators to point out their top 3 pain points
> after eval.  When we started the project it was all over the place.  Now
> there doesn’t seem to be much if any pain points pointed out by Operators
> when operating Kolla.  A majority of people find it intuitive, well
> designed, and easy to operate and manage an OpenStack cloud long  term.  I
> personally think our top problem at this point is lack of documentation
> around operating Kolla long term – which will be rectified in May/June
> after Austin Summit concludes.
>
> Most folks get a deployment going on bare metal in 1-2 hours – sometimes
> with a little help from the kolla irc channel #kolla on freenode.  Our
> community runs 24 hours a day – so drop in if you have questions.  OSAD and
> Kolla are completely different experiences – the only thing they really
> have in common is the usage of Ansible as a dependency.
>
> Kolla documentation is here:
> http://docs.openstack.org/developer/kolla
>
> The Kolla repository is here:
> http://github.com/openstack/kolla
>
> To find out more about the design check out this Ansible blog post:
> https://www.ansible.com/blog/openstack-kolla
>
> In the recent user survey published, 1% of respondents are using Kolla in
> production, and 3% are using in testing.  This is up from zero in the last
> survey ;)  (Kolla entered the big tent 10 months ago, so the project is
> relatively fresh).  That said we have a small army of co-beta sites and
> developers so Linus's Law[1] applies.
>
> Version 2.0.0 will be completely production ready when tagged and released
> on April 15th and implements deploy and operational management for CentOS,
> Oracle Linux, Ubuntu, and Debian with either from source or from packaging
> as build options.  On the deployment targets only docker-engine and
> docker-py are required as dependencies.
>
> I'd love to have your feedback after an eval if you decide to undertake
> one.  Ping me as sdake on the #openstack-kolla channel on freenode.
>
> Regards
> -steve
>
> [1] https://en.wikipedia.org/wiki/Linus%27s_Law
>
>
> Thanks again,
> Rayson
>
> ==================================================
> Open Grid Scheduler - The Official Open Source Grid Engine
> http://gridscheduler.sourceforge.net/
> http://gridscheduler.sourceforge.net/GridEngine/GridEngineCloud.html
>
>
>
> >
> > Thanks for bringing this up,
> > --
> > Emilien Macchi
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160413/518df21f/attachment.html>