Great info but I think I might have found the issue. So we don't use r10k to deploy code we use a different tool. But what I found is on the puppet server (master) the httpfile.rb in /opt/puppetlabs/puppet/cache/lib/puppet/type is the older version. I didn't find any ./resource_types directory in our environment directories so not sure if we are using environment isolation or not. As part of Justin's suggestion to allow the DELETE option to be valid, I had to restart each of our 4 puppet servers so according to some of this conversation, that should have refreshed the cache right?
What else is odd is the domain where the quick_check parm is work seems to be getting refreshed somehow in /opt/puppetlabs/puppet/cache/lib/puppet subdirectories (just looking at time stamps). The deploy process works the same in that domain along with the domain where quick_check is not working. Since the /opt/puppetlabs/bin/puppet generate types --environment production --force operates by environment, could this possible break the environment as well? These are production boxes I need to run this on and want to make sure I don't break anything. Also using the environment parm will this then setup environment isolation and do i have to manually manage that each time code is deployed to that environment? On Tuesday, August 25, 2020 at 5:09:28 PM UTC-4 Justin Stoller wrote: > > why wouldn't puppet just do this automatically when a module changes? > > Some background. Puppet's type and provider system modifies the running > Puppet instance when they're _loaded_. This causes issues when you try to > load multiple conflicting versions of a type in different environments. To > work around this we have a kind of header file for your types that Puppet > can read w/o actually loading the type. This way Puppet Server can load > multiple versions of a type (as long as those different versions are in > different environments) and check that each environment uses the type > correctly for that version. > > The command Dirk gave you, loads those types safely in a separate process > and then serializes their parameter information into a format for Puppet to > later read that doesn't corrupt its global state. It places this > information in the ".resource_types" directory at the root of your > environment (like "/etc/puppetlabs/code/environments/production") > > Also, in order to speed up Puppet Server catalog compilation, we attempt > to cache information like type parameters. > > In PE, if you use our built in code management facilities, we generate > this type information on every commit (if needed), distribute it to your > compilers, and then evict the environment cache so that any new information > will be read. > > In FOSS, r10k has a config setting to generate this info when it deploys > an environment [1]. > > > Now, the error you're ultimately getting involves Puppet Server thinking > that you're using the httpfile class wrong. It looks like the "quick_check" > field was added in the latest version. So really the first question would > be, are you using the latest version in this environment? > > Assuming you're doing that you probably either have the environment cache > containing an older version of the module (which should be resolved by > restarting the server or evicting the environment cache) or an old > .resource_types in the root of your environment that should be removed and > regenerated like Dirk said. Possibly you could have an older version in a > different environment that's being loaded first, but I don't think that'd > cause a problem for uncached, new parameters on a type. > > HTH, > Justin > > 1. > https://github.com/puppetlabs/r10k/blob/master/doc/dynamic-environments/configuration.mkd#generate_types > > On Tue, Aug 25, 2020 at 9:42 AM [email protected] <[email protected]> > wrote: > >> So a followup to the original question. >> >> As a test we created a simple module on the node which is failing when >> puppet agent executes. Running puppet apply, the parameter quick_check is >> found and the module completes successfully. So why would puppet apply >> work and not puppet agent? >> >> Code: >> >> class testmod() >> >> { >> >> httpfile { "ansible-2.8.0a1.tar.gz": >> >> ensure => present, >> >> path => "/u01/testmod/ansible-2.8.0a1.tar.gz", >> >> source => " >> https://mynexus.domain.com/nexus/repository/ae-raw-ansible-group/ansible/ansible-2.8.0a1.tar.gz >> >> <https://nexus.aetna.com/nexus/repository/ae-raw-ansible-group/ansible/ansible-2.8.0a1.tar.gz> >> ", >> >> quick_check => true, >> >> # hash => 'hex form SHA2 hash OR an URL to the .sha file with that >> hash' >> >> } >> >> } >> >> >> >> Here is my run: >> [root@node testmod]# puppet apply --modulepath=/home/toor --test -e >> "include testmod" --verbose >> >> On Tuesday, August 25, 2020 at 12:38:05 PM UTC-4 [email protected] >> wrote: >> >>> Dirk, why wouldn't puppet just do this automatically when a module >>> changes? Is there a bug somewhere? >>> >>> On Tuesday, August 25, 2020 at 2:43:03 AM UTC-4 Dirk Heinrichs wrote: >>> >>>> Am Montag, den 24.08.2020, 11:06 -0700 schrieb [email protected]: >>>> >>>> Justin, I implemented the suggestion you made however after running the >>>> curl command against the 2 environments having the issue and receiving the >>>> 204 response, the puppet module is still getting the 500 error. Do you or >>>> anyone else have any other suggestions? Is it possible it's related to >>>> ruby and/or java? Frankly I'm stumped. >>>> >>>> >>>> Didn't see this earlier, sorry. >>>> >>>> The "no parameter named 'xxx'" error can usually be resolved by >>>> recreating the metadata for your Puppet environment(s). This can be done >>>> on >>>> the Puppet master using the following command (for the production >>>> environment): >>>> >>>> /opt/puppetlabs/bin/puppet generate types --environment production >>>> --force >>>> >>>> I've added this command to my environment update script after running >>>> into this problem myself a few months ago after updating some external >>>> modules from the forge. >>>> >>>> See https://puppet.com/docs/puppet/5.5/environment_isolation.html for >>>> the details. >>>> >>>> HTH... >>>> >>>> Dirk >>>> >>>> -- >>>> >>>> *Dirk Heinrichs* >>>> Senior Systems Engineer, Delivery Pipeline >>>> OpenText ™ Discovery | Recommind >>>> *Phone*: +49 2226 15966 18 <+49%202226%201596618> >>>> *Email*: [email protected] >>>> *Website*: www.recommind.de >>>> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach >>>> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu >>>> Ranganathan, Christian Waida, Registergericht Amtsgericht Bonn, >>>> Registernummer HRB 10646 >>>> This e-mail may contain confidential and/or privileged information. If >>>> you are not the intended recipient (or have received this e-mail in error) >>>> please notify the sender immediately and destroy this e-mail. Any >>>> unauthorized copying, disclosure or distribution of the material in this >>>> e-mail is strictly forbidden >>>> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte >>>> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail >>>> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und >>>> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte >>>> Weitergabe dieser Mail sind nicht gestattet. >>>> >>> -- >> > You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/80022945-ecdc-43ef-b857-ca2813c37919n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/puppet-users/80022945-ecdc-43ef-b857-ca2813c37919n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9cbe27fa-f4a9-476b-8f88-6490bd83435an%40googlegroups.com.
