On Thu, Dec 22, 2016 at 02:02:12PM -0500, Lars Kellogg-Stedman wrote: > I've been working along with a few others on some "opstools" > composable services for TripleO: that is, services that provide > things like centralized logging, performance monitoring, or > availability/health monitoring. > > We've been running into a persistent problem with TripleO's > architecture: our services in many cases need configuration > information to be provided by other services in the stack, but there's > no way to introspect this data from inside a composable service > template. This has led to some rather messy and invasive changes to > things like puppet/services/services.yaml. > > In https://review.openstack.org/#/c/413748/, I've proposed the > addition of a secondary chain of services called LateServiceChain. > This is, like the existing ServiceChain resource, just a Heat > ResourceChain. Unlike the existing ServiceChain, it receives an > additional "RoleData" parameter that contains the role_data outputs > from all the services realized in ServiceChain.
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. We originally added this because there was a need to wire configuration data from any node to the nodes running e.g keystone, but it seems like the use-case you're describing is very similar? > This permits composable services in the LateServices chain to access > per-service configuration information provided by the other services, > leading to much cleaner implementations of these auxiliary services. > > I am attempting to use this right now for a collectd composable > service implementation, but this model would ultimately allow us to > remove several of the changes made in services.yaml to support Sensu > and Fluentd and put them back into the appropriate composable service > templates. 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? Steve __________________________________________________________________________ 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