allow mode changes on files without restarting the service.
|Status:||Needs Decision||Start date:||06/13/2012|
|Assignee:||J.D. Welch||% Done:|
|Affected Puppet version:||2.7.14||Branch:|
I managed to have a booboo tonight by restarting a process which really shouldn’t be. What I ran into was that a mode change caused subscribe to fire and the process to restart. Also given that “replace” only affects file contents, this means that you can never, ever change the mode of a file for new installs only, either. So it’s always a risk of restarting a process.
I think it’s perfectly reasonable to want that subscribe/notify only fire on content changes. Also replace should maybe be expanded to also support giving other properties the same treatment perhaps? Not sure.
I have thought and thought and I just can’t find a situation where I think that changing the mode should cause a refresh. Owner or group in some circumstances, but not many. I think that the default should be content only, with an option to say “any attribute”.
RIP said: Lots of daemons ship files like accessible only by $daemon:$daemon when what we need is $daemon:$otherdaemon or maybe $daemon:$group_of_daemons. You want to notice $otherdaemon that it can now read that file etc
So I think this argues that we should have an option for what changes invoke a refresh. Something like
refreshon => 'content',
refreshon => ['owner','content'],
#1 Updated by eric sorenson 10 months ago
- Status changed from Unreviewed to Needs Decision
- Assignee set to Randall Hansen
Randall — There was a giant puppet-users discussion related to this:
Interested to hear if you think (a) it’s something to spend engineering time on and (b) if so, whether there’s a way to expose the functionality with a reasonable UX.