[openstack-dev] [tripleo] Request for input: scaling the number of Ceph clusters deployed in the overcloud
Giulio Fidente
gfidente at redhat.com
Tue Nov 21 11:16:33 UTC 2017
Hi,
we're currently exploring ways to deploy multiple Ceph clusters in the
overcloud.
Given Ceph is now managed by a ceph-ansible playbook, we can "easily"
deploy multiple Ceph clusters running multiple times the playbook with
different parameters and inventory.
The initial idea to make this consumable in TripleO has been to have
jinja add a prefix to the Ceph service names and its parameters, and let
the user build custom roles (deploying on each a different instance of
the Ceph service) to distribute the Ceph services as needed on any
arbitrary role.
The benefits of the above approach are that daemons of different Ceph
clusters can be colocated on the same node and that operators continue
to customize any Ceph parameter using heat environment files as they
used to (they just add the jinja prefix to the parameter name).
The cons are that we'd need to scale (hence use jinja) also for other
services, like Cinder or Nova because the Ceph parameters can be
consumed by those too.
An alternate proposal has been to tag the roles, bound the Ceph cluster
to a tag to build the inventory and use role-specific settings so that
instances of the Ceph services deployed on a role would get different
parameters based on the role they run on.
The most important benefit that I can see of the above approach is that
it is a lot less intrusive as it does not require jinja processing of
the templates but I think I do not understand fully how the
implementation would look like so I was curious if there are examples in
tree of anything similar?
I would also like to know if other people is interested in this same
functionality so that we can come up with a more generalized solution?
Last but not least, I would like to hear more input, ideas and feedback
to see if there are more ways of doing this!
Thanks for the feedback
--
Giulio Fidente
GPG KEY: 08D733BA
More information about the OpenStack-dev
mailing list