docs: Add documentation-test for run-command.md#52
docs: Add documentation-test for run-command.md#52mqasimsarfraz wants to merge 1 commit intomainfrom
Conversation
42e65b7 to
841b46d
Compare
841b46d to
81be06a
Compare
81be06a to
763d0d5
Compare
763d0d5 to
aad8b88
Compare
aad8b88 to
c09ff6c
Compare
717d4f9 to
26a81fc
Compare
26a81fc to
6c87024
Compare
Signed-off-by: Qasim Sarfraz <qasimsarfraz@microsoft.com>
6c87024 to
4dda796
Compare
| run: make documentation-test -o kubectl-aks | ||
| run: make documentation-test-readme |
There was a problem hiding this comment.
Why did you remove the -o kubectl-aks?
| kubectl aks config unset-all | ||
| ``` | ||
|
|
||
| Import the nodes information with the cluster information: |
There was a problem hiding this comment.
| Import the nodes information with the cluster information: | |
| Import the nodes information with the cluster information: | |
| > [!NOTE] | |
| > Passing the cluster information to the `config import` command is optional. However, in this specific case, it will force the command to retrieve the nodes information from the Azure API server instead of the Kubernetes API server, making this approach more resilient to issues on the Kubernetes control plane. |
| In case we want to print the imported information, we can use the `show` command: | ||
|
|
||
| ```bash | ||
| kubectl aks config show | ||
| ``` |
There was a problem hiding this comment.
If you check, we always execute config show after a config import. I started thinking that we should automatically print the imported data in the config import (maybe with a --quiet flag). Also for the documentation, it makes things more consistent. For instance:
Import node info:
kubectl aks config importRun command against one of the nodes (Folks will take the node name from the previous output):
kubectk aks run-command --node <myNode>WDYT?
| ```bash | ||
| kubectl aks run-command "ip route" | ||
| ``` | ||
|
|
||
| # Execute the run-command, and it will be automatically executed in aks-agentpool-12345678-vmss000000 | ||
| $ kubectl aks run-command "ip route" | ||
| The output should be similar to this: | ||
|
|
||
| <!--expected_similarity=0.8--> | ||
| ``` |
There was a problem hiding this comment.
I'm wondering if we should use another command that provides a more deterministic output so that we can use <!--expected_similarity=1--> or some regex to match an expected string.
Of course, this is something we can do later, not for this PR.
| Unset the current node to avoid conflict with flags or environment variables: | ||
|
|
||
| ```bash | ||
| kubectl aks config unset-current-node | ||
| ``` |
There was a problem hiding this comment.
#55 should solve this issue. It shouldn't be necessary anymore. In the documentation we said that the precedence is flags, env variables, config file. So, using the flag --id should simply have the precedence and don't go in conflict with the config file.
| GO_VERSION: 1.18 | ||
| AZURE_PREFIX: kubectl-aks-ci | ||
| AZURE_NODE_COUNT: 3 # multiple nodes are needed to allow running parallel 'run-command' against the same cluster | ||
| AZURE_NODE_COUNT: 4 # multiple nodes are needed to allow running parallel 'run-command' against the same cluster |
There was a problem hiding this comment.
| AZURE_NODE_COUNT: 3 # multiple nodes are needed to allow running parallel 'run-command' against the same cluster | |
| AZURE_NODE_COUNT: 4 # multiple nodes are needed to allow running parallel 'run-command' against the same cluster | |
| AZURE_NODE_COUNT: 4 # multiple nodes are needed to allow running parallel 'run-command' against the same cluster. See create-aks-cluster.nodes job. |
|
|
||
| ```bash | ||
| kubectl aks run-command "ip route" --id "/subscriptions/$SUBSCRIPTION/resourceGroups/$NODERESOURCEGROUP/providers/Microsoft.Compute/virtualMachineScaleSets/$VMSS/virtualmachines/$INSTANCEID" | ||
| <!-- TODO: Test following when we have a simple way to get instance information --> |
There was a problem hiding this comment.
We could do it with az in the CI and store that info in the ini file.
| echo "mySubID = ${{ secrets.AZURE_AKS_SUBSCRIPTION_ID }}" >> $f | ||
| echo "myRG = ${{ env.AZURE_PREFIX }}-rg" >> $f | ||
| echo "myCluster = ${{ env.AZURE_PREFIX }}-amd64-cluster" >> $f | ||
| echo "myNode = $(echo '${{ needs.create-aks-cluster.outputs.documentation-nodes }}' | jq -r ".[0]")" >> $f |
There was a problem hiding this comment.
I suggest to continue with the ini file approach.
|
|
||
| ```bash | ||
| kubectl aks run-command "ip route" --subscription $SUBSCRIPTION --node-resource-group $NODERESOURCEGROUP --vmss $VMSS --instance-id $INSTANCEID | ||
| Or using the flags: |
There was a problem hiding this comment.
| Or using the flags: | |
| Or using the individual flags: |
BTW, please add also the same TODO comment here.
| ```bash | ||
| kubectl aks run-command "ip route" --node aks-agentpool-12345678-vmss000000 | ||
| kubectl aks run-command "ip route" --node $myNode | ||
| ``` |
There was a problem hiding this comment.
After #52, we should need to clean up the config file. I think it is fine. We could add the unset-all here and explain that otherwise, the info already available in the config file will be re-used.
| ``` | ||
|
|
||
| Start using one of the nodes e.g `aks-agentpool-12345678-vmss000000` we call it `$myNode` here: | ||
|
|
||
| ```bash | ||
| kubectl aks config use-node $myNode | ||
| ``` | ||
|
|
||
| # Start using one of the nodes | ||
| kubectl aks use-node aks-agentpool-12345678-vmss000000 | ||
| Execute the run-command, and it will be automatically executed in `aks-agentpool-12345678-vmss000000`: | ||
|
|
||
| # Execute the run-command, and it will be automatically executed in aks-agentpool-12345678-vmss000000 | ||
| ```bash | ||
| kubectl aks run-command "ip route" | ||
| ``` | ||
|
|
||
| If we run another command, it will again be executed in `aks-agentpool-12345678-vmss000000`: | ||
|
|
||
| # Another command that will be still executed in aks-agentpool-12345678-vmss000000 | ||
| ```bash | ||
| kubectl aks run-command "hostname" | ||
| ``` |
There was a problem hiding this comment.
I don't know, it doesn't make sense to repeat everything here again. Probably, we should change the structure of this file:
- The two mechanisms to retrieve the info (and we verify the output from both using ExecDocs).
- Show the example (only once and no matter how we retrieve the info as we already tested that both are fine).
It's fine to manage this comment in later.
Add test for run-command.md. In order to test it locally you need to write an INI file at
docs/run-command.iniwith sample:Then use following to run the tests: