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[1] 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 [2] uses this format to merge the parameters. Regards, Saravanan KR [1] https://docs.openstack.org/tripleo-docs/latest/install/advanced_deployment/role_specific_parameters.html [2] https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/neutron-ovs-dpdk-agent.yaml#L59 On Tue, Nov 21, 2017 at 4:46 PM, Giulio Fidente <gfide...@redhat.com> wrote: > 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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev