Skip to content
This repository has been archived by the owner on Aug 21, 2020. It is now read-only.

Name parameter in esx_system_resource. #205

Open
crayfishx opened this issue Aug 4, 2016 · 1 comment
Open

Name parameter in esx_system_resource. #205

crayfishx opened this issue Aug 4, 2016 · 1 comment

Comments

@crayfishx
Copy link
Contributor

crayfishx commented Aug 4, 2016

@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
Copy link
Contributor Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant