Hello, 11.01.2010 11:47, Richard Hartmann wrote: > Hi all, > > we are deploying Bacula on more and more hosts and up to now, we like > what we see :) > > We added some functionality around Bacula in order customize it. Amongst > others, we created trigger for our monitoring solution that inform us of > any failed jobs.
I wonder why you needed additional Bacula functionality here - the messages resource (or a run after job script) is quite good for passing job status to, for example, Nagios. > Trying to keep relevant data as close to the original source as > possible, I am lacking a system to ACK failed jobs. I.e. I need a > mechanism to store the information that someone looked at a specific > backup job and decided that it's OK (or at least, that it is being > handled). > > To achieve this end, I can imagine several solutions: > > 1) Add a field timestamp field called 'ManualVerification' to the Job > table. If set to non-NULL, it means that someone verified the job > at this specific date. > > 2) Add a BOOL and a timestamp, analogous to the above (this less > implicit data storage might appeal to some people) > > 3) Add a table JobState with the fields > JobId (foreign key) > Type (ENUM; ACKJobFailure, ACKJobWarning, ...) > Name (text; of the person verifying, maybe a proper foreign key to a > new Table called User) > Timestamp (timestamp) > Comment (text) I really don't think that Bacula should have that functionality. First, ack'ing job problems is rather useless inside Bacula IMO - or do you want to mark failed jobs as ok afterwards? Instead, I think a system-wide monitoring solution (probably linked to a ticketing system) is the right place to track issues, fixes, notices of that kind. Not only are there such system available, but trying to keep monitoring and state acknowledgement as close to the source as possible sounds like you'll have to extend most of the software you use, too. I don't think that's an investment that will pay back. > > For future expandability, I would lean towards option 3, but I would > obviously prefer to do something that will be integrated and used in > mainline so I want to start a discussion about the relative merits of > these, and other, solutions. I doubt that your ideas will be integrated into Baculas core, unless you come up with very good reasons. In my opinion, your reasons outlined above, are not good enough - sorry. > > Also, and this is a very important question to me, does Bacula do any > kind of internal verification or make any assumptions which could be > broken by adding custom fields or tables? Yes and no... if you add tables, that should be no problem. It can become a problem later, if the catalog is extended, or if an update of the catalog schema needs to change your extensions, too. Creating tables in the catalog is, thus, surely an option. The question is if they are located there reasonably... you'd need to have some interface in Bacula to them to make that the proper choice, i.e. bcconsole, bweb and bat should be able to manage and present that data. And that will be much more work than merely extending the catalog. What I recommend to not do is, without consent from the core developers, modifying existing tables - that could break once the table layout is changed, and it could break Bacula itself. But, I'd still like to hear why you want to ack failed jobs in Bacula itself, and how you would integrate that into the user interfaces. Best regards, Arno > > > Thanks, > Richard > > ------------------------------------------------------------------------------ > 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 > -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück www.its-lehmann.de ------------------------------------------------------------------------------ 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
