On Aug 27, 2006, at 9:55 AM, Thorsten Sandfuchs wrote:> hio, > me again :) > > In Debian, there is a mechanism to preseed debconf (configuration- > database for > the system) with decisions, before installing a package. Debconf > mussn''t ask > the user then. I wrote this pp for preseeding-support:[snip] Very cool. Seems like that''s something that should be supported within Puppet''s Apt support.> and it works like a charm. The algorithm fetches the files, I like > to preseed > from my server and fills the database, after a > > preseed { ldap-preseed: > file => "ldap", > classname => ldap > } > > Now I can install a "package" as desired. Buf if the package is > installed, the > preseeding never stopps... It preseeds the information on every > puppet-run... > > Is there a way to only trigger the "preseed" if the package is > upgraded/installed?Hmm; this is the first time I know of that someone has had to run a command *before* an object gets changed, but I can see how it might be necessary in more cases than this. At this point, there''s no way to do this, but I think it would be great to find a way. I think, for this problem, the right solution is to be able to specify a pre-seed file, or maybe just the information necessary for pre-seeding, but it seems like a general problem. -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199
On Sun, Aug 27, 2006 at 11:21:29AM -0700, Luke Kanies wrote:> On Aug 27, 2006, at 9:55 AM, Thorsten Sandfuchs wrote: > > me again :) > > > > In Debian, there is a mechanism to preseed debconf (configuration- > > database for > > the system) with decisions, before installing a package. Debconf > > mussn''t ask > > the user then. I wrote this pp for preseeding-support: > [snip] > > Very cool. Seems like that''s something that should be supported > within Puppet''s Apt support.Isn''t there a bug in the Trac for that already?> > Is there a way to only trigger the "preseed" if the package is > > upgraded/installed? > > Hmm; this is the first time I know of that someone has had to run a > command *before* an object gets changed, but I can see how it might > be necessary in more cases than this. At this point, there''s no way > to do this, but I think it would be great to find a way.For myself, I''ve never been really comfortable with the term ''subscribe'' for "tell me when this other object changes" -- although it describes the operation well enough once you know what you''re doing, it doesn''t seem at all obvious (and was one of my big mental hurdles when I was starting with Puppet). It seems to me like it would nice if you could specify pre/post actions, like so: package { ldap: before-change => preseed[ldap] after-change => exec[restart_ldap] } I think keeping the refreshonly semantics is nice, although I wonder if, in the wider context, ''refreshonly'' is the best term for it. Of course, having to go through and tag every package with it''s relevant preseed is a bit naff, so we''d obviously want to be able to specify the relationship from the other side: preseeed { ldap: runme-before-changing => package[ldap], refreshonly => true } exec { restart_ldap: runme-after-changing => package[ldap], refreshonly => true } Which would operate identically to the earlier form -- it''s only the location of the declaration that moves around. This symmetry of declaration is quite important, too. I''ve already had one instance where I''ve ended up declaring an "exec { restart_foo" object twice because I wanted to enhance a configuration only for a certain class, and I couldn''t subscribe the base exec object to the subclass'' reconfiguration object because that object isn''t available for everyone.> I think, for this problem, the right solution is to be able to > specify a pre-seed file, or maybe just the information necessary for > pre-seeding, but it seems like a general problem.The APT preseed issue is definitely best solved elsewhere (isn''t there already an answers file parameter for packages that could be used? -- not online, can''t check at the moment) but I think pre- and post- scheduling/triggering parameters would be *wonderful* for many purposes. - Matt
On Mon, Aug 28, 2006 at 01:37:09AM +0200, Thorsten Sandfuchs wrote:> On Mon, Aug 28, 2006 at 07:14:08AM +1000, Matthew Palmer wrote: > > On Sun, Aug 27, 2006 at 11:21:29AM -0700, Luke Kanies wrote: > > > On Aug 27, 2006, at 9:55 AM, Thorsten Sandfuchs wrote: > > I think keeping the refreshonly semantics is nice, although I wonder if, in > > the wider context, ''refreshonly'' is the best term for it. > > well if it basically just "restarts" why don''t name it "restartonly" or are > there other situation, I can''t think of right now, where there actually is a > "refresh"-action.The semantics of "refreshonly" aren''t limited to restarting services -- I use it for rebuilding hash tables from (eg) aliases and access maps in Postfix. - Matt
On Aug 27, 2006, at 4:37 PM, Thorsten Sandfuchs wrote:> well if it basically just "restarts" why don''t name it > "restartonly" or are > there other situation, I can''t think of right now, where there > actually is a > "refresh"-action.As Matt mentioned, this is used for more than just service restarts. It''s true that there are currently only two types that have any concept of "refresh" (service and exec), but I wouldn''t be surprised if we developed more of them over time. I''m personally not attached to any of these names; I do my best to name them initially, but I''m fine with other names. I do think the name should be more about reflecting the fact that it''s about event response, rather than the action taken, though.> yes "adminfile" - but it''s currently "only used on Solaris" - yet I > didn''t > read the source...Apt support could be modified to use this file. It''s available for other providers, it''s just that it''s only used by Solaris packages. -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199
On Aug 27, 2006, at 4:26 PM, Thorsten Sandfuchs wrote:> On Sun, Aug 27, 2006 at 11:21:29AM -0700, Luke Kanies wrote: >> Hmm; this is the first time I know of that someone has had to run a >> command *before* an object gets changed, but I can see how it might >> be necessary in more cases than this. At this point, there''s no way >> to do this, but I think it would be great to find a way. > > pre-subscribtion :)In thinking about this, it would be pretty weird, and made a bit weirder by relatively recent changes in the system. It''d be easy to schedule the pre-sub change before the object, but the change would have to check if it''s required object was insync, and use that information to determine if it should run. The transaction itself handles all of the event-handling, but I don''t think it could handle this one, which would be a nasty exception.> I especially don''t like the hack of generating that temp-file in > general and > especially on every run. Would be nice to somehow pipe a file to a > command.You''re right, but I unfortunately don''t have a better answer at the moment. -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199
On Aug 27, 2006, at 2:14 PM, Matthew Palmer wrote:> On Sun, Aug 27, 2006 at 11:21:29AM -0700, Luke Kanies wrote: >> Very cool. Seems like that''s something that should be supported >> within Puppet''s Apt support. > > Isn''t there a bug in the Trac for that already?Dunno. The darn bug list is so long right now...> For myself, I''ve never been really comfortable with the term > ''subscribe'' for > "tell me when this other object changes" -- although it describes the > operation well enough once you know what you''re doing, it doesn''t > seem at > all obvious (and was one of my big mental hurdles when I was > starting with > Puppet). It seems to me like it would nice if you could specify > pre/post > actions, like so:I agree that people don''t seem to easily get the "require" and "subscribe" stuff.> package { ldap: > before-change => preseed[ldap] > after-change => exec[restart_ldap] > } > > I think keeping the refreshonly semantics is nice, although I > wonder if, in > the wider context, ''refreshonly'' is the best term for it.I''ll be the first to admit that my terminology often, um, sucks. I can pretty much rule out any attribute names with "-" in them, since ruby doesn''t accept those in symbols. If we can come up with and agree upon better terms, I''m glad to change them.> Of course, having to go through and tag every package with it''s > relevant > preseed is a bit naff, so we''d obviously want to be able to specify > the > relationship from the other side: > > preseeed { ldap: > runme-before-changing => package[ldap], > refreshonly => true > } > > exec { restart_ldap: > runme-after-changing => package[ldap], > refreshonly => true > } > > Which would operate identically to the earlier form -- it''s only the > location of the declaration that moves around.Yeah, but as I mentioned in my previous mail, this would actually be very difficult internally. All event handling is currently done within the transaction, at the moment, and it''s done with historical tracking -- after we apply an object, we check to see if there are any events that that object is subscribed to, and if there are, we trigger those subscriptions (the subscription itself knows how to react). I guess we could create a weird kind of reverse trigger, where triggering the subscription resulted in the other side reacting. Hmm. I''ll try to look at the code to see how this would work. We *really* need to start doing a better job of maintaining a dev page with all of this work. I''d love to migrate most of the enhancement requests to a wiki page that could organize them a bit better, because it''s insanely depressing to see 100+ bugs open, even if most of them are enhancement requests. Most of the bugs are also currently too high-level to be actionable at this point (e.g., dynamic vs. lexical scoping).> This symmetry of declaration is quite important, too. I''ve already > had one > instance where I''ve ended up declaring an "exec { restart_foo" > object twice > because I wanted to enhance a configuration only for a certain > class, and I > couldn''t subscribe the base exec object to the subclass'' > reconfiguration > object because that object isn''t available for everyone.You shouldn''t need to redeclare, you should be able to selectively do the subscription only if the subclass exists or however that works.> The APT preseed issue is definitely best solved elsewhere (isn''t there > already an answers file parameter for packages that could be used? > -- not > online, can''t check at the moment) but I think pre- and post- > scheduling/triggering parameters would be *wonderful* for many > purposes.Yes, the adminfile or answers file parameters created for Solaris packaging should be reused here. -- Luke Kanies http://madstop.com | http://reductivelabs.com | 615-594-8199