# SDP Installer Test Suite

The SDP Installer, the `install_sdp.sh` script, is often customer's first touch point with the SDP and P4 software. It must deliver a customer experience that conveys ease of use and reliability supported platforms. We deliver that experience by exercising the script in a variety of configurations on a variety of Linux platforms.

The SDP Installer Test Suite consists of a fleet of server machines, one per platform, that lives in AWS, and specifically in the us-east-2 (Ohio) region (for no particular reason other than we keep using the same *.pem file to access the machines, and the pem file is region-specific).

Adding a server to the platform entails:

* Selecting a representative AMI for the platform, typically a vanilla AWS community or marketplace AMI for the OS.
* Launching an AWS EC2 instance using the selected AMI.
* Installing the SDP Installer Test Suite software.
* Added an 'ssh' wrapper script to make it easy to access the fleet.

Currently, the wrapper scripts live here on my local machine:

/Users/ttyler/ppn/BattleSchool/aws/pem/us-east-2

The script naming pattern is: ssh-install_sdp-test[<N>]-<PlatformTag>.sh, where <PlatformTag> is a combination of OS/architecture, and <N> is an optional whole number. The <N> numbers are used when a prior EC2 instance (VM) with the same <PlatformTag> is abandoned for some reason. So the <N> isn't really meaningful. The <PlatformTag> make it easy to remember the platform once explained, e.g. `r8x86_64` is for Rocky 8 Linux, x86_64 architecture.

The fleet is currently represented by this set of SSH wrapper scripts:

* ssh-install_sdp-test-r8x86_64.sh, Rocky 8 Linux on x86_64.
* ssh-install_sdp-test3-r9x86_64.sh, Rocky 9 Linux on x86_64.
* ssh-install_sdp-test-r10x86_64.sh, Rocky 10 Linux on x86_64.
* ssh-install_sdp-test-sles15x86_64.sh, SLES 15 Linux on x86_64.
* ssh-install_sdp-test-u20x86-64.sh, Ubuntu 20 Linux on x86_64 (obsolete)
* ssh-install_sdp-test2-u22x86_64.sh, Ubunu 22 Linux on x86_64
* ssh-install_sdp-test2-u24x86_64.sh, Ubunu 24 Linux on x86_64
* ssh-install_sdp-test2-u26aarch64.sh, Ubuntu 26 Linux on aarch64.

These scripts capture the pem file used and the AWS public IP for each EC2 instance, and also the sudo user associated with the AMI (e.g. ubuntu, rocky, ec2-user).  They all use the same pem file.

The SDP Test Suite for install_sdp.sh is now versioned in the `//test-install_sdp` stream depot on the Public Depot server (see Task 1.2 in `ProjectKickoff.md`), pulled via a `swap_source.sh`-managed clone rather than a fixed path.

It used to live in an intentionally obscure path, `//guest/tom_tyler/sw/main/install_sdp/dev/bin/...`, which is now frozen/deprecated (see Task 1.2's plan to add a "We've Moved" notice there). That path was chosen to avoid being highly visible even though it was publicly accessible. Documentation did not direct users to it. It was used only by SDP developers and a few trusted power user customers doing cool things, like pushing the limits of Infrastructure as Code (IaC) deployments of SDP in their environments.

A driving reason for this intentional obscurity is that this test suite contains a script aptly named `DANGER_CLEAN.sh`. That script is extremely useful and even necessary for iterative testing of `install_sdp.sh` on a given machine.  The `install_sdp.sh` script is designed for fresh installs on a new server machine, so `DANGER_CLEAN.sh` makes it like new (more or less). However, we don't want that `DANGER_CLEAN.sh` script to be part of the SDP package itself, lest it cause potential harm if accidentally misused.

(Digression: Really, `DANGER_CLEAN.sh` it not any more dangerous than having 'rm' on a machine. Doing `rm -rf` in the wrong place on a machine can wipe it out, and nobody is asking Linus to remove the rm command from Linux!  But we had a historical incident where a script called the "Helix Installer" -- a script named `reset_sdp.sh` that was the predecssor of both `install_sdp.sh` and `DANGER_CLEAN.sh` -- was operated on a production server despite very clear warnings in documentation not to run it in production. It wiped out the customer's data.  That sad event contributed to the Helix Installer being decomissioned, and split into two parts. The "safe" part of the logic, installing SDP on a fresh machine, went on to become the install_sdp.sh script, and that script is now part of the SDP itself rather than living in a separate software package. The dangerous parts of the script, the "reset" logic, survive in the `DANGER_CLEAN.sh` script that is part if this SDP Installer, which remains separate from the SDP.)