On 11/02/15 17:06, Dan Prince wrote:
I wanted to take a few minutes to go over the progress we've made with
TripleO Puppet in Kilo so far.
For those unfamilar with the efforts our initial goal was to be able to
use Puppet as the configuration tool for a TripleO deployment stack.
This is largely built around a Heat capability added in Icehouse called
Software Deployments. By making use of use of the Software Deployment
Puppet hook and building our images with a few puppet specific elements
we can integrate with puppet as a configuration tool. There has been no
blueprint on this effort... blueprints seemed a bit ridged for the task
at hand. After demo'ing the proof of concept patches in Paris we've been
tracking progress on an etherpad here:
https://etherpad.openstack.org/p/puppet-integration-in-heat-tripleo
Lots of details in that etherpad. But I would like to highlight a few
things:
As of a week or so all of the code needed to run devtest_overcloud.sh to
completion using Puppet (and Fedora packages) has landed. Several
upstream TripleO developers have been successful in setting up a Puppet
overcloud using this process.
As of last Friday We have a running CI job! I'm actually very excited
about this one for several reasons. First CI is going to be crucial in
completing the rest of the puppet feature work around HA, etc. Second
because this job does require packages... and a fairly recent Heat
release we are using a new upstream packaging tool called Delorean.
Delorean makes it very easy to go back in time so if the upstream
packages break for some reason plugging in a stable repo from yesterday,
or 5 minutes ago should be a quick fix... Lots of things to potentially
talk about in this area around CI on various projects.
The puppet deployment is also proving to be quite configurable. We have
a Heat template parameter called 'EnablePackageInstall' which can be
used to enable or disable Yum package installation at deployment time.
So if you want to do traditional image based deployment with images
containing all of your packages you can do that (no Yum repositories
required). Or if you want to roll out images and install or upgrade
packages at deployment time (rather than image build time) you can do
that too... all by simply modifying this parameter. I think this sort of
configurability should prove useful to those who want a bit of choice
with regards to how packages and the like get installed.
Lots of work is still ongoing (documented in the etherpad above for
now). I would love to see multi-distro support for Puppet configuration
w/ TripleO. At present time we are developing and testing w/ Fedora...
but because puppet is used as a configuration tool I would say adding
multi-distro support should be fairly straightforward. Just a couple of
bits in the tripleo-puppet-elements... and perhaps some upstream
packages too (Delorean would be a good fit here for multi-distro too).
Great work, I'd love to see us either replace this fedora job with a
centos one or add another job for centos, I think this would better
represent what we expect endusers to deploy. Of course we would need
todo a bit of work to make that work, I'd be willing to help out here if
we decide to do it.
Also, the feedback from those in the Puppet community has been
excellent. Emilien Macchi, Yanis Guenene, Spencer Krum, and Colleen
Murphy have all been quite helpful with questions about style, how to
best use the modules, etc.
Likewise, Steve Hardy and Steve Baker have been very helpful in
addressing issues in the Heat templates.
Appreciate all the help and feedback.
Dan
__
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
