Hello Arno, Nice work. Your screen shots look really nice. It think this will be a popular feature. My comments are below:
On Thursday 06 July 2006 23:51, Arno Lehmann wrote: > Hi, > > as promised, but later than I wanted, I have some sort of a preview of > the Volume Location Management I'm implementing. > > Basic outline: > - Tag each volume with a Location. > - The Location assigned to a volume can be changed in a web interface. > - A volume can be (temporarily) disabled. This is intended for loading / > unloading operations, so you can have a catalog representing the actual > autochanger inventory and still swap volumes without Bacula stumbling. > - Bacula, as of version 1.40 (or the current development version) will > respect the Volume disabling AFAIK. > - Bacula does *not* respect Location tags, for example it will requests > volumes tagges as "off-site storage". The above is correct, but I would reword it a bit. Bacula simply does not interprete the location tags because the meaning of those tags is defined by the user and, as a consequence, Bacula has no idea what is off-site, damaged, with currier, in Europe, or any other such tag that you could define. As long as the volume is disabled or marked archived, Bacula will not use those volumes (not totally tested yet, but this is the plan ...). > - A very basic configuration page is implemented, but it's still lacking > lots of features. > - User authentication is implemented through LDAP, different roles can > be defined. Currently, the user setup itself can only be done manually. > - Locations can be defined in the web frontend, but needs work. > - Volume locations can be modified, and the Enabled/Disabled status can > be set. > - The appearance of the web front-end could be improved. > > Some screenshots are attached. > > Two questions regarding interaction with Bacula itself: > > I intended the volume disabling / enabling as a temporary setting for > use during changing the volumes in an autochanger. As such, I intended > to automatically enable volumes when changing locations, and would have > suggested to have the Bacula-internal 'update slots' command to > automatically enable the volumes it finds, too. So, whenever a volume > status is changed, it would be enabled. > > Does this sound right to you all, or should volume enabling / disabling > be done purely manually? No, not entirely. I don't think that Bacula should automatically enable a volume that it finds in the autochanger. This would mean that the user would have no way to disable the volume, then do other operations. However, I could easily imagine an option to "update slots" that says "enable=yes|no" that would automatically enable or disable all the Volumes found in the autochanger. This will permit the user to optionally mark all the Volumes in the magazine disabled prior to taking them offsite, and mark them all enabled when bringing them back on site. Coupled with the options to the slots keyword, you can apply the enable/disable to any or all volumes. > > Then, I implemented a logging function so each volumes life-cycle can be > tracked. This would be most useful if Bacula itself, when finding a > volume during 'update slots', logged this event, too. > > This would obviously require a new feature in Bacula, but I would > suggest to handle it by always writing the log entries to the > corresponding catalog table, but simply ignoring errors. Thus, if you > don't want the log, simply don't create the table. If the table exists, > the log will be written. > > Does this sound reasonable? Yes, but it is getting a bit late in the development cycle to add significant new features such as this. In what I show below, the new Log table would be required, and it would only be used if the user directs specific messages to it. This feature would be simply a new message destination (catalog) and one or more new message classes (such as INFO, FATAL, ERROR, ...) Also, it brings up the question about what logging means in your above paragraphs. If we are talking about the current messaging system, then we would probably need a new message class, or it could simply be INFO, then since we are talking about logging info to the database, why not allow the user to direct any message/messages with the current mechanism to the database. This means that the full Job Report as now produced could be written to the database -- something users have requested in the past. Since Job Reports are tied to a JobId, the log could easily be pruned when the File records are pruned for the job. To be more specific, here is the current list of message "classes": M_ABORT = 1, /* MUST abort immediately */ M_DEBUG, /* debug message */ M_FATAL, /* Fatal error, stopping job */ M_ERROR, /* Error, but recoverable */ M_WARNING, /* Warning message */ M_INFO, /* Informational message */ M_SAVED, /* Info on saved file */ M_NOTSAVED, /* Info on notsaved file */ M_SKIPPED, /* File skipped during backup by option setting * M_MOUNT, /* Mount requests */ M_ERROR_TERM, /* Error termination request (no dump) */ M_TERM, /* Terminating daemon normally */ M_RESTORED, /* ls -l of restored files */ M_SECURITY, /* security violation */ M_ALERT /* tape alert messages */ Note: the user specifies this in the conf file without the M_ I assume you would need a new class to indicate certain Volume state changes. Which ones? All state changes? Append, Full, ... How about Volume Enable changes (Enable, Disable, Archive), and finally, do we log Volume Location changes? The problem above is to define the new message class or classes (i.e. their name or names) and what specific message(s) goes into what class. Now the second change would be a new destination class. The current list of destinations are: Note, the user specifies this in the conf file without the MD_ MD_SYSLOG = 1, /* send msg to syslog */ MD_MAIL, /* email group of messages */ MD_FILE, /* write messages to a file */ MD_APPEND, /* append messages to a file */ MD_STDOUT, /* print messages */ MD_STDERR, /* print messages to stderr */ MD_DIRECTOR, /* send message to the Director */ MD_OPERATOR, /* email a single message to the operator */ MD_CONSOLE, /* send msg to UserAgent or console */ MD_MAIL_ON_ERROR, /* email messages if job errors */ I assume the new one would be something like MD_CATALOG. The new DB table might look like the following: CREATE TABLE Log ( LogId ... JobId ... LogText ... ); Best regards, Kern Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
