On Sunday 05 July 2009 08:46:11 Mordechai T. Abzug wrote: > [top posting since that seems to be the preference.]
The posting method is what makes sense to you. I don't have any religion on that subject -- except that after about 4 or 5 posts with responses mixed in, it can get a bit complicated :-) > > There might well be some cases where it would be useful to have "poll" > jobs to kick off what are currently "admin" jovs. However, I'm not > sure that would work well given the current split between different > job types -- if it starts off as an admin job, will bacula like when > it is promoted to an incremental? No an Admin job cannot be promoted. However, it can start another job that either is already promoted, or can be promoted. Starting other jobs is already implemented, and I don't foresee the need for any new code there, but if it is necessary, we will implement it. What is clearly necessary is coming up with some good general way for an Admin job to test all the conditions we may want in the future -- not all need to be immediately implemented, but we need a design that permits doing so relatively easily. > > If you really want to take "poll" jobs to their extreme, I think you > would want a generic syntax where you declare different things you > want to have happen. This would work like "MaxDiffInterval", but more > generic -- perhaps just "MaxInterval". Each job doesn't need to be > scheduled, you would just specify the run frequency. You could > specify an overall poll frequency that kicks off an implicit poll job > that promotes itself to whatever is needed -- assuming bacula would be > OK with this. Yes, that is what I am thinking about, with the exception that I do not envision an Admin promoting itself, rather it would start the appropriate job. > But I think that would be a rather extensive and > ambitious change. The design may ultimately require extensive and ambitious changes, but we will need to figure out how to phase it it as each change needs to be made in a reasonably controlled way to prevent instability creeping into Bacula. > The concept I sent in before is much more specific, > and therefore achievable (already written!) Yes, but it "tacks" on functionality in a disruptive way that does not easily extend to other things that we want to do (poll for migration high water marks, poll for expired retention periods, ...). Best regards, Kern > > - Morty > > On Thu, Jul 02, 2009 at 12:26:39PM +0200, Kern Sibbald wrote: > > Hello Morty, > > > > This is just to let you know that I have received these patches. The > > MaxDiff problem *should* now be fixed in the SVN. It took me several > > tries :-(. > > > > Concerning the Poll, I like the concept, but I would like to think about > > this some more. What bothers me is that this is a very specific > > implementation. It seems to me that we should be able to do the same > > thing but perhaps a bit more general by making similar modifications to > > Admin jobs. My original idea (not yet fully implemented), was that an > > Admin job could be started, and it could then trigger any action. That > > is sort of possible by using RunScripts, but it is really not very > > eligant. > > > > I wonder if you have any ideas to take the concept of your code and to > > add it to Admin jobs in a way, that the next time we want to "poll" for > > something different, it would be easy to add so we can deal with any kind > > of poll request. I hope you see what I mean. > > > > Best regards, > > > > Kern > > > > On Wednesday 22 April 2009 10:12:30 Mordechai T. Abzug wrote: > > > On Wed, Apr 22, 2009 at 08:33:51AM +0200, Kern Sibbald wrote: > > > > I am sorry, but it is not clear what you are doing here, in > > > > particular why you are adding a maxincinterval and what a "POLL" job > > > > is. > > > > > > I was trying to improve handling for laptops and other devices that go > > > away for the night. > > > > > > MaxIncrInterval is intended to be the Incremental analog of > > > MaxDiffInterval. A "Poll" is a level that doesn't actually do > > > anything except check if MaxIncrInterval, MaxDiffInterval, or > > > MaxFullInterval have been exceeded, doing a promotion if necessary. > > > > > > The idea is that instead of just running a once-a-night backup that > > > might fail, one also runs a "poll" job every half hour or so, and sets > > > MaxIncrInterval to 1 day (or whatever.) If the nightly incremental > > > fails, when the laptop does show up the next day and the poll runs, > > > the poll is promoted to an Incremental. If the laptop was there and > > > got backed up, then the poll doesn't get promoted. > > > > > > While this is intended for laptops, I think it also has a use in 24x7 > > > server environments, where this is no ideal backup time and spreading > > > out the backup impact is good. In such an environment, one can set > > > MaxIncrInterval, MaxDiffInterval, and MaxFullInterval, and *just* run > > > polls, without explicitly scheduling incrementals, differentials, and > > > fulls. So if I specify MaxFullInterval of 1 week, and run a full > > > backup of serverA on Monday and serverB on Tuesday, bacula should > > > henceforth automatically separate serverA from serverB without me > > > having to explicitly specify this in the bacula config. > > > > > > > PS: All patches need to be submitted as attachments to avoid email > > > > wrapping. > > > > > > OK. Patches attached. > > > > > > - Morty ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
