Open Stack

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