@Tristan - yes, sorry for the delay, I've now tested the following:
Via heatclient:
1. Create stack with a TemplateResource defined in /etc/heat/environment.d/default.yaml referencing the local filesystem
2. Modified the template file referenced
3. Update the stack with no other changes.
Turns out the concerns mentioned in comments #42 and #44 were unfounded, AFAICS this still works as it did before, and on update the modified file is loaded into the global environment, and the changes do take effect.
Via curl:
1. Created a stack referencing a nested stack defined in the "files" map - this worked as expected
2. Repeat previous step modifying the "files" map key so the type definition in the template points to a valid local path, but it's undefined in the "files" map of the request. This fails with "Invalid URL scheme file" and StackValidationFailed
So, I'm +2 on the fix, from my (admittedly fairly limited) testing it doesn't seem to break anything, and it fixes the reported issue - thanks Zane!
The patch applies fine via git apply or patch -p1, but I'll attach a git am friendly version shortly.
@Tristan - yes, sorry for the delay, I've now tested the following:
Via heatclient:
1. Create stack with a TemplateResource defined in /etc/heat/ environment. d/default. yaml referencing the local filesystem
2. Modified the template file referenced
3. Update the stack with no other changes.
Turns out the concerns mentioned in comments #42 and #44 were unfounded, AFAICS this still works as it did before, and on update the modified file is loaded into the global environment, and the changes do take effect.
Via curl:
1. Created a stack referencing a nested stack defined in the "files" map - this worked as expected Failed
2. Repeat previous step modifying the "files" map key so the type definition in the template points to a valid local path, but it's undefined in the "files" map of the request. This fails with "Invalid URL scheme file" and StackValidation
So, I'm +2 on the fix, from my (admittedly fairly limited) testing it doesn't seem to break anything, and it fixes the reported issue - thanks Zane!
The patch applies fine via git apply or patch -p1, but I'll attach a git am friendly version shortly.