X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=bacula%2Fprojects;h=d1e71862a2429fa1b066a851a5e4cde2c61f85bd;hb=35d5bf1cecf5e01cb6668199a6e2ac839f89093e;hp=a0c71a60e9f6562ea792c1f8e529808dacfc1848;hpb=e7b964f08cadf9b7e6d7248cc7da802cbf97b406;p=bacula%2Fbacula diff --git a/bacula/projects b/bacula/projects index a0c71a60e9..d1e71862a2 100644 --- a/bacula/projects +++ b/bacula/projects @@ -1,10 +1,30 @@ Projects: Bacula Projects Roadmap - 05 April 2004 + 23 April 2005 + +The following major projects are scheduled for 1.37: +#3 Migration (Move, Copy, Archive Jobs) +#4 Embedded Python Scripting (implemented in all Daemons) +#5 Events that call a Python program (Implemented in all + daemons, but more cleanup work to be done). +#6 Select one from among Multiple Storage Devices for Job. + This is already implemented in 1.37. +#7 Single Job Writing to Multiple Storage Devices. This is + currently implemented with a Clone feature. +#- Full multiple drive Autochanger support (mostly implemented). +#- We will have built in support for communications + encryption (TLS) done by Landon Fuller. +# We will most likely have support for Unicode characters + (via UTF-8) on Win32 machines thanks to Thorsten Engle. + + +Below, you will find more information on those projects as +well of other projects planned at a future time. Item 1: Implement Base jobs. - + Status: Voted by users not to be implemented in 1.37 + What: A base job is sort of like a Full save except that you will want the FileSet to contain only files that are unlikely to change in the future (i.e. a snapshot of @@ -34,58 +54,23 @@ Item 1: Implement Base jobs. FD a list of files/attribs, and the FD must search the list and compare it for each file to be saved. +Item 2: Add Plug-ins to the FileSet Include statements. + Status: In progress in 1.37 using Python scripting. -Item 2: Job Data Spooling. -Implemented in 1.34 - - What: Make the Storage daemon use intermediate file storage to -buffer - the data to disk before writing it to the tape. - - Why: This would be a nice project and is the most requested - feature. Even though you may finish a client job - quicker by spooling to disk, you still have to - eventually get it onto tape. If intermediate disk - buffering allows us to improve write bandwidth to tape, - it may make sense. In addition, you can run multiple - simultaneous jobs all spool to disk, then the data can - be written one job at a time to the tape at full tape - speed. This keeps the tape running smoothly and - prevents blocks from different simultaneous jobs from - being intermixed on the tape, which is very inefficient - for restores. - - Notes: Need multiple spool directories. Should possibly be - able to spool by Job type, ... Possibly need high and - low spool data levels. - - -Item 3: GUI for interactive restore -Partially Implemented in 1.34 -Item 4: GUI for interactive backup - - What: The current interactive restore is implemented with a tty - interface. It would be much nicer to be able to "see" the - list of files backed up in typical GUI tree format. - The same mechanism could also be used for creating - ad-hoc backup FileSets (item 8). - - Why: Ease of use -- especially for the end user. - - Notes: Rather than implementing in Gtk, we probably should go - directly for a Browser implementation, even if doing so - meant the capability wouldn't be available until much - later. Not only is there the question of Windows - sites, most Solaris/HP/IRIX, etc, shops can't currently - run Gtk programs without installing lots of stuff - admins are very wary about. Most sysadmins will always - use the command line anyway, and the user who's doing - an interactive restore or backup of his own files will - in most cases be on a Windows machine running Exploder. + What: Allow users to specify wild-card and/or regular + expressions to be matched in both the Include and + Exclude directives in a FileSet. At the same time, + allow users to define plug-ins to be called (based on + regular expression/wild-card matching). + Why: This would give the users the ultimate ability to control + how files are backed up/restored. A user could write a + plug-in knows how to backup his Oracle database without + stopping/starting it, for example. -Item 5: Implement a Migration job type that will move the job +Item 3: Implement a Migration job type that will move the job data from one device to another. + Status: Partially coded in 1.37 -- much more to do. What: The ability to copy, move, or archive data that is on a device to another device is very important. @@ -107,12 +92,13 @@ Item 5: Implement a Migration job type that will move the job Lowwater mark -Item 6: Embedded Perl Scripting (precursor to 7). +Item 4: Embedded Python Scripting (precursor to 5). + Status: Implemented in 1.37 in all 3 daemons. - What: On a configuration parameter, embed the Perl language in + What: On a configuration parameter, embed the Python language in Bacula. - Why: The embedded Perl scripting can be called to implement + Why: The embedded Python scripting can be called to implement Events such as "Volume Name needed", "End of Tape", "Tape at x% of rated capacity", "Job started", "Job Ended", "Job error", ... @@ -120,10 +106,12 @@ Item 6: Embedded Perl Scripting (precursor to 7). Notes: This needs Events. -Item 7: Implement Events +Item 5: Implement Events that call the scripting language. + Status: Implemented in 1.37, but more events to complete and + more work to be done to cleanup the implementation. What: When a particular user defined Event occurs, call the - embedded Perl interpreter. + embedded Python interpreter. Why: This will provide the ultimate in user customization for Bacula. Almost anything imaginable can be done if Events @@ -133,17 +121,23 @@ Item 7: Implement Events the user defines or "registers" events. -Item 8: Multiple Storage Devices for a Single Job +Item 6: Multiple Storage Devices for a Single Job + Status: This is already implemented in 1.37 (at least the + initial selection of one from a number of storage + devices. - What: Allow any Job to use more than one Storage device. + What: Allow any Job to specify a number of storage devices, + from which one will be used. Why: With two devices, for example, the second device could have the next backup tape pre-mounted reducing operator intervention in the middle of the night. -Item 9: Backup a Single Job Simultaneously to Multiple Storage - Devices +Item 7: Backup a Single Job Simultaneously to Multiple Storage Devices + Status: This will probably not be done in 1.37. However, version + 1.37 has a job Cloning feature, which permits essentially + the same thing. What: Make two copies of the backup data at the same time. @@ -153,8 +147,10 @@ Item 9: Backup a Single Job Simultaneously to Multiple Storage each Device. -Item 10: Break the one-to-one Relationship between a Job and a + +Item 8: Break the one-to-one Relationship between a Job and a Specific Storage Device (or Devices if #10 is implemented). + Status: Mostly done in 1.37. What: Allow a Job to simply specify one or more MediaType, and the Storage daemon will select a device for it. In @@ -165,24 +161,11 @@ Item 10: Break the one-to-one Relationship between a Job and a drives and/or multiple drives of different types. -Item 11: Add Regular Expression Matching and Plug-ins to the - FileSet Include statements. - - What: Allow users to specify wild-card and/or regular - expressions to be matched in both the Include and - Exclude directives in a FileSet. At the same time, - allow users to define plug-ins to be called (based on - regular expression/wild-card matching). - - Why: This would give the users the ultimate ability to control - how files are backed up/restored. A user could write a - plug-in knows how to backup his Oracle database without - stopping/starting it, for example. - - -Item 12: Implement data encryption (as opposed to communications +Item 9: Implement data encryption (as opposed to communications encryption) - + Status: Abel Menos expressed interest in this, but he is busy + at work. + What: Currently the data that is stored on the Volume is not encrypted. For confidentiality, encryption of data at the File daemon level is essential. Note, communications @@ -197,28 +180,6 @@ Item 12: Implement data encryption (as opposed to communications http://csrc.nist.gov/CryptoToolkit/aes/ -Item 13: New daemon communication protocol. - - What: The current daemon to daemon protocol is basically an ASCII - printf() and sending the buffer. On the receiving end, the - buffer is sscanf()ed to unpack it. The new scheme would - retain the current ASCII sending, but would add an - argc, argv like table driven scanner to replace sscanf. - - Why: Named fields will permit error checking to ensure that - what is sent is what the receiver really wants. The - fields can be in any order and additional fields can be - ignored allowing better upward compatibility. Much - better checking of the types and values passed can be - done. - - Notes: These are internal improvements in the interest of the - long-term stability and evolution of the program. On - the one hand, the sooner they're done, the less code we - have to rip up when the time comes to install them. On - the other hand, they don't bring an immediately - perceptible benefit to potential users. - Completed items from last year's list: Item 1: Multiple simultaneous Jobs. (done) @@ -226,5 +187,12 @@ Item 3: Write the bscan program -- also write a bcopy program (done). Item 5: Implement Label templates (done). Item 6: Write a regression script (done) Item 9: Add SSL to daemon communications (For now, implement with -stunnel) + stunnel) Item 10: Define definitive tape format (done) +Item 3: GUI for interactive restore. Partially Implemented in 1.34 + Note, there is now a complete Webmin plugin, a partial + GNOME console, and an excellent wx-console GUI. +Item 4: GUI for interactive backup +Item 2: Job Data Spooling. + Done: Regular expression matching. +Item 10: New daemon communication protocol (this has been dropped).