Simplify running script assets in Otter Configurations (PSEnsure)

Jonathan.Engstrom

I have been struggling calling PowerShell Script assets when running PSEnsure Configurations. I have used an example that someone sent to me with some success. I am not able to call multiple script assets, and they refuse to load as PowerShell Modules sometimes for no apparent reasons. I would like to ask for a feature to be added that when you call a PowerShell script asset, to allow it to import for you. I also want to verify I can load multiple Script Assets, as I have tried and not succeeded. I have a great need to reuse code across multiple roles as I have nearly ~100 roles currently.

Example:

##AH:UseTextMode

set $ModuleName = Test-Function;
Get-Asset $ModuleName.ps1
(
    Type: Script    
);
set $ModuleNamePath = $PathCombine($WorkingDirectory, $ModuleName.ps1);

PSEnsure
(
    Key: Test-Function,
    Value: True,
    Collect: "$false",
    Configure: >>
    Import-Module -Name "$ModuleNamePath" -Verbose
    
    &$ModuleName

    >>
);

I would like to see as an option for calling the script asset to load the module automatically. I also want to be able to import Powershell modules in the Collect Phase as well.

atripp

Hi Jonathan,

First, I could see how this could be useful as a first-class feature, perhaps as an option on a PSEnsure operation. But that's probably more complicated, and I think what you're doing may be close. If you can get it working, you could always write a OtterSCript Module that has a similar outcome. Like, something like this...

call PSExecWithMods(>>
   powershell-here-that-uses-assets-as-modules
>>);

But before getting there, can you shed some more light on this?

they refuse to load as PowerShell Modules sometimes for no apparent reasons

Are you saying that a pattern like the sample script you shared, sometimes works, and sometimes doesn't? If so, the first thing that comes to mind is the dual-pass run nature of configuration plan executions; perhaps this may explain it, but also the code feels a little "strange" to me.

Get-Asset will never run in the first pass the (Collection), because it's an Execute-only operation
The configuration you have for PSEnsure will always cause drift because Collect returns "false" and the expected value is True

If you always want the block to run the Execution pass, then you could do this...

with executionPolicy=always
{
    Get-Asset $ModuleName.ps1
    (
        Type: Script    
    );
    set $ModuleNamePath = $PathCombine($WorkingDirectory, $ModuleName.ps1);
    PSExec >> 
        Import-Module -Name "$ModuleNamePath" -Verbose
        ....
    >>;
}
```

Jonathan.Engstrom

To add to this, I need the script assets to work in both the collect and configure passes, and I have not been able to get the module to work in both passes. I am not sure why they are so different, or would be designed in such a manner to disallow this to work. I have a great need to be able to call scripts and or modules to simplify my code and processes. Mostly as I need to keep extensive logging, I need to be able to during both collect and configure stages, I need to gather the existing settings in PowerShell for logging/ retention reasons. I then write that data to the computer's event log to be captured by logging systems.

I am not sure what you mean with the "call PSExecWithMods" example.

Also, I have one module I can run, Test-Module,ps1, but I have another script asset called TestOtter.ps1, and it won't load that PowerShell Asset. The actual content is the same; which makes it strange.

atripp

@Jonathan-Engstrom said in Simplify running script assets in Otter Configurations (PSEnsure):

I am not sure why they are so different, or would be designed in such a manner to disallow this to work.

The collect pass is "read only", and isn't supposed to change any server configuration at all. A Get-Asset operation always changes configuration (it always puts a file on disk), so by design, it doesn't run during the collect-pass.

I know a lot of people use PowerShell modules packages (i.e. things you install on a server), but I can see why using assets for this would be nice. It was never a design we had considered, which is why we'd need to modify the operations to do an automatic import.

I guess the only alternative i think of now, is to store the assets on disk, and use a sort of Ensure-Asset in another plan to do that. Then refer to it as like `c:\modulestore\myasset.ps1' or something

Jonathan.Engstrom

A Get-Asset operation always changes configuration

I am suprised that a "Get-Asset" " always changes configuration in stark contrast to powershell where the verb "get" is a read-only or gathering action only. This action, imho, is very poorly named.

So with that said, even if a collect is read only, I still don't understand why I can't load a script asset and gather/report data? Can a script asset be loaded to be made available for both collect and configure stages? That would be fantastic.

atripp

It's designed to download a file to disk; so naming aside (pretend it's called Write-Asset), it's still writing a file to disk, and thus it won't run in the collect phase.

As I mentioned, the feature wasn't designed to behave like you'd like it; most users will create/publish PowerShell module packages.

What your describing is nontrivial, from a design perspective, and we'd like to really consider it for the next major release of Otter, which is going to be focusing on things like "Compliance as Code". Based on some examples you shared, and how I've seen your Otter usage, I think you'll find those a lot more useful. We'll be exploring this mid-Q2.

In the meantime, I recommend you to just maintain the assets on disk somehow, and import them that way.

Jonathan.Engstrom

Alright, fair enough. As I use Otter almost exclusively for checking for compliance, I will look forward to this. Nontrivial asks are always the best ones, right? :D