I have a managed directory defined in one class. I need the ability to update a subset of files in the managed directory from a puppet define. I would like to simply define a new file resource that is a directory and have the files from this new resource simply overlay the existing managed directory. Of course I get a duplication declaration error since the File titles would be the same. Is there anyway to achieve this? I realize I could just update the source files but I need the flexibility to install to select nodes. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/YaSW5VHM0VsJ. 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 Wednesday, November 28, 2012 6:15:24 PM UTC-6, Schofield wrote:> > I have a managed directory defined in one class. I need the ability to > update a subset of files in the managed directory from a puppet define. I > would like to simply define a new file resource that is a directory and > have the files from this new resource simply overlay the existing managed > directory. Of course I get a duplication declaration error since the File > titles would be the same. Is there anyway to achieve this? > > I realize I could just update the source files but I need the flexibility > to install to select nodes. > >You are focusing far too narrowly on a particular implementation. It may not be possible to achieve specifically what you''re asking for, but there are several ways to reach the configuration objective that is your ultimate goal. One thing you might be able to do is subclass the class that manages your directory, and override the File resource appropriately. Another thing you might be able to do is split out management of the files that need to vary (with the help of File''s ''ignore'' parameter, for instance) into separate classes, and apply the correct one of those classes based on whatever logic applies. Alternatively, perhaps you could template those files such that all nodes could use the same templates, and you wouldn''t need conditional or special-case behavior in your manifests. There are other alternatives, too, but those are the most promising I have come up with. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/IIcR-aP7c40J. 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.
John, thanks for the response. I added my comments inline. On Thursday, November 29, 2012 9:18:18 AM UTC-5, jcbollinger wrote:> > > > On Wednesday, November 28, 2012 6:15:24 PM UTC-6, Schofield wrote: >> >> I have a managed directory defined in one class. I need the ability to >> update a subset of files in the managed directory from a puppet define. I >> would like to simply define a new file resource that is a directory and >> have the files from this new resource simply overlay the existing managed >> directory. Of course I get a duplication declaration error since the File >> titles would be the same. Is there anyway to achieve this? >> >> I realize I could just update the source files but I need the flexibility >> to install to select nodes. >> >> > You are focusing far too narrowly on a particular implementation. It may > not be possible to achieve specifically what you''re asking for, but there > are several ways to reach the configuration objective that is your ultimate > goal. >Yep, exploring my options and learning:)> > One thing you might be able to do is subclass the class that manages your > directory, and override the File resource appropriately. >Looking at this now actually. the source and sourceselect attributes of File are probably what I want. However the source attribute is order dependent when determining which file gets applied. Would you know if the +> operator pre or post pends to an existing array? Is there a way to enforce the array ordering when appending? Haven''t found documentation on this so will be doing some trial and error.> > Another thing you might be able to do is split out management of the files > that need to vary (with the help of File''s ''ignore'' parameter, for > instance) into separate classes, and apply the correct one of those classes > based on whatever logic applies. >> Alternatively, perhaps you could template those files such that all nodes > could use the same templates, and you wouldn''t need conditional or > special-case behavior in your manifests. > > There are other alternatives, too, but those are the most promising I have > come up with. > > > John > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/zb4I05D40gMJ. 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 Thursday, November 29, 2012 10:18:48 AM UTC-6, Schofield wrote:> > Looking at this now actually. the source and sourceselect attributes of > File are probably what I want. However the source attribute is order > dependent when determining which file gets applied. Would you know if the > +> operator pre or post pends to an existing array? Is there a way to > enforce the array ordering when appending? Haven''t found documentation on > this so will be doing some trial and error. > >I do not know for sure whether +> prepends or appends, but my guess would be that it appends. Whichever way it does it, you can rely on Puppet to be consistent. As far as I know, there is no way to switch the order. Of course, the subclass can always replace the source array instead of appending. With judicious use of class variables, you could even do that without duplicating the source list anywhere. Alternatively, if your approach is going to be to fiddle with the ''source'' parameter then you might consider how to avoid subclassing at all. One way would be to load your source(s) via hiera. Another might leverage File''s behavior of skipping sources that don''t exist: for example, if one or more of your sources are declared in terms of the $hostname fact, then you can create hostname-based overrides entirely within your source data for only the nodes you want. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/T2jGulWMySUJ. 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 Thursday, November 29, 2012 5:17:43 PM UTC-5, jcbollinger wrote:> Alternatively, if your approach is going to be to fiddle with the ''source'' > parameter then you might consider how to avoid subclassing at all. >Agreed. This is what I am focusing on. But have hit a snag I don''t know how to resolve. My end goal is to have a patching mechanism for a JEE container that does not have an installer. Just a directory of files that gets copied to the node. I have verified that passing an array with source directories of the patches before the JEE container files works perfectly. I can add patches and roll them back easily. This all works great when I hard code the patch directories in an array before the jee container source directory. However I don''t know when a patch will be released and I need the flexibility to apply the patch to only certain nodes. This means the array set for the source has to be created dynamically. I am using a template to create the array from the patches passed in as parameters. class jee ($patches = []){ ... file {$install_dir: ensure => directory, source => split(template(''jee/source.erb''),'',''), sourceselect => ''all'' recurse => true, ... } } Everything in mind tells me this should work. However when I try to run the above code I get the following error. "Error: /Stage[main]/jee/File[/usr/local/jee]: Failed to generate additional resources using ''eval_generate: wrong header line format" I have seen the "wrong header line format" before and it is usually an incorrect quotation someplace. However in this case I am relying on the split function to transform the string returned from the template into an array. I am not sure where to begin debugging this. Any ideas?> One way would be to load your source(s) via hiera. Another might > leverage File''s behavior of skipping sources that don''t exist: for example, > if one or more of your sources are declared in terms of the $hostname fact, > then you can create hostname-based overrides entirely within your source > data for only the nodes you want >I''m not too keen on the $hostname solution. I feel that is what nodes are for so don''t want to obfuscate how files get applied by creating another means to do the same thing. Plus this would become a management nightmare given the use case I described earlier. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/DXMZm9PwzIoJ. 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.
Apparently a template adds return on the end of the return string. Guessing this is to support the template concatenation for file content. Switched to inline_template and all works well. Lesson learned. Appreciate your comments on this John. It''s nice to have second pair of eyes. On Thursday, November 29, 2012 7:34:08 PM UTC-5, Schofield wrote:> > > > On Thursday, November 29, 2012 5:17:43 PM UTC-5, jcbollinger wrote: > >> Alternatively, if your approach is going to be to fiddle with the >> ''source'' parameter then you might consider how to avoid subclassing at all. >> > > Agreed. This is what I am focusing on. But have hit a snag I don''t know > how to resolve. My end goal is to have a patching mechanism for a JEE > container that does not have an installer. Just a directory of files that > gets copied to the node. I have verified that passing an array with source > directories of the patches before the JEE container files works perfectly. > I can add patches and roll them back easily. This all works great when I > hard code the patch directories in an array before the jee container source > directory. However I don''t know when a patch will be released and I need > the flexibility to apply the patch to only certain nodes. This means the > array set for the source has to be created dynamically. I am using a > template to create the array from the patches passed in as parameters. > > class jee ($patches = []){ > ... > file {$install_dir: > ensure => directory, > source => split(template(''jee/source.erb''),'',''), > sourceselect => ''all'' > recurse => true, > ... > } > } > > Everything in mind tells me this should work. However when I try to run > the above code I get the following error. > "Error: /Stage[main]/jee/File[/usr/local/jee]: Failed to generate > additional resources using ''eval_generate: wrong header line format" > I have seen the "wrong header line format" before and it is usually an > incorrect quotation someplace. However in this case I am relying on the > split function to transform the string returned from the template into an > array. I am not sure where to begin debugging this. Any ideas? > > > >> One way would be to load your source(s) via hiera. Another might >> leverage File''s behavior of skipping sources that don''t exist: for example, >> if one or more of your sources are declared in terms of the $hostname fact, >> then you can create hostname-based overrides entirely within your source >> data for only the nodes you want >> > > I''m not too keen on the $hostname solution. I feel that is what nodes are > for so don''t want to obfuscate how files get applied by creating another > means to do the same thing. Plus this would become a management nightmare > given the use case I described earlier. > > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/8Fip-9fPFmYJ. 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.