[Printing-architecture] CUPS: fail-over without load-balancing

[Michael Sweet]

Tim,

We've had a few requests for this functionality over the years.  The current bug tracking it is:

   http://www.cups.org/str.php?L1240

Right now the simplest thing to do is add a backend that implements the required functionality.  Longer term we'll address STR #1240 as a manual operation that (temporarily) redirects jobs queued on one queue to another.

More comments inline...

On Jul 16, 2014, at 6:32 AM, Tim Waugh <twaugh at redhat.com> wrote:
> Hello!
> 
> I'm investigating how to implement fail-over for CUPS, but without
> having load-balancing as a side effect.
> 
> The usual way of implementing fail-over is simply to use classes, so
> that printers are used round-robin fashion.
> 
> However, I'd like to implement fail-over as follows:
> 
> Each class will have one active printer accepting jobs, and a fail-over
> printer not accepting jobs. When all is well, only the active printer
> will be in use.
> 
> When the active printer fails, a daemon will spot this and start the
> fail-over printer accepting jobs.

This was basically the point of another feature request (STR #2878), however after we looked at implementing such a scheme it didn't seem workable - right now the class accepts the job and any printer in the class will process the job, regardless of the state of its "printer-is-accepting-jobs" attribute.  And if you use change the class code to honor "printer-is-accepting-jobs", or use "printer-state" instead, you'll basically need printers that are dedicated to a particular class since most of the time they will be disabled/not accepting jobs.

In the end we decided the only thing that made sense was to track a selected/primary printer for the class, and have the admin change this when needed.  And that is what STR #1240 is tracking, for any queue (even a class).

> ...
> Does this sound like the best approach? Is it something that would be
> best implemented as part of CUPS, or cups-filters, or a standalone
> project?

Long term this should be part of CUPS.  Short term it can be implemented as a backend.  I would hesitate to patch cupsd for this since you will introduce long-term support issues when we finally do add the functionality ourselves.  At least with a backend the migration path is clear and can be staged over many releases.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20140716/cfd5878e/attachment.p7s>