Allow Groups to be managed or not

[robh007]

In relation to issue #329 I've added a manage_group parameter. We ran into an issue were we couldn't upgrade to the later version of the module due to the refactor as mentioned in the issue. The reason for this was we added an additional user to the Administrators group during the puppet run. The WLS user configured to run WLST then didn't have any privilege to create any further WLS resources. So the puppet run just hangs. I've left the default to be true, Its probably an edge case that this scenario happens.

Hope this is ok, I had a slight issue with the commit so it maybe not to you're liking.

[biemond]

Thanks,

interesting, do you get a change on every puppet run.

[robh007]

With this change or in general when we run puppet on WLS servers? I've not investigated further, I'd heard we had a problem upgrading so I looked at the issue whilst upgrading a vagrant project I had to 12c.

[biemond]

because the index of wls_group sees a difference and wants the modify the group everytime it runs

[robh007]

I see, yes a little short sighted of me perhaps. I was trying to resolve the issue that we encountered, which is fatal. But as you say the group that puppet is managing will never have the original domain user inside unless it's specified in the hiera data. So each subsequent puppet run will trigger a change. Is there a way to perhaps always include the wls_weblogic_user within the Administrators group somehow? This scenario is probably slightly different from the original issue which was reported. I'd agree that if your managing users & groups with puppet they should exist in the data passed to the type.