@msnyder It should, but I can’t guarantee anything. In the past it would, certainly because of how replication operated. It was an all or none type of thing.
It would delete everything from the /images folder and make the master’s images folder a “copy” on the nodes. Of course this worked, but it left a lot of “unknowns” in the mix and didn’t allow any granularity. For example, if the d1.fixed_size_partitions for /images/someimage changed, but the d1p1.img and d1p2.img file (not reality but for the example’s sake) didn’t change at all, it would delete the WHOLE image and force replication down. While this has it’s upsides, it can also cause a huge strain on network performance considering the files can be very large sometimes. (Pro’s vs. Con’s can be thought here).
With the restructured layout for replication, each file is checked individually within an image and only the “changed” files are deleted and re replicated. This also allows you to say which images you want to be replicated at an individual level. (Granular control). Of course this makes it so deletions aren’t autonomous. That said, I’m fairly sure I have the layout set to search all nodes/storage groups it’s assigned to and remove them from ALL places, but I haven’t looked at the way deletes happen in a fairly long time. Sorry I should know it, but I’m working a full time job, plus updating the source code in FOG, plus building kernels, and maintaining Inits. I think you might understand why I might forget things from now and then.