MountImage Name parameter

[mmajcica]

Since at least version 2.6.0.0 of xStorage the Name parameter was removed. This is unfortunate as now ImagePath is a key. This means that if we would like to first mount, use it, then unmount a resource in our configuration this will not be possible anymore.
Will there be a chance that this property gets reintroduced or am I missing something about the logic that draw you to take it out?

[PlagueHO]

Hi @mmajcica - thanks for raising this. This has been raised in this issue: #73

Although I completely understand your use case here, it actually goes against the intended behavior of DSC. What I mean is that typically we shouldn't think about DSC as a set of steps that need to be applied in order to go from one known state to another. DSC was intended to define a desired end state of each individual resource. Each unique resource (such as a mounted ISO in this case) should be represented by only a single state in a configuration. You'd also end up with the ISO being continuously mounted and dismounted each time the LCM fired.

Otherwise what happens is the node can never reach a desired state - as the state in the case of the config you mention would be internally conflicting - e.g. Should the disk be mounted or not? So reporting on a machine state in this case would give a nondeterministic result.

At the end of applying a DSC configuration the state should always be deterministic - if that makes sense?

We have struggled with a solution to this problem for some time and unfortunately haven't got an ideal solution. You can of course leave the ISO mounted at the end of the config (although again, not ideal).

Alternately you can use the Script resource to perform the mount, install, dismount task or even look at doing this in a composite resource.

[mmajcica]

Hi @PlagueHO ,

thank you for your complete answer. This is something I was suspecting and indeed the use I presented goes against the principals of DSC. It is a good observation about the LCM which only applies, if I'm not wrong, in case of the pull setup.

All of this as I'm provisioning several MSI's that are part of different ISO files and I do mount-dismount on the same drive letter each time. I could probably just specify different ISO on the same drive letter and not worry about unmounting it.
It is also a good suggestion about getting rid of the mount in a simple Script as a workaround.

Thank you for now.

[PlagueHO]

Sorry I couldn't provide an adequate solution on this one - and it is definitely a perfectly valid use case.

The LCM can still apply multiple times in Push mode as well Pull mode, but you are right, this problem is only going to occur if the LCM is set with ConfigurationModeFrequencyMins > 0 and ConfigurationMode is ApplyAndAutoCorrect.

Again, I wish I had a good solution for you - but script should work fairly well (I've used in for similar things myself).

[mmajcica]

Having the DriveLetter set as a key, will not allow us to reuse the drive letter for our installations.
Provisioning several tools that do ship as iso files will just be difficult in this case as drive letters are not infinite.

What was offered in the previous versions and that was a Name param, made things implicitly less compatible with the idea of desired state, however it was way more flexible and usable.
This is just pushing some of use to use an old and outdated version of the module.

[PlagueHO]

Perhaps an alternative would be for creation of a new resource that combines the mounting, installation and dismounting process in a single Set, but only if the Test determined the software was not installed.

I do understand the need for this. It was changed because it had been the cause of other problems due to being able to be misconfigured. It also could also allow VHD/VHDx in read/write mode to be mounted more than once which was also a problem.

One other alternative - and I'm fairly uncomfortable even suggesting such a solution - is adding a second copy of this resource for just mounting an ISO to a drive (pretty much like the older one), without support for VHD/VHDx and with big warnings all over it about it potentially resulting in non-deterministic configurations/nodes and violating DSC practices. Using it to mount and then dismount will always result in configurations that never reach desired state. And very damaging when used in Pull mode (e.g. every time the disk will be mounted and dismounted - 100s of times a day).

@johlju - do you have any ideas for a solution on this?

[johlju]

@mmajcica I understand you problem, but sounds like you looking for creating a programmatic flow with DSC, and it isn't built for that, it's built for keeping a desired state. It's built for making sure the iso, in this case, is mounted on a drive letter, if it is not, it will be remounted. Being able to specify more than one .iso will make a ping-pong behavior, when the configuration can never be in desired state.

If you have so many .iso's that needs to be mounted I suggest adding those that can, to a network share and install from there (without the need to mount). If that is not possible, then I suggest a xScript resource (or rather a dedicated resource for the application) that mounts the .iso for the application, only if that application is no longer in desired state. That way you can reuse the same driveletter for each xScript and you wont get the ping-pong behavior.

[mmajcica]

@johlju you are tight about the tool not being built for that and that what I am trying to do is an abuse of the idea that stands behind the DSC.
I'll look up for a better approach as soon as I do get a chance to refactor the current script; for now sticking to 2.6.0.0 version of xStorage. Thanks