vmware-archive / vmware-vcenter

VMware vCenter Module
Other
87 stars 102 forks source link

Name parameter in esx_system_resource. #205

Open crayfishx opened 8 years ago

crayfishx commented 8 years ago

@maniacmurphy longer-term, I think we should discuss how we should model what is currently esx_system_resource.

In the code, we have the name attribute as the namevar, but by design it doesnt actually do anything...

  newparam(:name) do
    desc "A unique name that will allow for setting the same resource on multiple hosts 
or multiple resources on the same host through multiple resource calls within your
 puppet manifest."
  end

This, to me, feels like trying to have your cake and eat it. By grouping all the configurable elements into one resource type you lose the ability to manage individual elements from different resources. The workaround here is to make the namevar a non-configurable attribute that only serves to provide uniqueness to resource declarations in the catalog.

The purpose of uniqueness in Puppet is to make the managed entities unique, and this work around loses this thus also losing strict idempotency. Consider this....

esx_system_resource { 'foo':
   host => '192.168.2.11',
   cpu_limit => '4000',
   ....
  }

esx_system_resource { 'bar':
   host => '192.168.2.11',
   cpu_limit => '9999',
   ....
  }

We should not be able to do that in Puppet and it will result in unpredictable behaviour.

One possible workaround would be a generic esx_system_resource_setting type that would look something like;

esx_system_resource_setting { '192.168.2.11:cpu_limit':
   value => '4000',
}

Something like that - with title_patterns mapping the host and setting attributes from the title.

You'd have to validate the value depending on what the setting is, which isn't so bad.

You could then replicate existing behaviour by providing a defined resource type called vcenter::esx_system_resource that churns out esx_system_resource_setting types but maintains the uniqueness of each setting.

I'm not saying the above is definitely the solution, but I do think we need to re-think this type going forward.

Thoughts?

crayfishx commented 8 years ago

Maybe something like this (purely a POC mock workup for now)...

https://github.com/crayfishx/vmware-vcenter/blob/poc/resource_setting/lib/puppet/type/esx_system_resource.rb