On Jan 27, 7:58 am, Nick <oinksoc...@letterboxes.org> wrote: > On 26/01/12 17:48, jcbollinger wrote: > > > In particular, it is useful to recognize that dependencies are not just on a > > particular resource generally -- rather, they are on a particular resource > > having certain specific properties. > > Yes. > > Also: currently in Puppet one cannot say anything about a resource without a > declaration that you will "manage" it. (Unless perhaps that state happens to > be > encapsulated by a Fact, which typically isn't and in many cases couldn't > feasibly be - like the case of file attributes.)
Of course, this is a question of scale and foreknowledge. One can easily create a custom fact expressing any or all of the attributes of a specific file. I think one could even do it for all of the files in a directory, or even for an entire directory tree. Before too long, however, that's going to become quite slow, and it would be difficult to use on the Puppet side. I can't think of a persistent node state detail that couldn't be expressed via a custom fact, but if you need many such details, or if you can't be sure in advance which you will need, then you do have a problem. > Therefore many "dependencies" are created only because of a need to check some > state of a resource - which one may not want or need to manage. It sounds like you want to perform conditional logic on the agent. I am not at all comfortable with that idea, though perhaps I could become more so. It entails a much more fundamental change to Puppet than anything else we have been discussing. Or did you have something different in mind? > Here's a slightly different angle. [...] > Ideally we'd be able to separate out the aspects of a Resource which merely > assert what *should* be the case (ensure => present etc.) from those bits > which > would then change the state of the resource if it deviates. > > For the sake of discussion I'll call that former kind of declaration an > "Assertion". [...] > Possibly this doesn't fit all the use-cases which run into cross-module > dependency problems, but might significantly reduce the need to create the > dependencies in the first place. I could see implementing a version of your Assertion idea as a check- only Constraint, but I don't think there is yet an infrastructure to support that part. However, I don't see at all how the Assertion idea fits into the cross-module dependency picture. Perhaps this is because I don't see the purpose of declaring resources that you do not intend to manage. When I consider cross-module dependencies, I think the usual case is that a module *does* want ensure that particular resource properties are managed, but it may not care about other properties, and it cares about who owns Resources only insofar as someone has to own them and it affects who can manage them. I can imagine wanting to _assert_ Resource properties only as a workaround for not being able actually to manage them. Are there other reasons to want such a thing? > Anyway, I need to get back to work, I'll try to say more in a later email. That would help me to determine what I think about the idea. As it is, I suspect I don't quite understand what you are hoping to accomplish with it. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
