Hi Everybody,
We''ve several use cases where we''d like to define stdin as an
exec param. My searches didn''t reveal anything relevant, but I did
dredge up a 3-year old, unimplemented ticket concerning this matter:
https://projects.puppetlabs.com/issues/653
Here is a mock-up of a Puppet passage that conveys our real-world need, where
Maven''s settings.xml is patched with Sonar JDBC information:
exec { "patch -Nu /opt/apache-maven-2.2.1/conf/settings.xml":
stdin => template(''maven/sonar.patch.erb''),
require => Package[patch],
}
Notice the concision. My current approach is to write templatized patch files to
local disc and them reference them in separate ''exec''s, which
even at present may be a sub-optimal solution. Ultimately, the fewer turds
scribbled on the file system, the better ..
Any ideas?
* I wonder if an out-of-the-box Puppet ''patch'' feature is
prudent ..
--
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, while I can see the practical use, it seems to me that such approaches contradict the general puppet paradigm of "specifying what things should be" by "specifying how to do things". As such, I''m not sure such functionality is in fact prudent (both patch support and exec/stdin support). Regards, Felix On 02/22/2011 05:07 AM, Ty C wrote:> Hi Everybody, > > We''ve several use cases where we''d like to define stdin as an exec param. My searches didn''t reveal anything relevant, but I did dredge up a 3-year old, unimplemented ticket concerning this matter: > > https://projects.puppetlabs.com/issues/653 > > Here is a mock-up of a Puppet passage that conveys our real-world need, where Maven''s settings.xml is patched with Sonar JDBC information: > > exec { "patch -Nu /opt/apache-maven-2.2.1/conf/settings.xml": > stdin => template(''maven/sonar.patch.erb''), > require => Package[patch], > } > > Notice the concision. My current approach is to write templatized patch files to local disc and them reference them in separate ''exec''s, which even at present may be a sub-optimal solution. Ultimately, the fewer turds scribbled on the file system, the better .. > > Any ideas? > > * I wonder if an out-of-the-box Puppet ''patch'' feature is prudent .. >-- 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 Mon, Feb 21, 2011 at 20:07, Ty C <ty_c@cybozu.co.jp> wrote:> We''ve several use cases where we''d like to define stdin as an exec param. My searches didn''t reveal anything relevant, but I did dredge up a 3-year old, unimplemented ticket concerning this matter: > https://projects.puppetlabs.com/issues/653 > > Here is a mock-up of a Puppet passage that conveys our real-world need, where Maven''s settings.xml is patched with Sonar JDBC information: > > exec { "patch -Nu /opt/apache-maven-2.2.1/conf/settings.xml": > stdin => template(''maven/sonar.patch.erb''), > require => Package[patch], > }You could reasonable easily wrap a define around that which installed the patch on disk in, say, /var/tmp, then applied it from a local file, as a work-around and all.> Notice the concision. My current approach is to write templatized patch files to local disc and them reference them in separate ''exec''s, which even at present may be a sub-optimal solution. Ultimately, the fewer turds scribbled on the file system, the better .. > > Any ideas? > > * I wonder if an out-of-the-box Puppet ''patch'' feature is prudent ..Well, writing a "patch" type wouldn''t be all that difficult to do. http://docs.puppetlabs.com/guides/custom_types.html If you do, let us know, or publish it via the forge. That would allow you to work through the issues around it and all. Depending, we might look to ship it with core, or to keep it over on the forge as a separate project. If you need help, puppet-dev@googlegroups.com loves to hear about things like this, and we are happy to help keep you moving in the right sort of direction to get it all implemented and all. Oh, and you can use the plugin distribution features to make it easy to have this deployed across all your systems without needing to do too much on each client. Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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.