See the

dsc-networkingdsc

module at https://forge.puppet.com/dsc/networkingdsc?src=slack&channel=puppet

I may have asked this before- can't recall - Convert catalog - is there a way to evaluate where the time is spent? I dont think --evaltrace / summarize breaks it down.

ah, debug with timestamp led me to a problematic provider. evicted it... puppet-powershellmodule doesn't leverage ruby-pwsh/caching.

I'm completely baffled by something going on. I've got a catalog with 2 Alternatives (from puppet-alternatives 5.1.0). One of them isn't executing, but the items on either side of it in the dependency chain are. It causes the Exec which is downstream of it to fail because it needed to do it's thing first, but didn't.

See the

puppet-alternatives

module at https://forge.puppet.com/puppet/alternatives?src=slack&channel=puppet

Debug output shows the dependencies, but doesn't have it doing the execution.

I'd like a resource to be applied only if another resource is not changed (so an inversion of notify, so to speak). Code so far looks like this:

package { 'a':
  ensure => latest,
}
package { 'b':
  ensure  => latest,
  require => Package['a'],
}

The challenge behind is a software with a main installation package a and an update installation package b, the latter indeed requiring the former, and the installer quitting before having set everything in-place; so the logic I'd like to apply is "well give that thing the time between two agent runs before 'b' is applied". Has somebody done something similar before? :)

sounds like your package is broken?

does it start a service or similar?

Not broken, but bad vendor design. But the idea is good, a service could already be the answer. If so, I'll go ahead and require the software's service (it's a remote control agent software) to be running :)

couldn't you do some contains and require the whole class that resource lives in instead of the resource itself?

I've found that to get me over a hump like that in the past

I'm trying to wrap my head around that... I surmise that waiting for another resource implied by the package such as a service would be more reliable as its agent-run (and thus time) independent. But I'm curious nonetheless (and maybe testing shows I'll need that option). My brain right now translated this as: if package 'a' is successfully installed, there is a fact for that, and based on that very fact I could or could not contain the class managing package b. Right?

so, there's no fact, puppet creates a graph of dependency based on internal chaining as well as explicit chaining. you could make a fact via a ruby or external fact that returns the next run, so that you eventually become consistent

facts are collected before puppet applies manifest. so "installed" package fact will only available next run

for "difficult" packages like that God created

exec

resource 🙂

Also good (using custom facts through ruby, that is). I was just running in the wrong direction as it seems link run

goodnews 🧑‍🏫Puppet Core Team is about to start up in #CFD8Z9A4T

☕ 🧑‍🏫Puppet Forge is about to start up in #CFD8Z9A4T

@josh https://github.com/puppetlabs/puppet/pull/9505 this should finally turn green now

can environment.conf contain any agent variables? like hostname ?

no

really wish the autoloader had some flexibility around what to include/omit for nodes.

what do you mean?

really pluginsync, not autoloader. by default (and afaict exclusively) a lib dir in a module must go out to all agents.

yes it does

adding logic to it would result in so many edge cases

which problems do you have with it?

not everything is cheap or really belongs on all the things.

is it a problem that files are synced, or that they are executed?