On 25/01/12 14:57, Nan Liu wrote: >> To sum up, it appears that this feature is missing for a reason, but why? >> And >> what's the best workaround available? > > I'm assuming you mean if a resources exist in the catalog and not the > question of whether a file exist on the agent since they are different > issues.
The way you word it, I'm not sure. I mean: I want to put constraints on files in a puppet module manifest, which apply to files on the agent. In a way that I don't stop some other module from making compatible assertions about on the same file. I just want to make sure the file is there, not stake my claim to the right to manage it. > > Either a separate class for common resources or virtual resources and > realizing them instead of declaring them in a define: > http://docs.puppetlabs.com/guides/virtual_resources.html Ok - that's aimed at my second point, and is the standard answer to sharing resource definitions. Can anyone say why the design makes it so hard to merely say "I want this file to exist"? Unless there's some clever trick I don't know about, shared classes and virtual resources don't really solve the issue. They only work if the modules sharing the resource know about each other's internals. Given that, two modules can both say "I want this shared definition realized", but they have to agree to use the *same* unique definition, and therefore become strongly coupled. So, in the example of a user_account() define, yes I can do something like this: # In a shared_definitions module somewhere: @file { "/bin/bash": ensure => 'present' } # In my users module: define user_account($name, $shell = '/bin/bash') { # ... realize File[$shell] user($name: shell => $shell, require => File[$shell]); # ... } But then I have to anticipate every possible value of $shell and define resources for them. Anything which is not defined like this is not usable within the scheme, because there will be no file resource to realize and require. And of course, it also means nothing else can say anything about any of these files without blowing up, because my code "owns" them. So far as I can see, this property of resources makes it hard to write self-contained and reusable modules, and this is frustrating. N -- You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users?hl=en.
