-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: Add documentation-test for run-command.md #52
base: main
Are you sure you want to change the base?
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 <[email protected]>
6c87024
to
4dda796
Compare
run: make documentation-test -o kubectl-aks | ||
run: make documentation-test-readme |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 import
Run command against one of the nodes (Folks will take the node name from the previous output):
kubectk aks run-command --node <myNode>
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
```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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
On the other side, if we already have the node (VMSS instance) information and we don't want/need to save it locally, we could pass it directly as following: | ||
|
||
```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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do it with az
in the CI and store that info in the ini file.
.github/workflows/kubectl-aks.yml
Outdated
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.ini
with sample:Then use following to run the tests: