log_rotationdir is not recognized as a valid parameter

[rrod157]

I am using v2.0.15. When i added it in on wls_server command, it seem to fail with the following error:

Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: no parameter named 'log_rotationdir'

Apparently, I am fixing an issue introduced by this attribute since we upgraded orawls and now it is not recognizable. I checked that log_rotationdir.rb is defaulting it to blank (defaultto '') but it cannot accept custom value:

log_rotationdir => "/appl/spool/logs/${domain_name}/servers/AdminServer",

How this can be handled?

[biemond]

are you using a puppet master, if so it is a caching issue. please check the readme of orawls

[userMar2017]

Ed,

To provided more details, we were on 2.0.6 for months and our manifests worked just fine. Since 2.0.6 does not support 12.2.1.x, on your advise we upgraded to 2.0.15. After upgrading, we realized that it started throwing the error listed below

.. puppet-agent[XXXXX]:<admin_server>/log_rotationdir) log_rotationdir changed '/some_folder/somefile' to ''

We then proceeded to add option "log_rotationdir" to "wls_server" but it did not accept it and threw the following exception

...puppet-agent[XXXX]: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: no parameter named 'log_rotationdir' (file:...

[biemond]

yep follow the puppet master tips, it is a cache issue. puppet apply will work fine.

[userMar2017]

If you still think its related to caching, let us know if you want us to restart all the PE services on the puppet master. Problem is that we have a number of branches / environments ; do you think we will need to perform this on all the environments ? We did not encounter this issue in the branch we tested this on.

After adding or refreshing the easy_type or orawls modules you need to restart all the PE services on the puppet master (this will flush the PE cache) and always do a puppet agent run on the Puppet master

[biemond]

do some dummy puppet agent runs on puppet master so it detect the new modules, put it on the primary location. after that it will sync the agents with the new module versions

[userMar2017]

Thanks for the quick responses Ed. However, before I go to our Puppet team, I will need to justify to them why we need to perform these steps on the master.

1. Its odd that everything else works except that we run into this issue. If I do a "puppet agent -t", will it help confirm that this is a caching issue ?
2. If its a caching issue, are you asking us to run a "puppet agent -t" on the master next ?

[biemond]

somehow the puppet types changes are not detected , manifests are fine. just do some puppet agent run on the master with some user or group or maybe empty will already work.

[userMar2017]

So, I should ask them to run "puppet agent -t" on the master against this particular branch ?

Sorry, but I need to be very clear on what I am requesting. Puppet is new to all of us (even the Puppet team !).

[userMar2017]

Puppet enginner restarted pe-puppetserver but I encountered the same issue. Opened a ticket with Puppet.

[userMar2017]

Hi Ed,

Unfortunately, after a lot of back and forth, Puppet has asked us to engage you. Let us know their suggestion is doable. They are also suggesting that we "try" to promote the change to all environments and it "might" work but the full fix is to update to the module.

The resource type generation occurs on a code deployment, and we have done it manually in this ticket. The issue is that the module uses procs in their title patterns, so the resource types are not compatible with environment isolation. Below is an excerpt from the errors seen when generating types for this module.

Since the title pattern is not in a supported format for environment isolation, the resource type metadata is not generated. Unfortunately, this means that the resource type is susceptible to environment bleed, which is the issue that you are seeing. It may intermittently work depending on which version of the resource type is loaded first on each Jruby, but that behavior is unpredictable. This is likely why you may have seen a few agent runs successfully access it from the MoM, but this behavior will change on every restart and Jruby recycle. A workaround is to deploy the same version of the module to all environments that have it, which would negate the effects of environment bleed. The full fix for this issue is that the module developer will need to update the code to be compatible with environment isolation. Since we do not support the module, I suggest working with the module owner to have the title patterns updated to be compatible with environment isolation.

[userMar2017]

One other thing, is it possible to create a branch of orawls module that does not have "log_rotationdir" ? Recall that the only reason we are upgrading is to obtain support for OHS 12.2.1.x ; but after the upgrade, the module is breaking our existing weblogic, which is on 12.1.3.

[biemond]

I will not change anything because this is a puppet issue , did you restart the puppet master and did you do some puppet agent runs on the puppet master , that always works. put this module in production If puppet apply is working fine and puppet should fix this or give some error at least. plus title pattern should be dynamic because that is how it works on weblogic. multiple domain, jms modules etc.

[userMar2017]

We attempted it multiple times. Not only restarting Puppet but also deleting the resource types, generating types and numerous other suggestions provided by Puppet. In addition, I have personally cleared my Puppet agent cache a number of times. If you have any other suggestions, I can definitely attempt it Ed.

[biemond]

ok but do you have multiple versions of orawls on the same master

[userMar2017]

Yes, we do. We are testing the new orawls in our branch and few other branches. We cannot promote to qa and prod until we resolve this issue.

[userMar2017]

In all we have over 30 branches.

[biemond]

make a new master then or force puppet to fix this

[userMar2017]

I will pass on your feedback Ed. Thanks a lot for all of your support. Really appreciate it.

[bFekete]

@userMar2017 what version of Puppet are you using? I believe this was fixed in PE 2016.5 / Puppet 4.8.

[userMar2017]

We are on PE 2017.3 actually. Can you provide some documentation on this ? I will pass it on to Puppet.

[userMar2017]

Ed, with this update, is "log_rotationdir" a mandatory argument ? Do I need to add it to all the admin + managed servers ?

[userMar2017]

It appears to, I will modify accordingly.

[biemond]

no it is not required and it is default to '' you got some wlst exception where it tries to use '' as value else we need to remove this default from the type

[userMar2017]

If I dont modify it, it causes error " log_rotationdir changed 'actual_location' to '" This in turn causes modification to config.xml ; the actual change is "The non-dynamic attribute CustomIdentityKeyStorePassPhraseEncrypted on weblogic.management.configuration.ServerMBeanImpl(blah blah) has been changed. " This change caused a number of issues for us in production as we had a number of developers complain that their deployment task failed. We had to restart the entire domain on a large number of servers to correct this. I will be adding this attribute and attempting to upgrade orawls a second time later this week.

[biemond]

or remove this line https://github.com/biemond/biemond-orawls/blob/puppet4/lib/puppet/type/wls_server/log_rotationdir.rb#L6

[userMar2017]

Is there a new orawls module for this ? I hate to modify it manually on our servers.

[userMar2017]

I dont even have access to the Puppet master and the puppet admin is not too happy with me !

[biemond]

first check if this solves your issue

[userMar2017]

I cannot reproduce this error using puppet apply ; let me ask the puppet admin for this change

[userMar2017]

Yes, that did the trick. I had to get it modified on the puppet master and after that it worked. It threw the following message which suggests it implemented the change. The original error "log_rotationdir changed" is now gone !

desc 'The log rotation dir of the server'

• defaultto ''
• to_translate_to_resource do | raw_resource| raw_resource['log_rotationdir'] end