Hello!
I’ve been helping out a team with setting up a deployment pipeline that uses Azure Data lake Store, and so the obvious way to do this is to make use of the AzureRM.DataLakeStore PowerShell module. For those of you not ITK, Microsoft provide a set of PowerShell cmdlets that make use of the Azure Resource Manager model for managing Azure resources. These can be downloaded via the PowerShell Gallery. And because there are a fairly large amount of cmdlets, these are split into subsets, such as the aforementioned AzureRM.DataLakeStore Module. You can use it in your browser with Azure Cloud Shell, or you can install it on your local machine and use it in any PowerShell session.
To add a slight level of complexity, we need to check whether or not the DataLakeStore exists prior to attempting to create. This is so that we can run and rerun the process without changing the state of things. This is also known as creating scripts that are idempotent. Fortunately, there is a PowerShell cmdlet called Test-AzureRmDataLakeStoreAccount that tests the existence of a Data Lake Store account. Clearly we can run this, and then depending on whether “true” or “false” is returned create the Data Lake Store or make no changes. This script would look something like this –
View the code on Gist.
Quite simple, no? All nice and neat, making use of PowerShell cmdlets provided to us by Microsoft.
But…
When running this script via the automation process, I am greeted with this error –
Test-AzureRmDataLakeStoreAccount : Object reference not set to an instance of an object.a
Colour me confused! Running the exact same script on my machine (take a shot) all works well. So what could the issue be?
Turns out this is a bug in version 1..0.6 of the Module. Yes, I know this is an old version however this is a shared deployment machine and upgrading a PowerShell Module used by many different teams is something that is not really optional without a huge effort in terms of regression testing.
Turns out we need to get clever with writing the script. What we need to do is not only factor in that the object may not exist, but also capture an exception, whilst also taking into consideration that this Module may be updated at a later date and so should work with any further versions that are already available. Phew!
View the code on Gist.
This is far from ideal, but I’ve worked long enough to recognise that ideal is rarely achieved, and that “good enough” is the accepted standard.