Shouldn't the Ensure DscProperty be part of the BaseDSC class? about dscr-for-vmware HOT 14 CLOSED

That is indeed a take on that, I didn't consider.

Resetting to default is a more of a concept for interactive "one-off" change.

Looking at your argumentation, I tend to agree with you on the one-off nature of defaults.
Providing the "defaults" as a sample configuration is probably the better solution.

The same is probably also applicable to #101
More so since default might change between vSphere releases.
In that case we could envisage a 'default' configuration for version X and one for version Y.

from dscr-for-vmware.

That could be a valid solution.
Let me check if that covers everything for non-Inventory objects.

from dscr-for-vmware.

Sorry for popping up there, accidentally ran into this issue.

The Default property is not really a great DSC experience IMO.
One of the problem is "how do you test whether the current settings is actually the default? Do you Hard-code the values? What if they change across vsphere versions?"

Point being that you hide the declarativeness of DSC.
But also, if a user enforce a setting that is ignored because Default is also selected, that's an anti-pattern.

The default config should probably be shown as an example configuration in your repository, so that if someone wants to reset some defaults, they can just take your example config and adapt it.

Resetting to default is a more of a concept for interactive "one-off" change, than enforcing settings to avoid configuration drifts.

from dscr-for-vmware.

Ok, so maybe we should create a separate issue where we can discuss adding default Configurations for the existing Resources.

from dscr-for-vmware.

Yes, as a [Feature] to start the concept, and later add it to the Coding Guidelines.
At least that is my current take on it.

from dscr-for-vmware.

For now only in the VMHostSatpClaimRule implementation, Ensure property is needed. In the future, if other resources require Ensure property, maybe it will be a good idea to put in the BaseDSC class.

from dscr-for-vmware.

I might be misunderstanding this, but imho the Ensure property should be a basic property of every DSC resource that is made available to the user.
It is through this property that you tell if a resource shall be present or not.
For builtin vSphere resources, like for example a HostService, there is probably no need for an Ensure property. We are not supposed to install/remove such a service itself, it comes with ESXi. We are only supposed to enable/disable and configure it.

But for most other resources (datastore, VM, switch, folder...) there is definitely a need to be able to tell if the resource should be there or not.

My thought, behind this issue, was to already implement it now as a base property, instead of having to add it later, and being forced to evaluate all possible impact.

Even with builtin resources, the Ensure property would make sense imho.
An Ensure='Absent' for a HostService for example, would imply that the HostService would be configured with its defaults.

But perhaps I'm missing the bigger picture you guys have in mind on your side?

from dscr-for-vmware.

Yes, I think for the resources you mentioned (datastore, VM, switch, folder...) the Ensure property will be a good idea. So right now the plan is to have InventoryBaseDSC class which will have the Ensure property and the resources will derive from it. As for the resources we have now - NTP, DNS, TPS settings for VMHost , I think we do not need the Ensure property - you pass only the settings you wish to change and the others are ignored. So the case Present/Absent is not applicable here. The same applies for vCenterStatistics and vCenterSettings - you only pass the things you wish to change. The SATP Claim Rules are an example of good usage of the Ensure property - we either want the rule to exists or we do not.

So after we develop the new base class for inventory objects, then the Ensure property will be part of it and new resources can be written.

from dscr-for-vmware.

I understand your reasoning, but how would you go about for removing said SATP Claim Rule?
And related, how would you go back to establishing system defaults? For example for a VMHostService?

from dscr-for-vmware.

For SATP Claim Rule removing - If the rule is present and Ensure is set to Absent - the rule is deleted, otherwise if Ensure is set to Present - the rule is not deleted.

For VMHostService - What do you mean by system defaults ?

from dscr-for-vmware.

In the case of VMHostService this is how a specific service is configured after a new ESXi installation.
There is in fact an esxcli command, for several services, to reset the service to the defaults.

from dscr-for-vmware.

What about adding the following property:

 [DscProperty()]
 [bool] $Default

So if the value is true we go back to establishing system defaults, otherwise we use the other passed properties ?

from dscr-for-vmware.

@lucdekens any updates on this one ?

from dscr-for-vmware.

Consolidated in #203

from dscr-for-vmware.