Open nopjmp opened 4 years ago
In my experience adding a custom object model on top of the API in PowerShell is a big maintenance burden, as we'd need to duplicate and support all the things you can get from the native API objects. What worked well in my experience is using the raw API objects, especially if they are .NET class instances you have autocompletion on every property and can target them in Format.ps1xml files. I then like to use Types.ps1mxml files to add aliases to make the objects easier to work with, e.g. see: https://github.com/felixfbecker/PSKubectl/blob/master/PSKubectl/Types/ResourceV1.Types.ps1xml
For resources, we actually have two of the aliases you suggested (Name
and Age
), Status
would not be possible I think because that property already exists, but it could be under a different name. But these type aliases are all strictly additive so that all the underlying properties are still accessible. Notee: I just noticed SetScriptBlock
s are missing but those could be added.
I also define Format.ps1xml files for all types, so that in reality you actually shouldn't get the output above, but a table view similar to the one kubectl
outputs that actually uses those aliases for Name
and Age
.
The Az module (azure-powershell) uses proxy objects to make it easier for the end user to use and manage the objects. I'm not sure if this was a design decision, but the raw dotnet-kube-client objects are difficult to work for someone not familiar with the Kubernete's API.
The main idea would be to transform this:
into
The model can be based off of the information that kubectl provides and possibly adding a display option for "wide" output. The raw KubeClient model can be left as is, just the display and some helper items should be added.