So I can''t quite see how to do this in the existing syntax.
Ideally there would be an onlyif parameter for packages, but that
doesn''t
seem to be the case.
I could create a fact that returns true or false depending on whether the
file exists, but that doesn''t feel like the right way to do it either.
I could do something like:
$file_exists = file("/path/to/file", "/dev/null")
but we''re talking about a rather large binary file, so this
doesn''t seem
ideal either.
--
Nigel Kersten
Systems Administrator
MacOps
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
On Jan 10, 2008, at 11:18 AM, Nigel Kersten wrote:> So I can''t quite see how to do this in the existing syntax. > > Ideally there would be an onlyif parameter for packages, but that > doesn''t seem to be the case. > > I could create a fact that returns true or false depending on > whether the file exists, but that doesn''t feel like the right way to > do it either. > > I could do something like: > > $file_exists = file("/path/to/file", "/dev/null") > > but we''re talking about a rather large binary file, so this doesn''t > seem ideal either.The only way to do this right now is with facts, which isn''t very generic. The onlyif/unless parameters should be made metaparameters, so they work everywhere, but then the transactional system needs to be updated to support this. -- Risk! Risk anything! Care no more for the opinions of others, for those voices. Do the hardest thing on earth for you. Act for yourself. Face the truth. -- Katherine Mansfield --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jan 10, 2008 12:18 PM, Nigel Kersten <nigelk@google.com> wrote:> I could create a fact that returns true or false depending on whether the > file exists, but that doesn''t feel like the right way to do it either. > > but we''re talking about a rather large binary file, so this doesn''t seem > ideal either.How is the file created? Wouldn''t this work? file { "/path/to/file": ensure => present, replace => false, } package { "some package": require => File["/path/to/file"], } Or do you need to copy the file over for the package to make use of when it is installed?
On Jan 10, 2008 5:38 PM, Joshua Timberman <joshua.timberman@gmail.com> wrote:> On Jan 10, 2008 12:18 PM, Nigel Kersten <nigelk@google.com> wrote: > > I could create a fact that returns true or false depending on whether > the > > file exists, but that doesn''t feel like the right way to do it either. > > > > but we''re talking about a rather large binary file, so this doesn''t seem > > ideal either. > > How is the file created? Wouldn''t this work? > > file { "/path/to/file": > ensure => present, > replace => false, > } > package { "some package": > require => File["/path/to/file"], > }This kind of works, but seems to be the wrong approach.... file { "/does/not/exist": ensure => present, replace => false, } exec {"/bin/echo yo": require => File["/does/not/exist"], } # puppet test.pp err: //File[/does/not/exist]/ensure: change from absent to present failed: Could not set present on ensure: No such file or directory - /does/not/exist at test.pp:4 notice: //Exec[/bin/echo yo]: Dependency file[/does/not/exist] has 1 failures warning: //Exec[/bin/echo yo]: Skipping because of failed dependencies I realize it achieves what I''m asking for, but (and I might be being absurd here) the spurious warnings make this pretty undesirable. I''m using puppet almost solely for client management, and so I have a small army of front line support people who will end up sending me these error logs over and over again trying to be helpful :) -- Nigel Kersten Systems Administrator MacOps _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jan 10, 2008 4:58 PM, Luke Kanies <luke@madstop.com> wrote:> On Jan 10, 2008, at 11:18 AM, Nigel Kersten wrote: > > > So I can''t quite see how to do this in the existing syntax. > > > > Ideally there would be an onlyif parameter for packages, but that > > doesn''t seem to be the case. > > > > I could create a fact that returns true or false depending on > > whether the file exists, but that doesn''t feel like the right way to > > do it either. > > > > I could do something like: > > > > $file_exists = file("/path/to/file", "/dev/null") > > > > but we''re talking about a rather large binary file, so this doesn''t > > seem ideal either. > > > The only way to do this right now is with facts, which isn''t very > generic. > > The onlyif/unless parameters should be made metaparameters, so they > work everywhere, but then the transactional system needs to be updated > to support this.Yep, this is exactly my thought, and I was hoping this could be a good starting point for some patches, but I''m getting the impression from your mail this is a rather major undertaking? -- Nigel Kersten Systems Administrator MacOps _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jan 10, 2008, at 8:03 PM, Nigel Kersten wrote:> On Jan 10, 2008 4:58 PM, Luke Kanies <luke@madstop.com> wrote: > > > The only way to do this right now is with facts, which isn''t very > generic. > > The onlyif/unless parameters should be made metaparameters, so they > work everywhere, but then the transactional system needs to be updated > to support this. > > Yep, this is exactly my thought, and I was hoping this could be a > good starting point for some patches, but I''m getting the impression > from your mail this is a rather major undertaking?I wouldn''t say it''s a major undertaking, but it''s also not trivial. The ''exec'' type has a special kind of parameter called a ''check'', which essentially just returns true or false. If all checks return true, then the exec runs. The way that ''checks'' are supported is pretty simple, but would probably need to be modified a bit to work generically; I''d make them an attribute of the attribute class. Then you just move the checks to a different file, s/newcheck(/ newmetaparam(:check => true/g, and move the ''check'' method from ''exec'' to the base class. Once the types support these metachecks, you go to where schedules are checked in the transaction, and add another test. Right now we make sure that the resource matches tags and is scheduled, and you just need to make sure they also pass all checks. All in all, it''s not really that much work, and I''d like to see a patch with this. -- The trouble with the rat race is that even if you win, you''re still a rat. -- Lily Tomlin --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies schrieb:> Once the types support these metachecks, you go to where schedules are > checked in the transaction, and add another test. Right now we make > sure that the resource matches tags and is scheduled, and you just > need to make sure they also pass all checks. > > All in all, it''s not really that much work, and I''d like to see a > patch with this.Would things like provider-availability-checking also fit in this category (which would enable deferred provider confinement)? Regards DavidS
I have to say, it''s not exactly pretty, but writing facts for this
kind of thing is simple enough.
I do something similar for some steps that have to happen after some
software is installed that''s only installable via methods puppet has
no control over.
Here''s my fact:
require ''facter''
if FileTest.exists?("/opt/openv/netbackup/bin/bpcd")
Facter.add("ssu_netbackup") { setcode { "installed" } }
end
Then the manifest has "if $ssu_netbackup { }" wrapped around the steps
that need to happen after that software is installed.
Not exactly pretty, and definitely not something that scales up well,
but it works and it''s easy enough...
On Jan 11, 2008, at 6:14 AM, David Schmitt wrote:> Luke Kanies schrieb: >> Once the types support these metachecks, you go to where schedules >> are >> checked in the transaction, and add another test. Right now we make >> sure that the resource matches tags and is scheduled, and you just >> need to make sure they also pass all checks. >> >> All in all, it''s not really that much work, and I''d like to see a >> patch with this. > > > Would things like provider-availability-checking also fit in this > category (which would enable deferred provider confinement)?I don''t think so. Really, deferred provider suitability testing wouldn''t be that hard -- in the simplest cases, just delay the validation until evaluate() is called on the resource. That won''t be perfect, though, because the default provider is chosen from the list of suitable providers, so you''d always have to specify the provider if it''s not going to be valid without some work. I guess I should actually get this done, I''ve just been kinda lazy on this. -- Work is not always required. There is such a thing as sacred idleness. -- George MacDonald --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jan 11, 2008 11:29 AM, Eric Eisenhart <eric.eisenhart@sonoma.edu> wrote:> I have to say, it''s not exactly pretty, but writing facts for this > kind of thing is simple enough.Sure, and that''s close to how I ended up doing this, but it doesn''t scale up well, and in this case in particular it was something we only need to run for a week or so... and it''s a bit annoying having to clear up a fact as well as a class.pp file when removing it. Thanks for the response though, much appreciated. -- Nigel Kersten Systems Administrator MacOps _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Nigel Kersten schrieb:> > > On Jan 11, 2008 11:29 AM, Eric Eisenhart <eric.eisenhart@sonoma.edu > <mailto:eric.eisenhart@sonoma.edu>> wrote: > > I have to say, it''s not exactly pretty, but writing facts for this > kind of thing is simple enough. > > > Sure, and that''s close to how I ended up doing this, but it doesn''t > scale up well, and in this case in particular it was something we only > need to run for a week or so... and it''s a bit annoying having to clear > up a fact as well as a class.pp file when removing it.distributing via pluginsync would at least fix one of those problems: If the module is not around anymore, all plugins are purged automatically. Regards, DavidS