On Fri, Dec 23, 2016 at 02:21:00PM +0000, Steven Hardy wrote: > I commented on the bug, I'm not sure about this as it seems to overlap with > our service_config_settings interface, which IIRC landed slightly after > your previous patches for opstools things, and potentially provides a > cleaner way to approach this.
I'm not sure I see how to apply that, but let me further describe the use case and you can perhaps point me in the right direction. > Perhaps you can point to some examples of this usage, then we can compare > with the service_config_settings approach? > > I suspect the main difference is you need to append data for each service > to e.g the collectd configuration? Let's take the existing Fluentd support as an example. We want the ability for every service to provide a logging source configuation for Fluentd, which will get aggregated into a logging_sources list and then ultimately used in puppet-tripleo to populate a series of ::fluentd::config resources. Currently, the aggregation happens in a combination of puppet/services/services.yaml (which aggregates the logging_source attribute from all the services in the service chain) and in overcloud.j2.yaml (which actually instantiates the hiera data). With the LateServiceChain I've proposed, this could all be isolated inside the fluentd composable service: it would not be necessary to expose any of this logic in either services.yaml or overcloud.j2.yaml, leading. Additionally, it would not require the fluentd service to have any a priori knowledge of what services were in use; it would simply aggregate any configuration information that is provided in the primary service chain. It would also allow us to get rid of the "LoggingConfiguration" resource, which only exists as a way to expose certain parameter_defaults inside services.yaml. -- Lars Kellogg-Stedman <l...@redhat.com> | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/
signature.asc
Description: PGP signature
__________________________________________________________________________ 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