You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 21, 2020. It is now read-only.
@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.
Thoughts?
The text was updated successfully, but these errors were encountered:
@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?
The text was updated successfully, but these errors were encountered: