On Dec 7, 2010, at 7:20 AM, Peter Meier wrote:
[...]
> For example can't we flatten the catalog? Means: sending only "real"
> resources such as user, file, exec down to the client. Why do we need to
> send down defines? Actually all the relations for the graph could be
> mapped down to "real" resources contained within the defines, not?
[...]

Sorry to trim so heavily, but I think this is the main point of your email, so 
I figured I would just reply to it.

While I have some concerns about whether this should always be used or just be 
an optional feature, I think it's a reasonable thing to support.  It might be 
something that makes sense to start as a kind of post-compile filter, and based 
on results there we could look to integrate it into the core.

However, there are a few technical hurdles we need to cross before we can do it 
in the core.  In particular, we need to resolve all relationships before we 
trim the catalog in this way - e.g., someone can currently depend on one of 
those wrapping definitions, and if you just remove that wrapper, the dependency 
will fail.

One of our goals is to get to the point where the dependencies are all resolved 
on the server anyway, and this could be a good driver to get that done.  I also 
want to make it easier to have things like post-compile filters on the server 
for this kind of work, but it's not all that challenging at this point - at 
worst, you could do something like create a 'compile_trim' terminus that uses 
the existing compiler terminus but trims the results in the way you're 
mentioning, and then start puppetmasterd with --catalog_terminus=compiler_trim.

Does that make sense?  Is it worth your experimenting with that?

-- 
Computers are not intelligent.  They only think they are.
---------------------------------------------------------------------
Luke Kanies  -|-   http://puppetlabs.com   -|-   +1(615)594-8199




-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" 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-dev?hl=en.

Reply via email to