On Tuesday 02 March 2010 17:38:02 Bob Hetzel wrote: > On 3/2/2010 11:28 AM, Kern Sibbald wrote: > > On Tuesday 02 March 2010 16:50:20 Brian Debelius wrote: > >> Hi, > >> > >> I have some mtx-changer changes I would like to propose for possible > >> inclusion. Would I post the diffs here or send them to Kern? > > > > You can always send them to me, but it is *much* to send them to the > > list. > > > > Please be aware that any changes to the mtx-changer script need to be > > made to mtx-changer.in, and if they are things that users will want to > > change, you need to configure them with an environment variable that is > > defined in mtx-changer.conf. That way, the only change a user needs to > > make is to mtx-changer.conf, which is a file that we do not modify during > > an upgrade. This makes configuring cleaner, and avoids users configuation > > changes from being overwritten during upgrades. > > > > I imagine you already know all this though :-) > > > > Best regards, > > > > Kern > > While we're on the subject of mtx-changer configs, I'm thinking it might be > helpful if the strings mtx-changer looks for when it queries the > autochanger for slot status (i.e. the "list" section and presumably the > "listall" section) were moved into the mtx-changer.conf file.
Yes, that is a good idea. If there are several variations that are quite common, I also don't see any problem having the conf file be able to select from a number of standard strings designed for particular autochangers. What is important is that it is easy for the user to configure mtx-changer.conf (i.e. simple conf and a reasonable documentation). Also, the strings should be kept in mtx-changer.in so that we don't need to modify mtx-changer.conf. If you add new variables, mtx-changer.in should check to see if they are set (i.e. defined in mtx-changer.conf) and if that is not the case, it would set them to a default value. The idea behind this is that we should not make existing installations break when we add new features or variables (if the user continues using an old mtx-changer.conf with a new mtx-changer, it should work as it previously did). > This would > make upgrading easier. In my case, the change I have to re-put back in > every time I upgrade allows me to use the I/O slots as regular slots. > > Somebody else just asked about how to use their I/O slots similarly on one > of the bacula lists so it appears I'm not alone. I do realize this is not > a high priority item but it would be a cool smallish change, imho. Sounds quite good to me, but it will require some thought to add the new features without breaking existing configurations. Best regards, Kern ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
