Kern Sibbald wrote: > On Monday 28 December 2009 21:09:49 Phil Stracchino wrote: >> Kern Sibbald wrote: >>> On Monday 28 December 2009 19:57:24 Phil Stracchino wrote: >>>> Since I got no response from the users list: >>>> >>>> When starting a job from the console and modifying the job parameters, >>>> the 'modify Pool' operation overrides the 'Pool' directive in the job >>>> definition. >>>> >>>> >>>> It clearly SHOULD also override the 'Full Backup Pool', >>>> 'Differential Backup Pool' etc. directives. >>> I am not convinced that the manual pool override was ever supposed or >>> intended to override the other directives you mention. >> If that is the case, then one cannot override the Pool for a manually >> job whose definition specifies its level-specific backup pools. Since >> pool overrides in the schedule are now deprecated because of the >> problems they caused, it means that users must choose between being able >> to specify different Pools for different levels, or being able to >> override the pool when running jobs manually for the console. >> >> I have just performed a test job with the Full/Differential/Incremental >> Backup Pool directives in the JobDefs commented out, and it honored the >> console modifications and ran to tape exactly as it was supposed to. >> This seems to confirm the issue: 'modify Pool' on a console-run job >> overrides the Pool directive, but the level-specific Pool override >> directives override the Pool manually specified in the console. Thus, >> one cannot override the destination Pool for a manually-started job >> whose Job resource specifies per-level Pools. I would have to consider >> this a bug. > > This is not a bug. You are requesting a feature that has never been > implemented -- this was what I was implying in my previous email.
I disagree that this is a new feature. Let me explain why. Previously, when the default Pool was specified in the Job definition and any necessary Pool overrides for different backup levels were specified in the Schedule resource, one could set up pool overrides by level that would happen automatically, and still run manual jobs from the console to any desired pool. Which is to say, console modification or a manually-started job overrode the previously used Pool-override implementation. Now, Pool overrides in the Schedule resource have been deprecated, replaced by overrides in the Job definition. However, these *cannot* be overridden from the console in a manual job. Thus, replacing Pool overrides defined in the Schedule resource with Pool overrides defined in the Job resource has resulted in the loss of the ability to override the Pool for a manual job. Yes, *technically* one could say that the ability to override Job-resource Pool override directives is new functionality because Job-resource Pool overrides didn't exist before. From a functional viewpoint, though, a Pool override which can be manually overridden from the console has been replaced with one which cannot. The only way to manually run a Job to a non-default Pool now is to edit the Job resource, reload the Director's configuration, run the manual job, then restore the original configuration and reload the Director again. Since reloading a Director while jobs are running is hazardous at best, this may be impossible on a busy Director. Thus, previously existing important Console functionality (the ability to specify the destination Pool for a manual job that has level-specific Pool overrides) has, de facto, been lost as a result of the change from Pool overrides in the Schedule to Pool overrides in the job. This is not a case of adding new functionality that did not previously exist. It is a case of restoring functionality that has been lost as a side-effect of the change of the implementation of Pool overrides. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 [email protected] [email protected] [email protected] Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
