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 pkraw...@gmail.com <pkraw...@gmail.com> 
> 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 pkraw...@gmail.com 
>> 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 pkraw...@gmail.com:
>>>>
>>>> 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*: dhei...@opentext.com
>>>> *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 puppet-users...@googlegroups.com.
>>
> 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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/9cbe27fa-f4a9-476b-8f88-6490bd83435an%40googlegroups.com.

Reply via email to