No. I wanted to do targetting cleanup of a class that was previously present everywhere, but is now only present in a few places.

Like removing a Yumrepo that is broken in parts of the network.

Might be a case for a PuppetDB query to see if the last catalog compiled for given

$certname

had the class.

PuppetDB isn't an option right now for Reasons

Otherwise, the whether a class is declared or not is dependent on compile-time ordering and anything dependent on compile time ordering is basically "undefined behavior" 😉

Hmm... could you clarify your use case a bit more? "present everywhere" makes me think you're talking about a class being declared in the catalog of multiple nodes. A class can only be declared once per catalog, so "everywhere" is a confusing term in this case.

Hmm... could you clarify your use case a bit more? "present everywhere" makes me think you're talking about a class being declared in the catalog of multiple nodes. A class can only be declared once per catalog, so "everywhere" is a confusing term in this case.

A class had been included in a class that is used everywhere, but determined that it should not be, so was removed. However, it has left behind a Yumrepo that is broken in parts of the network, therefore breaking the Puppet:\Package:Yumrepo provider's update check.

A one-off cleanup is more of a job for

bolt

than

puppet

.

We don't really have a bolt installation right now. I guess I'll just do the laborous task of digging through reports to construct a node list and deploy a short-term resource for that.

This message was deleted.

Sounds like you want to do a targeted cleanup of that broken yumrepo. And I assume you can't just explicitly

ensure => absent

that yumrepo by name because..... why?

Sounds like you want to do a targeted cleanup of that broken yumrepo. And you can't just explicitly

ensure => absent

that yumrepo by name because..... why?

Because it's still validly installed for a certain number of nodes.

Got it. And what's responsible for that valid install of the yum repo? Is there some other class that is declaring the yum repo correctly?

i.e. how is the valid yumrepo being managed by Puppet?

i.e. how is the valid yumrepo being managed by Puppet?

It's validly calling the repo setup class in a more exclusive class.

I'd incorrectly called that repo setup class more broadly.

Is the name of the "bad" class (that declared the repo incorrectly) the same name as the "good" class? i.e. are they the same class?

Actually, I since I have to fix this in stages, I'll temporarily disable it in the correct location, broadly

absent

it, and then put it back.

Is the name of the "bad" class (that declared the repo incorrectly) the same name as the "good" class? i.e. are they the same class?

There isn't a bad class, exactly. It was put in too broad a location and there are network differences. That causes the repo itself to be bad for those nodes, which breaks the provider.

Got it. Thanks for clarifying. So, to Charlie's point, determining if a class has been declared (i.e. included) in a catalog is parse-order dependent, so it's nearly impossible to guarantee you won't get a false reading. For example, while this technically does work some times, it's not guaranteed to always work all the time because when in the catalog compilation process this is parsed matters:

# If the foo::repo class has been included, remove the foo repo.
# CAUTION: This is parse order dependent. Don't use it.
if defined(Class[foo::repo]) {
  yumrepo { 'foo':
    ensure => absent,
  }
}

ref: https://gist.github.com/natemccurdy/07e8f08f0b1811e8cbb8996bd08e5915?permalink_comment_id=3129252#gistcomment-3129252

This task is better suited to a one-time cleanup operation. Either do what you said and fix it in stages, or do some kind of report scraping to find a node list and explicitly remove the repo on those nodes.

Got it. Thanks for clarifying. So, to Charlie's point, determining if a class has been declared (i.e. included) in a catalog is parse-order dependent, so it's nearly impossible to guarantee you won't get a false reading. For example, while this technically does work some times, it's not guaranteed to always work all the time because when in the catalog compilation process this is parsed matters:

# If the foo::repo class has been included, remove the foo repo.
# CAUTION: This is parse order dependent. Don't use it.
if defined(Class[foo::repo]) {
  yumrepo { 'foo':
    ensure => absent,
  }
}

ref: https://gist.github.com/natemccurdy/07e8f08f0b1811e8cbb8996bd08e5915?permalink_comment_id=3129252#gistcomment-3129252

A colleague of mine came up with reasonable solution. Create new repos with identical definitions so that the old one can be broadly absented and the new one used in the original legit location.

Oh.. err, I guess you'd want to negate that

if

in my example.

unless defined(Class[foo::repo]) {

Ah, yeah, that'd work too. I like it.

Basically, anything other than using

defined()

is good and better than using

defined()

.