So, yeah, as the person responsible for the current interface I agree it's not ideal, and I did consider something similar to what you described when I did it.
> if the sha256sum has changed, delete any /var/run/heat-config/deployed/<uuid>.json which corresponds to a group:puppet config
This is the problem - you have a bunch of deployment resources which are e.g CREATE_COMPLETE, then some hieradata changes, and we have to ensure all the deployments go e.g UPDATE_IN_PROGRESS, or it's impossible to detect any failure.
So, if we go with the checksum approach, we have to take that output and somehow wire it in to all the puppet-applying deployments, otherwise we have no failure path when the puppet re-apply happens.
So, yeah, as the person responsible for the current interface I agree it's not ideal, and I did consider something similar to what you described when I did it.
> if the sha256sum has changed, delete any /var/run/ heat-config/ deployed/ <uuid>. json which corresponds to a group:puppet config
This is the problem - you have a bunch of deployment resources which are e.g CREATE_COMPLETE, then some hieradata changes, and we have to ensure all the deployments go e.g UPDATE_IN_PROGRESS, or it's impossible to detect any failure.
So, if we go with the checksum approach, we have to take that output and somehow wire it in to all the puppet-applying deployments, otherwise we have no failure path when the puppet re-apply happens.