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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
