Comments (4)
Currently, autofs::mount
permits $mapfile
to be undefined (that is its default), which it interprets as an indication that no map file for the mount should be named in the master map, and no physical map file should be managed. And this is a bit strange, because there is $mapfile_manage
to direct whether to manage a physical file, and specifying a map file in the master map is mandatory in all Autofs implementations I am familiar with. I think it is an historic quirk, possibly revolving around a now-obsolete mechanism for supporting the built-in -hosts
map. On one hand, then, it would make sense to generate the map file name automatically from the autofs::mount
title, as proposed.
On the other hand, however, the title already has a different, but similar use: it is the default value of the $mount
parameter. It would be pretty tricky to serve both purposes at the same time, though I guess in principle it could be done by requiring that at least one of $mapfile
and $mount
always be given explicitly.
Personally, I would be inclined to go the other way: leave the title's significance alone, and make $mapfile
mandatory. In fact, I wrote a note for myself earlier today to raise exactly that as an issue, and I still might do so.
from puppet-autofs.
@jcbollinger it's been a while. Any update to this?
from puppet-autofs.
@dhollinger, this feature request was filed against version 4 of the module, in which autofs::mount
had broader responsibilities than it does now. I wrote my previous comment before working out the refactoring that went into version 5. In v5, autofs::mount
manages only entries in the master map, not the corresponding map files. Its title is still used as the default for the mount
parameter, and the mapfile
parameter is now mandatory, per the alternative I suggested. On the other hand, map files are now managed by autofs::mapfile
, which does default to using its title as the path to the file.
That does not mean that $autofs::mount::mapfile
could not be made optional, prompting the map file name in the master map to be computed from the resource title. That would not take the exact form proposed here, however, because we still need to suppose that the title may be a path (to the mount point). We could trim off any leading directory part and build a map file name from the rest, but I am not inclined to do so because
- it would create a risk of hidden collisions,
- I prefer to see this particular data expressed explicitly in any case, to clearly connect
autofs::mount
resources with correspondingautofs::mapfile
resources, and - more generally, I prefer absence of a parameter to mean "this detail is unmanaged", as opposed to "Puppet will choose a value".
I make an exception to (3) for $autofs::mount::mount
because that is the type's unique identifier. It would be the namevar if the type were a native one rather than a defined one, so its association with the title is natural.
Overall, then, my recommendation would be to close this request without further changes. The use of the title of autofs::mapfile
can be considered a partial implementation, if you wish. I am not presently performing or planning any further work in this direction myself, and instead of the issue that I was considering filing in this area, I filed the several issues that were subsequently resolved in the v5 refactoring.
from puppet-autofs.
@jcbollinger It's been a little over a week since your response. I'm going to follow your recommendation and close this.
from puppet-autofs.
Related Issues (20)
- Documentation uses wrong name for autofs::map::mapfile HOT 2
- The mapfile banner should not be duplicated
- Executable maps cannot be built from multiple pieces HOT 7
- Catalog compilation can fail when managing the same map file via multiple autofs::map resources HOT 2
- Catalog compilation fails when mapcontents are given as a string
- Drop-in files created when $autofs::mount::use_dir is true should never be executable
- The Autofs::Mapentry data type is incomplete
- autofs::mount mapfile_manage is still useful - need to add back HOT 1
- enable support for mutli-mount entry. HOT 5
- parameter 'mappings' expects an Array value, got Struct HOT 2
- Feature: Add support for Darwin HOT 5
- Unknown variable: 'autofs::auto_master_map' in mount.pp HOT 2
- to include NIS/LDAP map HOT 5
- Cut a new release for updated dependencies
- Examples using Heira
- Merge Unique HOT 2
- Add Support for RHEL 8 HOT 4
- Dependency chain issue with puppetlabs-concat HOT 1
- Add AIX support HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from puppet-autofs.