[Feature] Structured facts with printer capabilities about puppet-cups HOT 4 CLOSED

What about mountpoint information, networking data, LSM settings, the ruby version, ssh hostkey information, and what have you? These are all data which can be changed by a Puppet agent run and still they are included in the list of facts.

from puppet-cups.

A Puppet fact - by definition - is a property that cannot be changed by a puppet agent run. Architecture, OS, physical network interfaces - those are facts. CUPS queues and there properties are not.

Also, IMHO your use case lies way beyond the intend scope of Puppet (i.e. provisioning nodes) and should therefore be solved with software tailored to the use case.

from puppet-cups.

@wiene This module offered the names of printers or classes as Puppet facts in versions 1.x.x. That was a bad choice: If you really used those facts in one way or another in your manifests, you most certainly broke idempotence and had to run Puppet at least three times to get a Puppet run which did not apply changes. That's why the facts were removed for versions 2.x.x.

from puppet-cups.

you most certainly broke idempotence

I fully agree that idempotence is a high and worthy goal. But with Puppet, it is sadly impossible to have idempotence in many cases without giving up other fundamentals, such as using even core facts altogether.

For example, https://github.com/cvmfs/puppet-cvmfs and https://github.com/desalvo/puppet-frontier can use mount points for caches and those packages at the same time need information on how much storage they are allowed to use.
Idempotence breaks if the mount itself is managed by Puppet, since it's then only part of the facts starting from the second run.

Another example are modules which detect system hardware and store that in external facts, e.g. https://github.com/jhoblitt/puppet-megaraid or https://github.com/treydock/puppet-infiniband . I'd clearly see this as a system property., so the term fact seems correct here - but they require lspci which in turn is installed by a package resource managed by Puppet.
This can lead to a requirement for even more than two puppet runs if e.g. a filesystem mount requires Infiniband to be set up, and something else (e.g. a cache) depends on the total storage of that filesystem.

To cut a long story short: Idempotence is a high goal and we should strive for it whenever possible. But Puppet is designed in a way making that impossible for complex setups - unless you completely ignore facts and reimplement all that locally in each module's ruby code (yes, of course also lspci can be emulated in Ruby that way). But that's rather impractical.

That's why I asked for this feature. I know idempotence is broken whenever most facts are used, that's by design whenever there are two phases and one may influence the other - but there are cases when this is better (as long as converging state is guaranteed) than reimplementing things in each module or breaking module boundaries by e.g. checking in a network file system if Infiniband hardware exists.

I also believe that puppet-cups could gain from using facts. Right now, I see 2-4 calls to lpoptions for each queue, depending on how many options are configured. With 50 queues, the puppet run takes pretty long just from these multiple calls. Collecting this information once and storing it in a structured fact would remove those repeated calls to the external command.
But the decision is of course yours to take, that's just my 2 cents 😉.

from puppet-cups.