Issue #12930 has been updated by Henrik Lindberg.

The problem to me is that there is no additional named construct that can be 
symbolically referenced when it comes to nodes (they don't have a symbolic 
name, since they may have a regular expression instead of a hostname), and 
"snippets of logic" certainly do not have a name.

If the Puppet DSL had named procedures/functions, it would be possible to use 
the existing model, i.e. include include them, and then use them (i.e. call 
them), or simply search for them and autoload them on demand. This is 
essentially the same as doing import, but in a symbolic way.

I see a lot of practical problems with having a directory with numbered files 
to be executed in order. (Reminds me of picking a Basic program apart and 
storing a line per file.... shudders). I can see the convenience of "just 
dropping a file in", but if you have to start worrying about the order 
(variables defined in a particular order; one thing should win over another 
etc.) and if have to start renumbering your files - shudders again, and they 
don't have symbolic names, and then versioning on top of that...).

A user that wishes to use functions/procedures today can do so via the Ruby DSL 
- I think we should offer the same in the Puppet DSL.
----------------------------------------
Feature #12930: Provide a manifest directory where all manifests are 
automatically parsed.
https://projects.puppetlabs.com/issues/12930#change-78532

Author: Nigel Kersten
Status: Investigating
Priority: Normal
Assignee: J.D. Welch
Category: 
Target version: 3.x
Affected Puppet version: 
Keywords: ux
Branch: 


There is at least one major use case where users need to import a set of 
manifest files, the following pattern:

<pre>
# manifests/site.pp
import nodes/*.pp
</pre>

As per the parent ticket, we're looking to deprecate `import`, and the most 
obvious solution appears to be to offer a configuration option for a directory 
where all manifest files are automatically parsed, much like site.pp is now.

This option *does* need to be per-environment.

Randall, I'm looking for input from your team on the user-facing design here, 
and if this solution is appropriate, tactical info like the actual name of the 
configuration parameter.



-- 
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