Issue #10917 has been updated by Daniel Pittman.

This is far and away the most innovative combination of features I have seen in 
Puppet; it really is awfully clever.  It is also firmly in the land of 
"undefined behaviour", in that it is using implementation happenstance in a 
bunch of different features to achieve a result that - while useful - is 
entirely unintentional.

My contention is that this is ultimately a failure of our model: we don't allow 
you to express the actual relationship here, so you are forced into these 
strange work-arounds.  (The concat pattern, and "export files from the node, 
import to the master, use generate() to read them into the catalog", and "ship 
extlookup data around as exported resources" patterns are also work-arounds to 
this problem.)

The ultimate desire is that we model the TSM configuration file as a resource, 
and the directories to back up as a resource that is "part of" the overall 
configuration file.

This is also present in a bunch of other places, such as Apache (apache config 
contains vhosts, which contain location blocks), DRBD (config file contains 
devices), and a whole bunch of other parts of the world.

Is that fair?  Is this really what you want - that you manage a bunch of 
`tsm::backup_this_directory` resources that are associated with a 
`tsm::configuration_file` resource in a way that allows you to consume the 
"directory" bits when you build that one config file?
----------------------------------------
Bug #10917: Virtual Define-based resources collect only once. Inconsistent with 
non-define-based resources
https://projects.puppetlabs.com/issues/10917

Author: Stephan Eckweiler
Status: Investigating
Priority: Normal
Assignee: Daniel Pittman
Category: parser
Target version: 
Affected Puppet version: 2.7.5
Keywords: 
Branch: 


Executive summary:
If I use the spaceship operator with an attached {} block to add additional 
attributes to an option of a define-based resource, then the first spaceship 
operater found will finalize the content of the option, and following spaceship 
operators won't be considered. When doing the same for non-define based 
resources, it works fine.

I understand that "realize" suggests that the first hit found should already 
realize it once and for all, but that works against the declarative nature of 
puppet, and against the concept of a "collection". "Collection" (a.k.a 
Spaceship Operator) suggests that it goes through everywhere, collects all the 
attributes, and then commits them. So "realize" and "collection" are 
semantically 2 different things.

Detailed description:
(as discussed here: 
http://groups.google.com/group/puppet-users/browse_thread/thread/c11fd64f4953a8b4/08ce80332430f90c#08ce80332430f90c)

A module that is responsible to roll out and configure TSM (a backup
tool). Basically I need a text file that mentions all directories that
have to be backed up. I want to make it a virtual resource and let
other modules configure which parts of it have to be backed up, e.g.
configure in the apache module that the apache logs of each defined
virtual server have to be backed up:

The node.pp is configured like this:

<pre>
apache::config {"virtualserver1":
    blah
}

apache:config {"virtualserver2":
    blah

}

@tsm::config { "$hostname":
    tsm_backup => ["/custdir1","/custdir2"]

}
</pre>

The @ means this is a virtual Define-based resource, so it is not
implemented until it gets realized.

/custdir1 and /custdir2 denote custom directories that have to be
backed up, but aren't managed by other puppet modules.

One module is supposed to add some directories to tsm_backup, I use
this configuration inside the apache module's config.pp:

<pre>
Tsm::Config<| title == $hostname |> {
    tsm_backup +> ["$apache_logs,$docroot],

}
</pre>

I can then use this array in the template for the conf file (dsm.sys,
virtualmountpoint and Domain, for those who know TSM). Up until here
it all works fine. The config file will contain /custdir1, /custdir2, /
apache/virtualserver1/logs, /apache/virtualserver2/logs, apache/
virtualserver1/docroot, apache/virtualserver2/docroot

But when I want to configure another module to also add its
directories to tsm_backup, so basically have another module, say
postfix config.pp which contains this:

<pre>
Tsm::Config<| title == $hostname |> {
    tsm_backup +> ["$postfix_logs],

}
</pre>

It will either contain the apache backup dirs OR the postfix backup
dirs, depending on which `<| |>` it finds first, but never both. 

If I use the same construct for non-define-based virtual resources, like for a 
user's groups, it works fine.


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