[openstack-dev] [TripleO] Integration of non-puppet service configuration?

Steven Hardy shardy at redhat.com
Tue Jul 19 15:12:27 UTC 2016


Hi all,

Recently I've had a few discussions around $subject, and in particular
there are folks involved in our community who would like to enable an
optional alternative so puppet-ceph for configuring ceph services in a
deployed overcloud.

The alternative under discussion is ceph-ansible, and I did a minimal PoC
that shows the roles provided there can be driven via a similar method to
our existing puppet deployments:

https://github.com/hardys/heat-ceph-templates/blob/master/mon_cluster.yaml#L61

Instead of hieradata we'll have to wire the parameter derived values in to
each deployment (there may be other possible approaches, but this is how
the heat hook works by default).

It gets a bit (well, a lot actually) more complex when you consider how we
wire this in to tripleo-heat-templates, because atm we assume we can
combine all of the role_data config_settings and step_config data.

I don't think this works as well with ansible (because it's a more
imperative tool, and doesn't build a global catalog like puppet does), and
we also don't have any way to enable a mixture of puppet and ansible
deployed services right now.

All of this is definitely long-term (e.g Ocata and beyond), but I'd like to
get feedback of how we might make this possible, and if the service
abtractions we have in place now are sufficient to enable choice in config
management tooling long term.

Note that we'd probably still enable puppet-ceph by default, but this would
be an alternative which could be supported in paralell.

One thing which occurs to me is there's risk of config-management
split-brain, so we probably want to make this work depend on container
based deployments - any thoughts on e.g enabling external config generation
via ansible vis the puppet approach we have already proven?

Feel free to jump in with your thoughts here, and perhaps we can arrange
some live discussion with those folks interested in due course too.

Thanks,

Steve



More information about the OpenStack-dev mailing list