Hi,
I want to assert a file exists - but in a way that doesn''t have the
potential to
create conflicting resource definitions.
I know this has been asked many times before:
"How can I check whether a file exists, like
''File.exists?(file)''
or ''-f $file''?"
My very specific use case is with a user-account define. I want something like
this:
define user_account($name, $shell = ''/bin/bash'', /* ... */) {
/* ... */
assert file_exists($shell) # make sure the shell is available
/* ... */
}
I don''t want to create the file $shell, nor do I care how it gets
there, but I
want it to be there (and ideally, executable). Declaring a resource
user("foo":
shell = $shell) doesn''t appear to assert this by itself (trying in
2.7.9).
Just to be clear, "require File[$shell]" and equivalents are no good,
because
they force me to define a File resource which "owns" the file $shell,
and since
there can only be one of those I am in trouble if something else wants to define
the same condition. In general I cannot know if this is being asserted
elsewhere by the author of another module.
However, the question has a more general aspect. Why doesn''t core
Puppet make
assertions like this easy? It seems a simple, obvious, and common thing to
want. And not just for files - I often want to express similar assertions about
users, groups, packages, and probably other resources.
This question seems like it ought to be addressed in the puppet FAQ [1], but I
can''t find any discussion of it there, nor in the puppet cookbook [2],
puppet
language guide [3], nor the "Puppet types" reference page [4].
I know there are workarounds of sorts:
- if !defined(File[$shell]) { file{ $shell: ensure =>
''exists'' } }
- Exec { "check ${shell} exists for ${user}":
command => "/usr/bin/test -f
''${shell}''" }
- if inline_template("<% File.exists?(shell)?
''true'':''false'' %>") ==
"true"
{ /* fail somehow */ }
- define a custom function which simply does File.exists?(shell) and fails if
false
They are all sledgehammers to crack a nut, the first is apparently dangerous and
another thread on this list is proposing to outlaw it.
To sum up, it appears that this feature is missing for a reason, but why? And
what''s the best workaround available?
Cheers,
N
1. http://docs.puppetlabs.com/guides/faq.html
2. http://www.puppetcookbook.com/
3. http://docs.puppetlabs.com/guides/language_guide.html
4. http://docs.puppetlabs.com/references/2.7.9/type.html
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Tue, Jan 24, 2012 at 7:39 PM, Nick <oinksocket@letterboxes.org> wrote:> I want to assert a file exists - but in a way that doesn''t have the potential to > create conflicting resource definitions. > > I know this has been asked many times before: > > "How can I check whether a file exists, like ''File.exists?(file)'' > or ''-f $file''?" > > My very specific use case is with a user-account define. I want something like > this: > > define user_account($name, $shell = ''/bin/bash'', /* ... */) { > /* ... */ > > assert file_exists($shell) # make sure the shell is available > > /* ... */ > } > > I don''t want to create the file $shell, nor do I care how it gets there, but I > want it to be there (and ideally, executable). Declaring a resource user("foo": > shell = $shell) doesn''t appear to assert this by itself (trying in 2.7.9). > > Just to be clear, "require File[$shell]" and equivalents are no good, because > they force me to define a File resource which "owns" the file $shell, and since > there can only be one of those I am in trouble if something else wants to define > the same condition. In general I cannot know if this is being asserted > elsewhere by the author of another module. > > However, the question has a more general aspect. Why doesn''t core Puppet make > assertions like this easy? It seems a simple, obvious, and common thing to > want. And not just for files - I often want to express similar assertions about > users, groups, packages, and probably other resources. > > This question seems like it ought to be addressed in the puppet FAQ [1], but I > can''t find any discussion of it there, nor in the puppet cookbook [2], puppet > language guide [3], nor the "Puppet types" reference page [4]. > > I know there are workarounds of sorts: > > - if !defined(File[$shell]) { file{ $shell: ensure => ''exists'' } } > > - Exec { "check ${shell} exists for ${user}": > command => "/usr/bin/test -f ''${shell}''" } > > - if inline_template("<% File.exists?(shell)? ''true'':''false'' %>") == "true" > { /* fail somehow */ } > > - define a custom function which simply does File.exists?(shell) and fails if > false > > > They are all sledgehammers to crack a nut, the first is apparently dangerous and > another thread on this list is proposing to outlaw it. > > 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. 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 Thanks, Nan -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.htmlOk - 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 puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jan 25, 2012, at 8:30 AM, Nick wrote:> 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.I just want to say +1 to this. I have found Puppet to be a wonderful way to deeply tie all your automation to an exact known configuration of hosts, but pretty much useless for dealing with situations in a generalized fashion. It is hard enough to track all the dependencies on modules being written by different people within the same team. I cannot image the pain which must be felt by people who have modules written by geographically and politically disperse teams. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Jan 25, 2012 at 08:53:15AM -0800, Jo Rhett wrote:> On Jan 25, 2012, at 8:30 AM, Nick wrote: > > 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. > > > I just want to say +1 to this. I have found Puppet to be a wonderful way to deeply tie all your automation to an exact known configuration of hosts, but pretty much useless for dealing with situations in a generalized fashion. It is hard enough to track all the dependencies on modules being written by different people within the same team. I cannot image the pain which must be felt by people who have modules written by geographically and politically disperse teams.(Define "generalized"?) Also, could you expound? I don''t know any production scenario where it''s desirable to have anything other than "an exact known configuration of hosts".> -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and other randomness > > -- > 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+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 25/01/12 16:59, Christopher Wood wrote:> Also, could you expound? I don''t know any production scenario where it''s desirable to have anything other than "an exact known configuration of hosts".Well, it''s one thing to have an exact known and audited configuration. It''d be another to try and combine two modules and then be forced to refactor parts of them out into a shared module in order to get them to work together, because they both want to manage the same resources. This costs time and money, and increases the chance of breaking what may be a tested solution. N -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jan 25, 10:53 am, Jo Rhett <jrh...@netconsonance.com> wrote:> On Jan 25, 2012, at 8:30 AM, Nick wrote: > > > 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. > > I just want to say +1 to this. I have found Puppet to be a wonderful way to deeply tie all your automation to an exact known configuration of hosts, but pretty much useless for dealing with situations in a generalized fashion. It is hard enough to track all the dependencies on modules being written by different people within the same team. I cannot image the pain which must be felt by people who have modules written by geographically and politically disperse teams.For the most part, I think this reflects the difficulty of the underlying problem more than any inadequacy of Puppet. If multiple independent subsystems place different demands on the same resources, then you have a mess to sort out no matter what tools you use to do it. On the other hand, if multiple independent subsystems place the same demands on certain resources, then that''s pretty easy to handle, with Puppet or otherwise. That''s not to deny that there is room for Puppet to improve here, but I suspect there is less room than you suppose. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jan 25, 2012, at 8:59 AM, Christopher Wood wrote:> (Define "generalized"?)Works in more than one specific situation.> Also, could you expound? I don''t know any production scenario where it''s desirable to have anything other than "an exact known configuration of hosts".One thing about a well-written piece of generic code is that it can be used in many environments. A lot of my modules do things like "do I have an external interface or am I behind the firewall?" and do different things based on those answers. Likewise, when dealing with software components you could be on a system dedicated to just that one component, or you could be on a Dev/QA box which has dozens of such components installed. The behavior calls for different actions there. It is very tricky, to the point of impossible in some scenarios, to write this kind of intelligent decision choices in Puppet today. You can successfully determine if a given class is loaded in the client''s manifest, but determining if certain things are set within the class is only possible in situations where ordering can be clearly constrained. This makes it truly impossible for someone on a different team to write a generic purpose module to fit Dev/QA/Prod-US/Prod-EU/Prod-AP/etc environments without having someone sit down and carefully work out the dependency flow through the modules to make this happen. And frankly, that kind of hardcore one-two-three ordering goes against the design philosophy of Puppet. It''s also nearly impossible when the ordering is more like 1, 2...67588, 67589 operations. I don''t believe that Puppet 2.x is capable of solving this problem. But I believe it should be a heavy design criteria for Puppet v3. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jan 26, 2012, at 6:19 AM, jcbollinger wrote:> For the most part, I think this reflects the difficulty of the > underlying problem more than any inadequacy of Puppet. If multiple > independent subsystems place different demands on the same resources, > then you have a mess to sort out no matter what tools you use to do > it. On the other hand, if multiple independent subsystems place the > same demands on certain resources, then that''s pretty easy to handle, > with Puppet or otherwise.I disagree. I have about 12 different modules, any combination of which may be applied to a given system, all of which need to ensure that sshd is installed and running on a system. They all have a single, common need. However, some of those modules also run on systems where we don''t need to ensure that sshd is running. The solution to this is an interlocking maze of module dependancies which is downright terrifying. You can''t import because of redefinitions. You yourself know well and deeply the issues involved with calling the same class from different places with different parameters. It is nearly impossible to get there from here. The ability for puppet to say "oh, I''ve seen this definition before and it''s exactly the same so that''s not an error" would be a tremendous improvement.> That''s not to deny that there is room for Puppet to improve here, but > I suspect there is less room than you suppose.I did an intensive deep dive on the current puppet code base regarding this issue, and my diagnosis was that it was currently impossible without a complete rewrite of the dependency hierarchy, and likely the addition of a third phase between the current two to improve this situation. Assuming I am right, this is a major overhaul. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Jan 26, 2012 at 6:19 AM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Jan 25, 10:53 am, Jo Rhett <jrh...@netconsonance.com> wrote: > > On Jan 25, 2012, at 8:30 AM, Nick wrote: > > > > > 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. > > > > I just want to say +1 to this. I have found Puppet to be a wonderful way > to deeply tie all your automation to an exact known configuration of hosts, > but pretty much useless for dealing with situations in a generalized > fashion. It is hard enough to track all the dependencies on modules being > written by different people within the same team. I cannot image the pain > which must be felt by people who have modules written by geographically and > politically disperse teams. >It''s actually not that bad at all from past experience when all the content is being written in-house, even if the authors are organizationally, politically and geographically disperse. If you have dependencies upon foreign content you didn''t author, express it at the class level. This allows the other authors to refactor their own classes internally, and not break your dependencies. If you can''t do this, one or both sides need to do refactoring so that it''s possible. If you''re building content you expect others to use more than once within a given catalog, provide it in the form of defined types with well-named parameters. You do need to have a robust release process in place along the lines of the classic dev -> test -> prod environments. If your teams push out change at significantly different rates, you may need to break up environments more to allow for this flexibility. For the most part, I think this reflects the difficulty of the> underlying problem more than any inadequacy of Puppet. If multiple > independent subsystems place different demands on the same resources, > then you have a mess to sort out no matter what tools you use to do > it. On the other hand, if multiple independent subsystems place the > same demands on certain resources, then that''s pretty easy to handle, > with Puppet or otherwise. > > That''s not to deny that there is room for Puppet to improve here, but > I suspect there is less room than you suppose. >+1 There are some things we could all do collectively to improve the situation, particularly around pre-commit hooks to version control. Functionality I''ve found useful in the past here was: * check whether the changed manifests parse * verify whether foreign class dependencies are fulfilled * verify whether references to file sources actually exist etc etc -- Nigel Kersten Product Manager, Puppet Labs -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi, On 01/26/2012 08:14 PM, Jo Rhett wrote:> One thing about a well-written piece of generic code is that it can be used in many environments. A lot of my modules do things like "do I have an external interface or am I behind the firewall?" and do different things based on those answers. Likewise, when dealing with software components you could be on a system dedicated to just that one component, or you could be on a Dev/QA box which has dozens of such components installed. The behavior calls for different actions there.what about custom facts, then? On 01/26/2012 08:22 PM, Jo Rhett wrote:> You can''t import because of redefinitions. You yourself know well anddeeply the issues involved with calling the same class from different places with different parameters. It is nearly impossible to get there from here. Have you considered combining class inheritance with parameters? I have found that in many situations, it''s extremely helpful to be able to include an unparameterized base class to satisfy dependencies, and allow nodes to include additional subclasses that take care of the gory details. Granted, this approach won''t float any boat out there, but potentially helpful in the SSH example you gave. Cheers, Felix -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> On 01/26/2012 08:14 PM, Jo Rhett wrote: >> One thing about a well-written piece of generic code is that it can be used in many environments. A lot of my modules do things like "do I have an external interface or am I behind the firewall?" and do different things based on those answers. Likewise, when dealing with software components you could be on a system dedicated to just that one component, or you could be on a Dev/QA box which has dozens of such components installed. The behavior calls for different actions there.On Jan 27, 2012, at 1:05 AM, Felix Frank wrote:> what about custom facts, then?Trust me, I''ve used a lot of custom facts. This works great for acting on different information, it doesn''t really help Puppet deal with diverse requirements.> Have you considered combining class inheritance with parameters?I''ve done a bit of class inheritance and I think this works great when I''m deeply tying together two bits I wrote. I don''t believe that class inheritance works well for situations where two or three different teams are trying to express their needs in a simple way.> I have found that in many situations, it''s extremely helpful to be able > to include an unparameterized base class to satisfy dependencies, and > allow nodes to include additional subclasses that take care of the gory > details.This is just moving the problem around. It doesn''t change the fact that you have two diverse modules with two diverse sets of needs for the same resource, and you can''t express that easily in puppet. You''re just moving the problem from a-module and b-module to ssh:a-module-needs and ssh:b-module-needs. I''ll admit that I haven''t finished plunging the ocean for what you can do by virtualizing an object and then materializing it later, but all the commentary on other threads keeps saying that you shouldn''t be using virtual objects to meet that need. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jan 26, 1:22 pm, Jo Rhett <jrh...@netconsonance.com> wrote:> On Jan 26, 2012, at 6:19 AM, jcbollinger wrote: > > > For the most part, I think this reflects the difficulty of the > > underlying problem more than any inadequacy of Puppet. If multiple > > independent subsystems place different demands on the same resources, > > then you have a mess to sort out no matter what tools you use to do > > it. On the other hand, if multiple independent subsystems place the > > same demands on certain resources, then that''s pretty easy to handle, > > with Puppet or otherwise. > > I disagree. I have about 12 different modules, any combination of which may be applied to a given system, all of which need to ensure that sshd is installed and running on a system. They all have a single, common need. However, some of those modules also run on systems where we don''t need to ensure that sshd is running. The solution to this is an interlocking maze of module dependancies which is downright terrifying.You seem to be describing my former case rather than my latter one, at least with respect to nodes that don''t need (and apparently don''t *want*) sshd to be running. All the same, were I faced with a problem of that sort I would probably take this approach: 1) Factor the ssh[d] management into its own module. 2) Avoid using any parameterized classes in the ssh module, or at least in its external interface. 3) Instead, have the ssh module use external data to determine node-by- node or role-by-role whether sshd should be running. 4) Make other modules ''include'' or ''require'' the appropriate classes of the ssh module, as needed. With that, all the modules depend on the ssh module, but they do not depend on each other, at least not for this purpose. It''s clean and simple. Enabling that result is the overarching benefit of the ability to assign the same class to a node multiple times.> You can''t import because of redefinitions. You yourself know well and deeply the issues involved with calling the same class from different places with different parameters. It is nearly impossible to get there from here.Parameterized classes do make it very difficult to get there from here. That''s one of the key reasons why I avoid them like the plague, and why I urge others to do so. But you *can* get there from here (for a wide variety of "heres"), and it doesn''t have to be hard.> The ability for puppet to say "oh, I''ve seen this definition before and it''s exactly the same so that''s not an error" would be a tremendous improvement.I wouldn''t object to that. As a practical matter, I think one would have to broaden it to cover all resources rather than only definitions, but that would be fine with me. It might even ease the problem of parameterized classes somewhat. HOWEVER, I wouldn''t be eager to rely on such a feature. I can see it all too easily producing a maintenance nightmare when one of perhaps many definitions of the same resource needed to be changed. If many resources were multiply-declared like that then the manifest set would likely be an unmaintainable morass. In the end, then, I suspect I would regard duplicate resource declarations much as I do parameterized classes: as an inferior and inherently problematic solution to the problem it addresses. Like parameterized classes, it would have the advantage of being fairly intuitive and relatively easy to write, and it would adequately address the problem it is targeted at. Also like parameterized classes, however, it would carry its own new problems that, for me, would outweigh those advantages. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> On Jan 26, 2012, at 6:19 AM, jcbollinger wrote: >>> For the most part, I think this reflects the difficulty of the >>> underlying problem more than any inadequacy of Puppet. If multiple >>> independent subsystems place different demands on the same resources, >>> then you have a mess to sort out no matter what tools you use to do >>> it. On the other hand, if multiple independent subsystems place the >>> same demands on certain resources, then that''s pretty easy to handle, >>> with Puppet or otherwise.> On Jan 26, 1:22 pm, Jo Rhett <jrh...@netconsonance.com> wrote: >> I disagree. I have about 12 different modules, any combination of which may be applied to a given system, all of which need to ensure that sshd is installed and running on a system. They all have a single, common need. However, some of those modules also run on systems where we don''t need to ensure that sshd is running. The solution to this is an interlocking maze of module dependancies which is downright terrifying. >On Feb 1, 2012, at 6:26 AM, jcbollinger wrote:> You seem to be describing my former case rather than my latter one, at > least with respect to nodes that don''t need (and apparently don''t > *want*) sshd to be running. All the same, were I faced with a problem > of that sort I would probably take this approach: > > 1) Factor the ssh[d] management into its own module. > 2) Avoid using any parameterized classes in the ssh module, or at > least in its external interface. > 3) Instead, have the ssh module use external data to determine node-by- > node or role-by-role whether sshd should be running. > 4) Make other modules ''include'' or ''require'' the appropriate classes > of the ssh module, as needed. > > With that, all the modules depend on the ssh module, but they do not > depend on each other, at least not for this purpose. It''s clean and > simple. Enabling that result is the overarching benefit of the > ability to assign the same class to a node multiple times.That simply doesn''t work, because you are basically asking the ssh module to have all the logic inside it for whether or not certain other classes need it. As expressed, it would require duplication of all the if/then in the other modules to be duplicated within this module. That''s simply not practical in a large or diversified team. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Feb 2, 4:42 pm, Jo Rhett <jrh...@netconsonance.com> wrote:> >> On Jan 26, 2012, at 6:19 AM, jcbollinger wrote: > >>> For the most part, I think this reflects the difficulty of the > >>> underlying problem more than any inadequacy of Puppet. If multiple > >>> independent subsystems place different demands on the same resources, > >>> then you have a mess to sort out no matter what tools you use to do > >>> it. On the other hand, if multiple independent subsystems place the > >>> same demands on certain resources, then that''s pretty easy to handle, > >>> with Puppet or otherwise. > > On Jan 26, 1:22 pm, Jo Rhett <jrh...@netconsonance.com> wrote: > >> I disagree. I have about 12 different modules, any combination of which may be applied to a given system, all of which need to ensure that sshd is installed and running on a system. They all have a single, common need. However, some of those modules also run on systems where we don''t need to ensure that sshd is running. The solution to this is an interlocking maze of module dependancies which is downright terrifying. > > On Feb 1, 2012, at 6:26 AM, jcbollinger wrote: > > > > > > > > > You seem to be describing my former case rather than my latter one, at > > least with respect to nodes that don''t need (and apparently don''t > > *want*) sshd to be running. All the same, were I faced with a problem > > of that sort I would probably take this approach: > > > 1) Factor the ssh[d] management into its own module. > > 2) Avoid using any parameterized classes in the ssh module, or at > > least in its external interface. > > 3) Instead, have the ssh module use external data to determine node-by- > > node or role-by-role whether sshd should be running. > > 4) Make other modules ''include'' or ''require'' the appropriate classes > > of the ssh module, as needed. > > > With that, all the modules depend on the ssh module, but they do not > > depend on each other, at least not for this purpose. It''s clean and > > simple. Enabling that result is the overarching benefit of the > > ability to assign the same class to a node multiple times. > > That simply doesn''t work, because you are basically asking the ssh module to have all the logic inside it for whether or not certain other classes need it. As expressed, it would require duplication of all the if/then in the other modules to be duplicated within this module. That''s simply not practical in a large or diversified team.How do you figure that? I repeat: "OTHER MODULES ''include'' or ''require'' the appropriate classes of the ssh module" (emphasis added). That is, the classes that need ssh (as THEY decide) ''include'' or ''require'' the appropriate classes of the ssh module. This is natural and very maintainable, and it does not require the ssh module to know anything about other modules. To complete the picture, where needed "the ssh module use[s] EXTERNAL DATA to determine node-by-node or role-by-role whether sshd should be running" (emphasis added). That might in fact not be needed anywhere, but if used it serves to *reduce* conditional logic in your manifests and to *remove* inter-module coupling. In particular, it does not require the ssh module to know which nodes or which roles should have sshd running. It only requires the ssh module to know the node or the node''s role[s], from which it *looks up* whether sshd should be running. That may be very different from your current design, but the design concept is sound. In fact, it''s the soundest Puppet design pattern I know that does not rely on an ENC (though it works fine with an ENC, too). I''d even say it''s what Puppetlabs should have embraced and promoted instead of parameterized classes. Nevertheless, if you use an ENC then you also have the option of putting the burden there. That you will do so seems one of the assumptions behind Puppetlabs''s current style recommendations, as those call for avoiding classes declaring (or ''include''ing or ''require''ing) other classes. Therefore, that approach necessarily involves moving all the messy conditional logic to the ENC and / or to external data, or at any rate out of the dependent classes themselves. This is the only viable option I know for shared, parameterized dependencies. You can mix those two approaches to some extent, if you''re careful, but what you must *not* do -- what it sounds like you are doing -- is to allow any two classes to each declare / include / require the same parameterized dependency, *even conditionally*. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.