Feature Request: service tunables about puppet-cups HOT 7 CLOSED

As far as I understand, you want to employ inheritance in a way such that the subtype on purpose does NOT provide a kind of functionality defined in the supertype's contract. That would be bad design, as it violates the Liskov principle.

However, if you want to run up that technical debt, note that most parts of the module will still work when you omit loading the defined class cups and instead manage package installation and services manually.

from puppet-cups.

Let me add that, as explained in README.md,

• this module strongly relies on the ipptool command line utility, which is not included in CUPS 1.4.8, but can be downloaded from www.cups.org.
• it is vital that the file /etc/lpoptions is absent. This one of the tasks handled by the class cups.

You could also use this nifty workaround

service { 'cups':
  ensure => absent,
  enable => false,
}

class { 'cups':
  services => [], # Disable automatic service management
  require  => Service['cups'],
}

from puppet-cups.

Not loading the cups class leaves the service in an unmanaged state. My desire is to have a managed state of "disabled". I guess I view the contract as "This service is managed." The way in which it is managed specified far closer to the node in question.

from puppet-cups.

Does the "nifty workaround" above your last post help?

from puppet-cups.

The workaround above effectively requires me to maintain one module which enables cups and sets up my printers (thanks for v1.2.0 btw) and another which disables it. While it does provide a managed state, it also provides two possible places for the source of that managed state. That is more or less what I'm doing now, but that is the sort of thing I'm looking to get away from.

from puppet-cups.

The fundamental premise of this module is that you do want the CUPS daemon to be running and to manage queues. If that is not your intention, the module should not be including on that particular node. Everything you want to do on your kiosk nodes can be done in plain Puppet. Including this module on such a node can only get you in trouble.

I'm always happy to help and I'm committed to keeping the module fit and simple for all intended usage. Covering up for design flaws higher up in the stack usually conflicts with these goals.

from puppet-cups.

Keeping the module lean feels viable. I'll deploy another workaround.

from puppet-cups.