Setup Path is relative to the installer and not PWD

[nlowe]

The trident installer uses <installerPath>/setup as a required folder for initial setup operations:

trident/cli/cmd/install.go

Line 341 in 47c001b

setupPath = path.Join(installerDirectoryPath, "setup")

Unlike specifying paths to backend configuration files, this path is hard-coded. This makes it hard to deploy trident to multiple clusters. for example, I have a git repo with the following layout:

.
├── cluster1
│   └── setup
│       ├── backend.tmpl.json
│       ├── prod-storage-class.yaml
│       └── prod.tmpl.json
├── cluster2
│   └── setup
│       ├── backend.tmpl.json
│       ├── prod-storage-class.yaml
│       └── prod.tmpl.json
├── cluster3
│   └── setup
│       ├── backend.tmpl.json
│       ├── prod-storage-class.yaml
│       └── prod.tmpl.json
├── cluster4
│   └── setup
│       ├── backend.tmpl.json
│       ├── prod-storage-class.yaml
│       └── prod.tmpl.json
├── README.md
└── tridentctl

I have to copy tridentctl to each cluster folder to be able to perform installation and some configuration operations on each cluster. I would like to instead be able to call ../tridentctl from one of the cluster folders. For example:

~/projects/trident-installation/cluster2$ ../tridentctl -n trident install

instead of

~/projects/trident-installation/cluster2$ cp ../tridentctl .
~/projects/trident-installation/cluster2$ ./tridentctl -n trident install
...
~/projects/trident-installation/cluster2$ rm ./tridentctl

This would also allow me to install tridentctl in a system-wide context on my $PATH so I can perform administrative operations on the cluster without being in a directory with a copy of the installer binary.