Resources flap on dsc_ensure when set to Absent

[epsilon-jpage]

Describe the Bug

When trying to use the xWebSite class to remove the IIS Default Web Site from the xWebAdministration module it does not work as expected.

Expected Behavior

Default Application Pool should get removed.

Steps to Reproduce

In the Puppetfile I added ...
mod 'dsc-xwebadministration', '3.2.0-0-0'

In a test profile I wrote ...
dsc_xwebapppool { "DefaultAppPool":
dsc_ensure => "Absent",
dsc_name => "DefaultAppPool",
}

When DefaultAppPool is present in IIS all is good ...
Notice: /Stage[main]/Profile::Test_webserver_profile/Dsc_xwebapppool[DefaultAppPool]/dsc_ensure: dsc_ensure changed 'Present' to 'Absent'
Notice: dsc_xwebapppool[{:name=>"DefaultAppPool", :dsc_name=>"DefaultAppPool"}]: Updating: Finished in 0.943723 seconds

When DefaultAppPool is NOT present in IIS ...
Notice: /Stage[main]/Profile::Test_webserver_profile/Dsc_xwebapppool[DefaultAppPool]/ensure: defined 'ensure' as 'present' (corrective)
Notice: dsc_xwebapppool[{:name=>"DefaultAppPool", :dsc_name=>"DefaultAppPool"}]: Creating: Finished in 0.996919 seconds

... nothing is actually created but a corrective action action to "Present" for an "Absent" occurs on each run.

Environment

Windows Server 2019.
Puppet Enterprise 2019.8.1
dsc-xwebadministration 3.2.0-0-0

Additional Context

dsc_ensure expects "Absent" and will not work with "absent". I chose "ensure" as opposed to "dsc_ensure" in issues #51 and #52 because it actually reported correct messages.

[epsilon-jpage]

FYI, dsc_xwebsite has the same issue / behavior. I would open another bug issue but since they act the same it's likely the same root cause.

[michaeltlombardi]

This will need to be addressed either in canonicalization or type munging; there's a potential rework of the builder to merge ensure and dsc_ensure (among other improvements) which may resolve this, but I'll leave this issue open here for now.

Thanks for the thorough report!

[michaeltlombardi]

It occurs to me in the short run and in this specific case, you could test whether setting both ensure and dsc_ensure to absent resolves the flapping issue - this is still a bug but that may unblock you.

[epsilon-jpage]

If "DefaultAppPool" Application Pool exists ...
Error: Failed to apply catalog: Parameter ensure failed on Dsc_xwebapppool[DefaultAppPool]: dsc_xwebapppool.ensure expects a match for Enum['absent', 'present'], got 'Absent'

If "DefaultAppPool" Application Pool does NOT exist ...
No errors, puppet agent -t runs normally.

... does not work with dsc_xwebsite, will file separate issue.

[michaeltlombardi]

The error tells you explicitly that you specified Absent instead of absent for that parameter, Puppet is case sensitive.

Are you editing your manifests in VSCode? If so, the Puppet extension can tell you what enum values are valid when you hover on the property key (may need to ctrl+space to get the help to show, depending on your settings).

[epsilon-jpage]

If I had a nickel for everytime a Puppet person said use VSCode, I'd hire someone to do this.

[steviecoaster]

Because the Puppet extension is really good at catching these linting errors? They suggest it for good reasons. I'd likely want to listen to them really.

[epsilon-jpage]

Forcing someone to do code the way you want to do it doesn't promote an inclusive community. I write in Sublime. I am very happy using Sublime. If you write in VSCode then so be it and have fun, don't force me to write in an editor you want me to write on. I'm closing all my bug requests and going back to Chef.

[michaeltlombardi]

Sorry, I guess? I'm not sure what you want me to do with this comment:

If I had a nickel for everytime a Puppet person said use VSCode, I'd hire someone to do this.

The Puppet extension for VSCode likely would have been useful in preventing several of the classes of error you've made where you are not specifying the correct data type in your manifest or the wrong capitalization for an enum. I just suggested it to save you a bit of time and stress. I'm indifferent to the workflow you use, it doesn't affect me at all. The language server that powers the extension can be used in any editor which supports the LSP, I just know that the VSCode implementation is well looked after.

[michaeltlombardi]

FWIW I'm sorry to see you go and appreciate your bug reports to this point, @epsilon-jpage.

[michaeltlombardi]

Re-opening this issue as the bug report was valid and I don't want this to get lost.

[michaeltlombardi]

This issue is related to puppetlabs/Puppet.Dsc#74 and will likely require a move away from the Simple Provider and towards a fully custom provider.

[michaeltlombardi]

Tracking for this issue is better covered in puppetlabs/Puppet.Dsc#74 and #59, closing this in favor of those.