Re: [openstack-dev] [tripleo] Request for input: scaling the number of Ceph clusters deployed in the overcloud

2017-11-21 Thread Saravanan KR
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  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


[openstack-dev] [tripleo] Request for input: scaling the number of Ceph clusters deployed in the overcloud

2017-11-21 Thread Giulio Fidente
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