Error with five Get-Unity* cmdlets: "Requested element, property or action is not supported..."
mtboren opened this issue · comments
Firstly, thanks, @equelin, for having made this module!
Following cmdlets throw error when invoked: Get-UnityLUNResource, Get-UnityFastCache, Get-UnityFilesystem, Get-UnityPool, Get-UnityStorageResource
The error, for Get-UnityStorageResource, for example, returning an error that the relocationPolicy property is not supported by current platform:
The array sends an error message:
Error code: 422
Error description: Unprocessable Entity
Error details: {"error":{"errorCode":131150138,"httpStatusCode":422,"messages":[{"en-US":"Requested element, property or
action is not supported by current platform:[relocationPolicy]. (Error Code:0x7d1313a)"}],"created":"2017-03-01T19:32:2
6.451Z"}}
Invoke-WebRequest : The remote server returned an error: (422) Unprocessable Entity.
At ...\Unity-Powershell\Private\Send-UnityRequest.ps1:20 char:15
+ ... $data = Invoke-WebRequest -Uri $URI -ContentType "application/jso ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommandSpeculation: this is Unity API version specific (this is happening against a Unity array whose API is at v5; however, cannot confirm that it is API-version-specific, as we only have APIv5 arrays)
Viable values for "fields=..." in API URIs seem to have changed in Unity API v5, and the given Get-Unity* cmdlets are all failing due to invalid field values being specified in URI by default.
Fact: One workaround is adding values to $Exception array of field names in the given cmdlets for when they then invoke Get-URLFromObjectType, which gets the $URL eventually used for Send-UnityRequest.
A more long-term fix is probably to dynamically get the field names to specify for each object type programmatically at Connect-Unity time, instead of having them statically defined within the PS module and then having to do field name exclusion per API version by populating the $Exception variable as mentioned above -- those available fields that are valid for the given version of the API can be retrieved from the API (at least in API v5, they can).
GitHub Issue Template items:
Please makes sure these boxes are checked before submitting your issue (put an X between the brackets).
- [ X ] Check that your Powershell version > 5.0 (Bonus point if you are using the latest version available)
- [ X ] Check that you follow the instructions for installing the module
- followed "manual setup" steps
Also, please provide:
- Any instructions that may help to reproduce the problem
- for Unity with software/firmare at a level that provides API v5, just invoking these cmdlets themselves will produce the problem (test Unity target is at software version
4.1.0)
- for Unity with software/firmare at a level that provides API v5, just invoking these cmdlets themselves will produce the problem (test Unity target is at software version
- Information about your host
$PSVerionTable
Name Value
---- -----
PSVersion 5.1.14409.1005
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14409.1005
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1- The list of the loaded modules
Get-Module:
ModuleType Version Name
---------- ------- ----
Manifest 3.1.0.0 Microsoft.PowerShell.Management
Manifest 3.0.0.0 Microsoft.PowerShell.Security
Manifest 3.1.0.0 Microsoft.PowerShell.Utility
Manifest 3.0.0.0 Microsoft.WSMan.Management
Script 1.1.0.1 PSReadline
Script 0.12.0 Unity-Powershell- And, some information about the storage array on which these actions were all taken (info from the REST API at URI
/api/types/basicSystemInfo/instances):
apiVersion : 5.0
softwareVersion : 4.1.0
earliestApiVersion : 4.0
model : Unity 600F
Hello @mtboren
First of all thank you for your interest to this module!
I would say that the API's version is not the only problem because those commands works well on my Unity VSA but not on your Unity 600F... It seems that the API has a different behavior depending of the hardware. Obviously, your 600F does not have FastVP enabled so the API does not accept any field value related to that functionality.
It means that I've to deal with different versions of the API and the hardware... I need to think about that a little bit more ! ;-)
those available fields that are valid for the given version of the API can be retrieved from the API (at least in API v5, they can).
I'm interresting about that information, do you have any example ?
Hello, @equelin,
I had an issue with the GitHub Issue that I created here -- I did not start of with a proper "thank you" to you for having made this module. Boo for me. I have now corrected that deficiency. And, thanks again!
Mhmm -- that is a nice little bit of complexity to consider and to handle in code (different API versions, possibly different behavior on different hardware in the same family).
As for an example for retrieving from the API itself the attributes of API object types, surre, I have an example! Check out this Gist. Maybe something that would be done, say, one time at connect-to-Unity-array time, for defining/confirming what objects' properties are on given array. Does that Gist convey the, well, gist?
As for an example for retrieving from the API itself the attributes of API object types, surre, I have an example! Check out this Gist.
This is huge! Thank you! Where did you find that information ?
Maybe something that would be done, say, one time at connect-to-Unity-array time, for defining/confirming what objects' properties are on given array. Does that Gist convey the, well, gist?
I was thinking about to store those informations in $global:DefaultUnitySession and used them to build requests. With this method we'll be able to automatically build the request no matter what the array is. It may add some latency during Connect-Unity...
What do you think about that ?
Indeed -- I was pretty excited to see that the API was self-documenting in that way.
This is huge! Thank you! Where did you find that information ?
I was just spelunking about, and thought that I would just try the straight-up /api/types URI. And, jackpot.
As for how to use that info: yes, we are pretty much thinking the same thing, there. It would cost a little at Connect-Unity time, but people will surely gladly endure (or at least I would) the extra few seconds for the extra value that comes from always having the correct fields values in the requests -- no error code 422 due to a slight change in the API.
The rest of the thought that I had was that the custom class definitions would still be needed (and that object types would be defined to have all properties that could be present for said object type), but that properties that might not actually get populated by return objects from the API would be nullable. That way, New-Object calls in cmdlets to create the return custom objects would not error -- the New-Object calls would return objects with all of the properties populated that are valid for the given API/hardware version, and the few other properties not pertinent to said API/hardware version would have $null values.
That's the thought, anyway. It'll be a bit of work to flesh that out, of course
As for how to use that info: yes, we are pretty much thinking the same thing, there. It would cost a little at Connect-Unity time, but people will surely gladly endure (or at least I would) the extra few seconds for the extra value that comes from always having the correct fields values in the requests -- no error code 422 due to a slight change in the API.
If you look at the develop branch (Module version 0.13.0) you'll be able to test my implementation of this idea ;-) My understanding is that you should be able to query your 600F with that version.
The rest of the thought that I had was that the custom class definitions would still be needed (and that object types would be defined to have all properties that could be present for said object type), but that properties that might not actually get populated by return objects from the API would be nullable.
There is now a new Pester test in Tests/Classes/Class.Tests.ps1 that will automatically check the custom class definitions against the information provided by the API. That test helps me to discover that I had forgotten some properties ;-). For now, class definitions are up to date with properties available in Unity VSA arrays but I don't know if it's true for physical Unity...
As always, feel free to provide any feedback!
Excellanté, I'll check it out! And, I'll share any feedback that I formulate. Cheers
Issues fixed in release 0.13.0
Confirmed fixed -- thanks!