Test-AzureRmResource Functionality

[ronbok]

Just ran one of my scripts and noticed this is now depreciated? What is replacing this??

[devigned]

@vivsriaus any thoughts on this?

[ronbok]

https://social.msdn.microsoft.com/Forums/en-US/cf5f7777-e5f2-4423-bdcd-db4b611e1be6/different-behavior-on-getazureresource-it-started-to-throw-resourcenotfound-exception-from-v091?forum=azurescripting&prof=required

This is a post just from June 17th, I can't believe this would be deprecated already, so I'm going to chalk it up as being a bug for now until l hear otherwise.

[ronbok]

This is taking way too long to resolve. I'm going to repeat what I said and pile onto issue #428 as another example. Microsoft needs to get its act together as far as PowerShell & Azure are concerned. PowerShell is just becoming so unstable and unreliable as a tool for Azure with its rapid month to month changes that folks are going to start getting turned OFF. Meanwhile, Microsoft SALES resources are out there telling customers how great Azure is as if it's Production ready...and its going to backfire very soon. Partners and customers don't want to have re-write these complex scripts on a monthly basis. Each Azure Resource needs a Test-AzureResource as these names need to be unique and it's crazy for us to have to right code/functions to do this grunt work when the platform should allow it to be done with a single line of code.

[ravbhatnagar]

@ronbok - Sorry for the inconvenience that this has caused you. Although, currently we do have the Test-AzureResource and Test-AzureResourceGroup cmdlets, they are not implemented in an ideal way which would work well for all scenarios. The plan is to remove it next release and later provide a way which works more reliably in all cases.

[ravbhatnagar]

To add some more detail, the way the cmdlet is currently implemented does not provide a reliable way to validate if a "name" is available for a particular resource type. It currently checks if a "resource" exists or not. Even for that, in the current implementation it is not guaranteed that it will work all the time across all the different types of resources. This is the reason we are planning to remove it and provide a solution which works consistently and reliably across all resource types.

[ronbok]

While anyone can certainly understand wanting improved functionality, why the need to remove it, then add it back? This approach is heavy handed in my view and is the root of my complaint. An API/Class has a contract and by removing it entirely - breaks that contract. Why not take the approach of leaving it in and simply enhancing it? What am I missing here?

[ravbhatnagar]

I completely understand that breaking the contract is not good for the customers and can cause a lot of rework. And let me assure you that we don't take these decisions lightly. We do it only if such changes are for the greater good and would serve better longer term. The reason behind the plan to remove this cmdlet is that we don't want to continue shipping something and leading more customers towards a path which is not guaranteed to work.

[erezyaron]

I am about to embark on this path to create these complex PS scripts, following blogs and articles from the last 3 months, and already finding out they are not correct as they are not guaranteed to work.
so what is the correct path to go down for checking resource existence?

[mpiroc]

I share ronbok's concern: Why is this cmdlet being removed before its replacement is available? Even if the current cmdlet is not 100% reliable, customers are using it. Removing it next release means that customers will have a working solution 0% of the time instead of most of the time.

[pauldalyii]

+1

Is there an ETA for Test-AzureRm* support?

[vicp-iq]

Hey, looks like there hasn't been any movement on this for a 6 weeks. Is there any ETA yet?

[Pete-rePete]

Yes, update please!

[vivsriaus]

We apologize for the delay here. Stepping in for @ravbhatnagar (who is OOF and should be back next week). As he pointed out above, the original implementation of the cmdlet was not a reliable way to check if a resource exists or not. That said, there are multiple ways to achieve this using an existing cmdlet. For example:

$r = Find-AzureRmResource -ResourceType Microsoft.Web/serverFarms -ResourceGroupNameContains MyGroup | where {$_.ResourceName -eq 'myServerFarm'}

I can then check if $r is null to get a similar behavior you'd get with Test-AzureRmResource.

Like @ravbhatnagar mentioned above, the ideal way to implement Test-AzureRmResource requires changes in the backend, which is still pending.

[ravbhatnagar]

This is still pending at large as we don't have the needed support from the different RPs to reliably implement this. The above mentioned workaround is the best bet to achieve the desired functionality.

[Pete-rePete]

Thanks for the update. The workaround is not pretty, but at least we're able to do this.

[ravbhatnagar]

#639

[ravbhatnagar]

Update: We are working on a solution for this. Will provide ETA through the milestone soon.

[graemechristie]

Any update on this ?

[MattAllison]

Update?

[markcowl]

We are looking at this and will provide equivalent functionality soon