esx_advanced_options not persistant

[ggeldenhuis]

When using the esx_advanced_options type it does not appear to set values persistently. When running puppet apply with the following sudo code:

# hiera data 
pod::vcenter::esxi::esx_advanced_options:
  Config.HostAgent.plugins.solo.enableMob: false
  Security.AccountUnlockTime: 900
  Security.AccountLockFailures: 3
  UserVars.DcuiTimeOut: 600
  Security.PasswordQualityControl: "retry=3 min=disabled,disabled,disabled,7,7"
  UserVars.ESXiShellInteractiveTimeOut: 900
  UserVars.ESXiShellTimeOut: 900
  Mem.ShareForceSalting: 2
  DCUI.Access: root

# puppet code
        esx_advanced_options { $esxi_server_name:
          options   => $esx_advanced_options,
          require   => Vc_host[$esxi_server_name],
          transport => Transport['vcenter'],
        }

You get the following output on the command line:

Notice: /Stage[main]/Pod::Vcenter::Esxi/Esx_advanced_options[esx00002.pod0000x.sys00004.il2management.local]/options: options changed {'Config.HostAgent.plugins.solo.enableMob' => 'false', 'DCUI.Access' => 'root', 'Mem.ShareForceSalting' => '2', 'Security.AccountLockFailures' => '3', 'Security.AccountUnlockTime' => '900', 'Security.PasswordQualityControl' => 'retry=3 min=disabled,disabled,disabled,7,7', 'UserVars.DcuiTimeOut' => '600', 'UserVars.ESXiShellInteractiveTimeOut' => '900', 'UserVars.ESXiShellTimeOut' => '900'} to '{"Config.HostAgent.plugins.solo.enableMob"=>false, "Security.AccountUnlockTime"=>900, "Security.AccountLockFailures"=>3, "UserVars.DcuiTimeOut"=>600, "Security.PasswordQualityControl"=>"retry=3 min=disabled,disabled,disabled,7,7", "UserVars.ESXiShellInteractiveTimeOut"=>900, "UserVars.ESXiShellTimeOut"=>900, "Mem.ShareForceSalting"=>2, "DCUI.Access"=>"root"}'

If you run puppet apply immediately again, you will get the same output again. This seems to suggest that either the settings are not being applied persistently of the resource type/provider does not have a reliable way of determining and comparing the current settings.

[ggeldenhuis]

Issue is addressed in https://github.com/vmware/vmware-vcenter/issues/175 It would be useful to force the user to provide strings, if only for ensuring that you don't see apparent non-idempotent behaviour. If all values gets changed to string anyway why allow the user to enter integers.

[crayfishx]

@gjngeldenhuis more appropriate IMO is just to munge the value in the type so it doesn't matter to the user.... I've done that in #202

[ggeldenhuis]

@crayfishx lets get #202 merged then.