Hello Phil, I can understand your point, but I still don't consider this a bug. The defiency has been there quite a long time (I have been wondering when someone would complain about it). I am not even sure how one might go about resolving the problem:
1. Make manually overriding the Pool when starting a Job take precedence over all other Pool specifications? I don't particularly like that idea. 2. Add several new commands that allow overriding all the different Job level pool directives? I don't much like that either. Anyway, until I find something I really like and time to implement it will remain their -- unless, of course, someone sends a reasonable patch. Best regards, Kern On Monday 28 December 2009 23:48:49 Phil Stracchino wrote: > 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. ------------------------------------------------------------------------------ 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
