fix: RA2.2 README test command references missing 90-pod.yaml

[andrewwhitecdw]

This PR corrects the documentation in profiles/spectrum-x-ra2.2/README.md: RA2.2 README test command references missing 90-pod.yaml.

Changes

• profiles/spectrum-x-ra2.2/README.md: RA2.2 README test command references missing 90-pod.yaml.

Details

bash
-kubectl apply -f 90-pod.yaml
+kubectl apply -f ./output/network-operator/90-example-daemonset.yaml

-Check the pod has access to all rails:
+Check that a DaemonSet pod has access to all rails (replace `<pod-name>` with the
+name of an actual pod created by the DaemonSet):

```bash
-kubectl exec -it spectrum-x-multirail-test-pod -- sh -c "ip addr show && rdma link"
+kubectl exec -it <pod-name> -- sh -c "ip addr show && rdma link"

## Tests
- `profiles/spectrum-x-ra2.2/README.md`

## Contributor guidelines

Per this repo's [CONTRIBUTING.md](CONTRIBUTING.md):
- All commits are signed off (`Signed-off-by` trailer, DCO).

[greptile-apps]

Greptile Summary

The PR updates the RA2.2 testing instructions to apply the rendered example DaemonSet and execute checks in one of its pods, but the apply command still names a file that normal generation does not emit.

• Replaces the missing 90-pod.yaml reference with the example DaemonSet.
• Moves the apply path under ./output/network-operator/.
• Replaces the obsolete fixed pod name with an explicit pod-name placeholder.

Confidence Score: 4/5

The PR is not yet safe to merge because its revised apply command still points to a workload filename that normal generation does not create.

Normal generation emits the example DaemonSet as 90-example-daemonset-.yaml, while the README directs users to the nonexistent bare filename.

Files Needing Attention: profiles/spectrum-x-ra2.2/README.md

Important Files Changed

Filename	Overview
profiles/spectrum-x-ra2.2/README.md	Updates RA2.2 workload-testing commands, but the apply command omits the identifier suffix added to generated DaemonSet filenames.

_{Reviews (2): Last reviewed commit: "fix: RA2.2 README test command reference..." | Re-trigger Greptile}

[andrewwhitecdw]

@greptile-apps Thanks for the review. I have updated the testing section to use the rendered manifest path ./output/network-operator/90-example-daemonset.yaml and replaced the non-existent DaemonSet target with a <pod-name> placeholder so users select an actual pod created by the DaemonSet. The commit has been amended and pushed.

[greptile-apps]

Both changes look good:

1. The kubectl apply path now correctly points to ./output/network-operator/90-example-daemonset.yaml, consistent with the kubectl apply -f ./output/network-operator/ pattern used just above in the file.
2. The kubectl exec target is replaced with <pod-name> and accompanied by a clear inline note telling users to substitute an actual pod name — this is the right approach since DaemonSets don't have a fixed exec target like a named pod or deployment rollout.

LGTM.

[greptile-apps]

Generated workload filename mismatches

When a user generates the RA2.2 deployment files and follows this command, generation appends the merged group identifier to the DaemonSet filename, so the referenced bare 90-example-daemonset.yaml path does not exist and kubectl apply cannot deploy the example workload.

Knowledge Base Used: Spectrum-X addressing and topology