Closed unkinected closed 1 year ago
johlju
commented
1 year ago If "loading facts" stage runs the method Get on all DSC resources then the media must be available at that point since the version of the media (the version of setup.exe) is used to determine the version that is gonna be installed (media must be available for all methods, Get, Test, and Set).
johlju
commented
1 year ago Is it possible to tell Puppet not to evaluate SqlSetup until runtime?
johlju
commented
1 year ago my first step is to copy the iso from a corporate file share and extract it
Another option is let SqlSetup do this copy by adding SourceCredential. Then it will mount a share that SourcePath points at and get the version from sqlsetup.exe on that path (it must be already extracted at source). When method Set run it will mount the share and copy the content of the SourcePath to a temporary local path, and install from that local path.
unkinected
commented
1 year ago Is it possible to tell Puppet not to evaluate SqlSetup until runtime?
I thought I had done all that by trying dependencies, virtual resources, and run stages, but if there's a way to delay Puppet calling Get-TargetResource until later, I'm not sure.
I took a look at the source code for sqlsetup and tried playing around by adding an optional "SqlVersion" parameter that would obviate the need for SourcePath during Get-TargetResource. I got too far in the weeds and decided to go another route.
It looks like the SourceCredential option wouldn't work for me... the "corporate file share" I mentioned is actually in an Azure storage file share, which is not as easily accessible, so the steps to download the ISO and extract it require more work than sqlsetup can handle.
I've worked around this for now by simply requiring our team to download and extract the ISO before applying the sqlsetup module. This two step process is less than ideal, but at least it gets me to the end goal.
johlju
commented
1 year ago I took a look at the source code for sqlsetup and tried playing around by adding an optional "SqlVersion" parameter
That was a thought I had too when I read this issue. I think it would be easy enough to just set $sqlVersion to a parameter SqlVersion instead of running these two lines.
Since it would be optional it wouldn't break anything else.
johlju
commented
1 year ago @unkinected I pushed this change in 16.5.0-preview0001 - try it and report back if there are any issues.
Problem description
I'm implementing sqlsetup using puppet. In my puppet module, my first step is to copy the iso from a corporate file share and extract it, the second step is to install SQL using sqlsetup, specifying the sourcepath as the local directory from step 1.
Unfortunately the code won't ever work because sqlsetup is somehow evaluating the sourcepath before anything else (technically, it's happening in the puppet "loading facts" stage). Because my directory doesn't exist until the module runs, and loading facts comes before the module gets applied, the whole thing fails. This happens no matter how I try to build a dependency tree... dependencies, virtual resources, run stages. If sqlsetup is declared/realized anywhere in my module, it tries to evaluate the sourcepath in the loading facts stage and kills the rest of the process.
The exact error depends on whether I've extracted the ISO to a directory or just mounted it as a drive, but generally follows like this:
C:\WINDOWS\system32>puppet agent -t Info: Using environment 'production' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: dsc_sqlsetup: Cannot find drive. A drive with the name 'S' does not exist.In the debug log I don't see anything related to sql during the loading facts stage, so I'm not sure what's going on in the above error.
Verbose logs
DSC configuration
Suggested solution
Evaluation of sourcepath should not happen until the sqlsetup resource is run.
SQL Server edition and version
SQL Server PowerShell modules
Operating system
PowerShell version
SqlServerDsc version