[openstack-dev] [tripleo] Request for input: scaling the number of Ceph clusters deployed in the overcloud
skramaja at redhat.com
Wed Nov 22 05:26:37 UTC 2017
We had a similar kind of requirement to differentiate parameters
between overcloud compute nodes, like a cluster having DELL and HP
machines have different hardware layout, but DPDK requires the
specific CPU information of a hardware layout to function effectively.
We addressed it by using different roles and role-specific
parameters. There will be 2 roles for compute: ComputeOvsDpdkHP and
ComputeOvsDpdkDell. And using role-specific parameters, the parameters
are targeted to the specific role of a service. The dpdk service files
 uses this format to merge the parameters.
On Tue, Nov 21, 2017 at 4:46 PM, Giulio Fidente <gfidente at redhat.com> wrote:
> we're currently exploring ways to deploy multiple Ceph clusters in the
> 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev