[Openstack-operators] [puppet][kolla] Multi-node installation

Steven Dake (stdake) stdake at cisco.com
Wed Apr 13 08:40:16 UTC 2016


A suggestion to give Kolla a spin inside…

From: Rayson Ho <raysonlogin at gmail.com<mailto:raysonlogin at gmail.com>>
Date: Tuesday, April 12, 2016 at 1:58 PM
To: Emilien Macchi <emilien at redhat.com<mailto:emilien at redhat.com>>
Cc: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto: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<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160413/fccf0688/attachment.html>


More information about the OpenStack-operators mailing list