You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> These notes are intended to compliment and extend the common instructions for this process. If you spot a sensible common location where part of this document could live, please do move the information out of here.
> These notes are intended to complement and extend the common instructions for this process. If you spot a sensible common location where part of this document could live, please do move the information out of here.
3
3
4
4
# Overview
5
5
## Why Custom Cmdlets?
6
-
Powerhsll cmdlets can be created almost totally automatically for many products but ConnectedKubernetes is special. The standard cmdlet interations are one or more ([Swagger]) REST API exchanges with Azure but ConnectedKubernetes also has to install Azure Arc support into a Kubernetes cluster and this requires work to be performed using [helm].
6
+
Powershell cmdlets can be created almost totally automatically for many products but ConnectedKubernetes is special. The standard cmdlet interactions are one or more ([Swagger]) REST API exchanges with Azure but ConnectedKubernetes also has to install Azure Arc support into a Kubernetes cluster and this requires work to be performed using [helm].
7
7
8
8
For this reason, the ConnectedKubernetes cmdlets have two or more steps such as:
9
9
- Interact with Azure using the REST APIs; this often involves just calling the autogenerated cmdlets
10
10
- Now interact with Kubernetes using [helm].
11
11
12
12
## (Part) Autogeneration Process
13
-
The autogeneration process uses [autorest.powershell], an [autorest] extension for creating Powershell cmdlets based on a (Swagger) REST API definition. this is typically as follows:
13
+
The autogeneration process uses [autorest.powershell], an [autorest] extension for creating Powershell cmdlets based on a (Swagger) REST API definition. This tool is run via an [autorest][Docker] image (you will need something like [Docker Desktop] installed). The typical cmdlet development process is this:
14
14
15
15
1. Carefully craft your [Swagger] definition of the REST API
16
16
1. Read the [Quickstart for Azure PowerShell development using code generator]
17
17
1. Clone the [azure-powershell] repo
18
-
1. Create a develpoment branch based on the `generate` branch **and not based on `main`**!
19
-
1. Run the [autorest] Docker image; if you have no local image for [autorest], refer to
20
-
1. Run [autorest] to generate configuration and files that will result in the autogenerated cmdlets
21
-
1. Run the build process (`pwsh build-module.ps1`) which completes the build process.
18
+
1. Create a development branch based on the `generate` branch **and not based on `main`**!
19
+
1. Run the [autorest][Docker] image; see below if you do not already have a local image for [autorest],
20
+
1. Inside the [autorest] environment...
21
+
1. Run `autorest` to generate configuration and files that will result in the autogenerated cmdlets
22
+
1. Run the build process, `pwsh build-module.ps1`, which completes the build process
23
+
1. Optionally create a local package `pwsh pack-module.ps1`.
24
+
25
+
---
26
+
Note that many of the intermediate steps rely on output from a previous step. For example `build-module.ps1` is an output from the `autorest` step.
27
+
28
+
---
22
29
23
30
### Building the [autorest] Docker image
24
-
> Do **NOT** build an [autorest] image based on the Dockerfile contained in the `tools/autorest` directory below the [azure-powershell] repo as this does not produce a working image!
31
+
If you do not already have an [autorest] image, do **NOT** build one using the Dockerfile contained in the `tools/autorest` directory in the [azure-powershell]- repo as this does not produce a working image! Instead, build the image like this:
25
32
26
33
- Clone the [autorest.powershell] repo
27
34
- Navigate to the `tools/docker` directory
28
-
- Follow the instructions in the README file in that directory
35
+
- Follow the instructions in the README file in that directory.
29
36
30
37
## Special Aspects for ConnectedKubernetes
31
38
The autogenerated cmdlets are created in C# with Powershell wrappers that are placed into the `internal` folder. This is because we are **NOT** exposing the autogenerated functions to the user, rather er export our custom versions.
32
39
> As described earlier, the custom versions often call-through to the autogenerated version to perform the ARM REST API portion of their work.
33
40
34
-
### Gotchas
35
-
#### You Want a New Cmdlet?
41
+
The custom cmdlets can be found in the `custom` directory. They are written in Powershell and do some manuipulation of input parameters before interacting with Azure and then Kubernetes via [helm].
42
+
43
+
## Gotchas
44
+
### Desktop Powershell (v5.1) Back-Compatibility
45
+
The `Az` packages are all written to work with the preinstalled Windows Desktop version of Powershell, which is obsolete!
46
+
47
+
We have to maintain this compatibility and the way to prove this is to use `PSScriptAnalyzer` (invoked as `Invoke-ScriptAnalyzer`) to confirm this. The process is below and the following references contain useful information:
Write-Error 'ScriptAnalyzer found (possibly back-compatibility) issues.'
85
+
}
86
+
```
87
+
88
+
89
+
### Dependencies
90
+
We have thus far been unable to make the `Az.ConnectedKubernetes` module install its dependencies (`Az.Resources` and `Az.Accounts`). This is possible for powershell but the issue is that the configuration to do this has to somehow be passed through the [autorest] process and attempts to do this have thus far failed.
91
+
92
+
### You Want a New Cmdlet?
36
93
If you are creating a whole new command, then you need to get the [autorest] process and the build process to work together to create the underlying `internal` command for you and this is not trivial.
37
94
38
95
When we tried to add the `Set-` cmdlet, we found it never appeared but eventually we discovered these nuggets of knowledge.
39
-
-[autorest] will look at the `operationId` field in the [Swagger] for each REST API method and determine what commands to create. So in our case `ConnectedCluster_Create` only causes `New-` cmdlets to be created and we had to update the [Swagger] to say `ConnectedCluster_CreateOrUpdate` before any `Set-` cmdlets were created
96
+
-[autorest] will look at the `operationId` field in the [Swagger] for each REST API method and determine what commands to create. So in our case `ConnectedCluster_Create` only causes `New-` cmdlets to be created and we had to update the [Swagger] to say `ConnectedCluster_CreateOrUpdate` before any `Set-` cmdlets were created. Note that there are other options possible and the Swagger teams preferred `ConnectedCluster_CreateOrReplace` which works just as well for what we need and introduces no external API differences.
40
97
- The `internal` cmdlets are really just Powershell wrappers but these are not created until the `pwsh build-module-ps1` step
41
98
- Between the steps above sits the [autorest] configuration found in the XML at the end of [README.md]. This does stuff like:
42
99
- Stops the generation of various versions of cmdlets that are not required
@@ -48,4 +105,6 @@ When we tried to add the `Set-` cmdlet, we found it never appeared but eventuall
48
105
[Swagger]: https://swagger.io/
49
106
[README.md]: ./README.md
50
107
[Quickstart for Azure PowerShell development using code generator]: https://eng.ms/docs/cloud-ai-platform/azure-core/azure-management-and-platforms/control-plane-bburns/azure-cli-tools-azure-cli-powershell-and-terraform/azure-cli-tools/onboarding/azurepowershell/quickstart_codegen
0 commit comments