generation of tripleo config hash is broken in master
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Fix Released
|
High
|
Damien Ciabrini |
Bug Description
When deploying a stack or running a stack update, the deploy steps (re)generate the containers' config and (re)compute their config hash. This is being done by container-
A container <C> gets an associated tripleo config hash if and only if one of its bind mount contains /var/lib/
Currently the generation of the config hash is broken because container-puppet stopped parsing the bind mounts appropriately. From container-puppet.py logs:
2020-01-20 14:46:27,530 INFO: 714161 -- Finished processing puppet configs for neutron
2020-01-20 14:46:27,531 DEBUG: 714143 -- STARTUP_
2020-01-20 14:46:27,536 DEBUG: 714143 -- Looking for hashfile /var/lib/
2020-01-20 14:46:27,537 DEBUG: 714143 -- Looking for hashfile /var/lib/
2020-01-20 14:46:27,538 DEBUG: 714143 -- Looking for hashfile /var/lib/
As seen above, sometimes the config volume path is stripped from the service name, sometimes the full config path remains (memcached)... which prevent container-puppet.py to locate the hash file .md5sum associated to the service.
Consequently, stack update doesn't restart the service as expected when config changes.
Fix proposed to branch: master /review. opendev. org/703480
Review: https:/