Closed Bug 1253147 Opened 5 years ago Closed 4 years ago
XML server copy/generate script does not delete old entries
Reproduction: * Remove a domain from an ISPDB file * Commit to SVN * Wait 15 minutes Actual result: * Config is still there Expected result: * Config for that domain is removed
I think this is the script: http://svn.mozilla.org/mozillamessaging.com/sites/ispdb.mozillamessaging.com/trunk/tools/convert.py
This is fixed https://github.com/thundernest/thundernest-ansible/blob/master/files/update.sh#L24 The server script now regenerates all entries and then moves that folder into place on the web server, so the effect is essentially that all files are deleted and then regenerated from scratch.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Any chance of doing it slightly more atomic so it's like the following? I worry that "rm -rf" could take long enough to run that there could be transient failures. ``` PURGEDIR=/var/www/html/autoconfig-purge mv $DEST $PURGEDIR mv $TEMP $DEST rm -rf $PURGEDIR ```
Noting that that's still not perfect. Something like changing a symlink might actually end up being actually atomic, but that has its own complexities.
Changed in https://github.com/thundernest/thundernest-ansible/commit/053d022697db051df0ff2c8671082dafd079a2fd rm -rf ran basically instantly in my testing, but I suppose it's possible the web servers could be under enough IO pressure even with SSDs that it would be a significant delay(ie more than 100-200ms). Note that this script only runs on a repo commit now(not on a timer like it used to) so this whole process actually happens very rarely, minimizing the frequency of any transient failures to only when we update the files. I removed the cron from the servers in the above commit, the webhook was added the other day.
Good point. Commits are super rare.
You need to log in before you can comment on or make changes to this bug.