Bug #1670
Mount parameters "dump" and "pass" should default to undefined
| Status: | Accepted | Start date: | 10/21/2008 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | mount | |||
| Target version: | - | |||
| Affected Puppet version: | 0.24.5 | Branch: | ||
| Keywords: | ||||
Description
Currently there is no way to leave the previous value of the fs dump and pass fields in /etc/fstab at their original pre-Puppet values. Both the dump and pass parameters default to 0 and obliterate any previous values.
Obviously some value is needed for completely new entries in the file, but for pre-existing entries, it would be nice if the previous values were preserved.
History
#1
Updated by Peter Meier over 4 years ago
ohookins wrote:
Currently there is no way to leave the previous value of the fs dump and pass fields in /etc/fstab at their original pre-Puppet values. Both the dump and pass parameters default to 0 and obliterate any previous values.
this isn’t imho the idea of puppet, either you’d like to manage the whole resource or nothing, but something between will always raise various problems.
Obviously some value is needed for completely new entries in the file, but for pre-existing entries, it would be nice if the previous values were preserved.
default values for these options might be an option, however this won’t be a solution for what you’d like to do and would avoid some typeing.
the only solution for your problem is to manage the resource completly, not only partially.
so I would say that this bug report should either migrated into a feature request, that there should be default valies for dump and pass or closed.
#2
Updated by Luke Kanies over 4 years ago
- Status changed from Unreviewed to Accepted
- Assignee set to Puppet Community
- Target version set to 4
Actually, I think the bug is valid, but it requires differentiating between creating the mount (when a default value of some kind is required) and modifying an existing mount.
#3
Updated by Oliver Hookins over 4 years ago
My rationale is that the file type (and many other types) will only modify the aspect of the resource that you specify. You wouldn’t expect the file type to wipe a file clean if you didn’t specify a source to copy, and likewise you wouldn’t expect the mount type to overwrite values you didn’t specify.
#4
Updated by James Turnbull about 4 years ago
- Assignee deleted (
Puppet Community)
#5
Updated by James Turnbull almost 2 years ago
- Target version deleted (
4)
#6
Updated by Justin Ellison over 1 year ago
Just bumped into this bug myself. Wanted to create a define like so:
define mount::options ($mountpoints = undef, $options = ['defaults', 'noatime', 'nodiratime']) {
include mount
$mounts = $mountpoint ? {
undef => $name,
default => $mountpoints,
}
# Setting properties to undef leaves them as-is
mount { $mounts:
pass => undef,
ensure => undef,
fstype => undef,
target => undef,
options => $options,
dump => undef,
device => undef,
notify => Exec["remount all"],
}
}
I have a custom fact that returns all locally mounted devices, and want to call my define above passing it the array of mountpoints. The net result is that I can ensure that all mountpoints are mounted with noatime and nodiratime, regardless of their other settings. However, running the above code results in it changing the dump and pass properties to 0 as well as changing the options.
Any way around that?
#7
Updated by Ben Hughes over 1 year ago
- Description updated (diff)
- Status changed from Accepted to Unreviewed
#8
Updated by Luke Kanies over 1 year ago
- Description updated (diff)
- Status changed from Unreviewed to Accepted