So in https://github.com/openstack/tripleo-heat-templates/blob/master/docker/docker-steps.j2#L169 we have the following lines:
{{role.name}}PuppetStepConfig:
type: OS::Heat::Value
properties:
type: string
value:
yaql:
expression:
# select 'step_config' only from services that do not have a docker_config
$.data.service_names.zip($.data.step_config, $.data.docker_config).where($[2] = null).where($[1] != null).select($[1]).join("\n")
data:
service_names: {get_param: [role_data, {{role.name}}, service_names]}
step_config: {get_param: [role_data, {{role.name}}, step_config]}
docker_config: {get_param: [role_data, {{role.name}}, docker_config]}
The problem is that in our current haproxy HA docker service we need both docker_config *and* step_config to do stuff. Namely in step_config we'd like to create the extra haproxy iptables rules that are needed when you split off galera/rabbit/etc off the haproxy nodes (controllers) whereas in docker_config we create the pacemaker bundle which manages the haproxy container.
In the current situation when we deploy an overcloud with galera and rabbitmq off to separate nodes, we can observe that the iptables rules on the haproxy node are not created:
https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/pacemaker/haproxy.yaml#L67
We discussed this with shardy and there was always the assumption that docker_config and step_config was an either/or kind of thing. While we could change this back it would have a larger impact.
The other options we discussed are:
- Use host_prep_task
- Move the logic to tripleo::firewall
- Add a OS::Tripleo:
Another option might be to just make it so that we can create the iptables rules on the host using a short-lived docker container.