Issue #4430 has been updated by martin krafft.

Please see what I wrote about that in the report: there is no standard naming 
scheme, making it difficult for me to write a logcheck module that can be used 
by others, without enforcing my nomenclature.

I cannot try this out right now, but doesn't "files" refer to the fileserver? 
E.g.

<pre>
puppet:///files/somedir_served_by_fileserver
</pre>

and if not, then maybe "fileserver" could be used to explicitly pick the global 
fileserver?
----------------------------------------
Feature #4430: Overzealous deprecation warning
http://projects.puppetlabs.com/issues/4430

Author: martin krafft
Status: Rejected
Priority: Normal
Assigned to: 
Category: fileserving
Target version: 
Affected version: 0.25.4
Keywords: 
Branch: 


I have a few modules which install site-local files. The idea is that the
logic is in a publicly-shared module, but the actual file is provided by the
site admin.

I've always used the fileserver for that, e.g.
<pre>puppet:///logcheck/ignore.d.server</pre>.

As of late, I get the following deprecation notice when doing that:

<pre>
puppetmasterd[15672]: DEPRECATION NOTICE: Files found in modules without 
specifying 'modules' in file path will be deprecated in the next major release. 
 Please fix module 'logcheck' when no 0.24.x clients are present
</pre>

Maybe puppetmasterd could check whether I am trying to use the deprecated
syntax to address a module's file space, or whether a logcheck directory
exists in the global fileserver space, and hide the warning in that case?

I understand that an alternative approach would be to provide such site-local
files in modules, e.g.
<pre>puppet:///modules/site-local/logcheck/ignore.d.server</pre> or even
<pre>puppet:///modules/site-logcheck/ignore.d.server</pre>, but I don't really
see much benefit in that approach over the simpler fileserver approach.

Of course, some people have complex setups and might want to encapsulate
site-local data in modules, but that doesn't mean that everyone has to do
that.

Thanks for your consideration.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

Reply via email to