Hi all,
Is there a (simple) way to add conditionals to a call to a define?
What I want is to run a define only if a file (that gets created
somewhere along the run of the define) does not exist. In this way I
can skip a whole lot of setup work in the define if I know it has
already run once before. I would think adding a unless clause would be
a elegant solution (and the other conditionals like onlyif that exist
elsewhere too).
So that I can call my defines with something like this:
installesite { "testaa":
require => [ perlinstall[ "everything" ], exec[
"fix-everything-sqldefs" ] ],
unless => "test -e /var/www/testaa/index.pl",
}
I don''t know if this would be easy to add to the puppet language, or
if it can easily be emulated with code in the define itself? I''m
drawing a bit of a blank on the last option at the moment... ;)
Thanks for any comments,
Thijs
On Jan 16, 2007, at 1:38 AM, Thijs Oppermann wrote:> Hi all, > > Is there a (simple) way to add conditionals to a call to a define? > What I want is to run a define only if a file (that gets created > somewhere along the run of the define) does not exist. In this way I > can skip a whole lot of setup work in the define if I know it has > already run once before. I would think adding a unless clause would be > a elegant solution (and the other conditionals like onlyif that exist > elsewhere too). > > So that I can call my defines with something like this: > > installesite { "testaa": > require => [ perlinstall[ "everything" ], exec[ > "fix-everything-sqldefs" ] ], > unless => "test -e /var/www/testaa/index.pl", > } > > I don''t know if this would be easy to add to the puppet language, or > if it can easily be emulated with code in the define itself? I''m > drawing a bit of a blank on the last option at the moment... ;)At this point, there''s no real way to do this right now. You could kind of hack this right now, by having your definition have an exec at the beginning that will fail if the file exists, thus skipping the entire definition (because resources will be skipped if they have failed dependencies). This will result in a lot of erroneous warnings, though. It seems that Puppet needs some kind of way to skip configuration branches, other than by throwing failures. I''ll think about it, but for now, you can''t do this, unfortunately. -- I take my children everywhere, but they always find their way back home. --Robert Orben --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 16/01/07, Luke Kanies <luke@madstop.com> wrote:> > On Jan 16, 2007, at 10:17 AM, Thijs Oppermann wrote: > > > OK, too bad. I could work around it of course by adding ''unless'' > > and ''creates'' clauses on all the individual parts of the define > > where appropriate, but I think I''ll just ignore the warnings and > > overhead for now. > > Okay. I''m always looking for specific recommendations on how to > better do this. I agree it should be better, but I don''t know > exactly how it should work. > > > It would be cool, though, if something like the ''unless'', ''onlyif'', > > etc, logic was available for all resources (or at least, those > > where they make some sense) as well as defines. > > Yeah, I''ve often thought the same thing. I''m a bit afraid of some of > the repercussions, though, because it could tend to make > configurations a lot more prone to instability and a lot less > computable. E.g., the same configuration could behave completely > differently on machines that are almost but not quite the same, which > is a bit frightening. It''s fine to use them with execs because you > have to have something like these parameters to make execs > idempotent, but the rest of the resources are naturally idempotent, > so these extra parameters would only be used for efficiency, which > probably isn''t worth it, or for making widely diverging > configurations, which is probably a very bad idea.Yeah, ok. Although I''m not sure this would fall under the heading of a very bad idea. Puppet, in my view, is also a tool to ease the maintenance of multiple systems. If you can cover a few different situations with just the one ''script'' by adding some simple tests to see if something should apply of not, I think that could be a good thing. In my specific case I have a define that does a whole bunch of stuff to arrive at ''one'' goal: a working, fully operational, blank CMS running on my server. It would be nice if I could approach that define as a single entity in my manifests, in the way that the *whole* define gets run if it has never been applied before, or skipped if it has. Adding support for a ''creates'' clause to defines would even be enough (instead of ''unless'', ''onlyif'', etc.) for that. But then again, I haven''t yet had the time to delve into the inner workings of ruby, let alone puppet, so I have no idea how easy or hard this would be to implement.. ;)> By the way... I''m not seeing the answer to this just now on the > > site: to update puppet to the next version just install the new > > version over the old one? That''s how I''m doing it now, but I don''t > > know if that will result in stale files being left behind? > > I''d say that''s a packaging question, not a Puppet question per se. > If you''re using Puppet''s installation script, then you *should* be > okay just installing over it, but it''s far better to use native > packages if they''re available.Yeah, but they always lag behind the current releases, which is why I prefer to just grab the tgz off the site and manually install those. Although, I guess once I have more machines running this could become troublesome... ;) --> It is well to remember that the entire universe, with one trifling > exception, is composed of others. --John Andrew Holmes > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >Thijs _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Tue, 2007-01-16 at 00:39 +0100, Thijs Oppermann wrote:> In my specific case I have a define that does a whole bunch of stuff > to arrive at ''one'' goal: a working, fully operational, blank CMS > running on my server. It would be nice if I could approach that define > as a single entity in my manifests, in the way that the *whole* define > gets run if it has never been applied before, or skipped if it has. > Adding support for a ''creates'' clause to defines would even be enough > (instead of ''unless'', ''onlyif'', etc.) for that.I am a little sceptical about this change, since it requires that knowledge about the inner working of the define is encoded wherever the define is used, and not kept internal to the define. It also goes against the idea of describing what you want the system to be like, not how to get there with puppet. In general, trying to emulate exec is somewhat iffy, since exec itself goes against puppet''s basic philosophy, though it''s just plain needed in practice.> But then again, I haven''t yet had the time to delve into the inner > workings of ruby, let alone puppet, so I have no idea how easy or hard > this would be to implement.. ;)Have you tried adding a custom fact for your CMS ? If you do that, your define can be enclosed in a big ''if ($cms_installed) { .. }'' which keeps everything about the define internal to it and doesn''t require the user of the define to know anything about how it does what it does. David
On 16/01/07, David Lutterkort <dlutter@redhat.com> wrote:> > On Tue, 2007-01-16 at 00:39 +0100, Thijs Oppermann wrote: > > > In my specific case I have a define that does a whole bunch of stuff > > to arrive at ''one'' goal: a working, fully operational, blank CMS > > running on my server. It would be nice if I could approach that define > > as a single entity in my manifests, in the way that the *whole* define > > gets run if it has never been applied before, or skipped if it has. > > Adding support for a ''creates'' clause to defines would even be enough > > (instead of ''unless'', ''onlyif'', etc.) for that. > > I am a little sceptical about this change, since it requires that > knowledge about the inner working of the define is encoded wherever the > define is used, and not kept internal to the define. It also goes > against the idea of describing what you want the system to be like, not > how to get there with puppet. In general, trying to emulate exec is > somewhat iffy, since exec itself goes against puppet''s basic philosophy, > though it''s just plain needed in practice.You are of course correct. The trouble I''m running into with this lies deeper and my need for these ''enhancements'' stems from the fact that I''m trying to solve my problems by using puppet as a scripting language. The problem is that some resources I need are not yet puppetised, for example CPAN package management and apache2-style enabling and disabling of sites. And although the CMS I want to use has a .deb available, it''s install scripts are a bit retarded in that some options aren''t available on the command line, forcing user interaction. So I end up doing a bunch of stuff with execs (quite a bit of which is ugly hacking of the CMS install scripts), and stringing them together by use of ''require'' and ''before'' clauses... So maybe I should approach this differently. I''m thinking that maybe as long as these resources are not puppetised I should create an install script in a real scripting language that does all this for me and then just use one exec to call it. Which I could then of course provide with an ''onlyif'' or ''unless'' clause''...> But then again, I haven''t yet had the time to delve into the inner > > workings of ruby, let alone puppet, so I have no idea how easy or hard > > this would be to implement.. ;) > > Have you tried adding a custom fact for your CMS ? If you do that, your > define can be enclosed in a big ''if ($cms_installed) { .. }'' which keeps > everything about the define internal to it and doesn''t require the user > of the define to know anything about how it does what it does.Ah, that route I had not thought about yet... That would probably be the quick hack in my current situation. But I think maybe the rewrite would be better long-term. Or better yet, learn how to do Ruby and add the needed resources.. ;) David> > > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >Thijs _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 15 January 2007 15:38, Thijs Oppermann wrote:> Is there a (simple) way to add conditionals to a call to a define? > What I want is to run a define only if a file (that gets created > somewhere along the run of the define) does not exist.You can create a facter fact to check for the file and decide on that. That''s not really ''simple'' (or scalable) but it''s not rocket science either ... Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFrKCr/Pp1N6Uzh0URArzWAKCF1c0+OjZexCLxTdkyDOnF8N7V1wCcD73/ d2hVaLdKtXTcfo5qEW51EeE=/ze0 -----END PGP SIGNATURE-----
On Tue, 2007-01-16 at 09:54 +0100, Thijs Oppermann wrote:> > So maybe I should approach this differently. I''m thinking that maybe > as long as these resources are not puppetised I should create an > install script in a real scripting language that does all this for me > and then just use one exec to call it. Which I could then of course > provide with an ''onlyif'' or ''unless'' clause''...That sounds like your best bet; and might actually be a lot simpler than doing it with puppet itself, since puppet is by design onot a general-purpose scripting language.> Ah, that route I had not thought about yet... That would probably be > the quick hack in my current situation. But I think maybe the rewrite > would be better long-term. Or better yet, learn how to do Ruby and add > the needed resources.. ;)If you do it not in Ruby, make sure to put a note on the Wiki - I am sure there are other people out there that think ''If I want to extend puppet, I need to learn Ruby'', though in a lot of situations you can get away with your favorite scripting language and exec. David
On Jan 17, 2007, at 9:48 AM, David Lutterkort wrote:> On Tue, 2007-01-16 at 09:54 +0100, Thijs Oppermann wrote: >> >> So maybe I should approach this differently. I''m thinking that maybe >> as long as these resources are not puppetised I should create an >> install script in a real scripting language that does all this for me >> and then just use one exec to call it. Which I could then of course >> provide with an ''onlyif'' or ''unless'' clause''... > > That sounds like your best bet; and might actually be a lot simpler > than > doing it with puppet itself, since puppet is by design onot a > general-purpose scripting language.I agree with this. I was talking to someone at LCA about this last night. You''d be better off creating a shell or Ruby controller for your program and just coupling that to Puppet, even if you can get "close" doing what you want in Puppet itself. -- Some people are afraid of heights. I''m afraid of widths. -- Stephen Wright --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com