We should be able to compose the value of a config key from multiple TripleO services. This would be useful in scenarios like [1], where for example the list of keyrings to be provisioned on the nodes, defined by the single opentack_keys parameter, would be built concatenating values coming from multiple (but only enabled) services instead of being a single list provisioning all keyrings regardless of which service is enabled. Currently if the same key is defined by multiple services its value is set to the last one parsed/merged. 1. https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-base.yaml#L250
I am attempting a proper fix for this, in Director, in https://review.openstack.org/#/c/563112/
Hi Giulio, can you provide some example about how to verify that issue ?
(In reply to Artem Hrechanychenko from comment #7) > Hi Giulio, > can you provide some example about how to verify that issue ? There was a DNM submission in gerrit meant to test this functionality https://review.openstack.org/#/c/572070 In that submission we're setting different values for the same hiera key in two different services. While the CI logs have been deleted, if you look at my comments in that submission you'll see that on the nodes the value set for the keys have been merged to include all values set by each of the service and this was the purpose of the RFE. This is something we use for a few services but not something that users interact directly with, for example it does not apply to environment files. One of the potential benefits for the user of this RFE is that for example we don't need to create all the Ceph pools at once anymore (like the Cinder's volume backups pool), but while the RFE has landed the restructuring of the TripleO Ceph services hasn't happened yet.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:0045