Open Stack

On Tue, Jul 19, 2016 at 11:12 AM, Steven Hardy <shardy at redhat.com> wrote:
> 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?

One thing about it, and you highlighted it very well:
we need to make sure ceph-ansible does not manage a resource that our
puppet deployment already do.

Example:
puppet create file1 but ansible removes file1.

If we disable puppet-ceph usage in TripleO, we also need to make sure
ceph-ansible is not intrusive as touching other resources that we
already manage in TripleO.
Other than that, I think it's doable.


Secondo, I would like to investigate when running Puppet and Ansible
in term of steps. For example, in the case of hyperconverged setup, we
need to make Ceph working before Cinder service to start for example.
Anyway, I think in the case of Ceph it's pretty safe to first deploy
Ceph before OpenStack. But what about future things we will integrate?
How to mix them within our steps? Just adding an area to investigate.

> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi