@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....
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.
@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...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....
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;Something like that - with title_patterns mapping the
host
andsetting
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 outesx_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?