Switch out /service/etcd service endpoint for /service/storage/status to support multiple backends

[synackd]

Introduces one of multiple fixes for #20.

BSS used to support only the EtcD backend, so having a /service/etcd endpoint made sense. However, with the recent support of a PostgreSQL backend, it makes more sense to make this more generic.

This endpoint is now changed to /data/service/storage/status, and the response JSON now includes which backend is being used (i.e. "etcd" or "postgres") as well as the status of the connection to the printed backend.

So instead of:

# curl -H "Authorization: Bearer $ACCESS_TOKEN" https://foobar.openchami.cluster/boot/v1/service/etcd

One now queries /boot/v1/service/data. Here is what a successful query looks like:

# curl -H "Authorization: Bearer $ACCESS_TOKEN" https://foobar.openchami.cluster/boot/v1/service/data
{"bss-storage-backend":{"name":"postgres","status":"connected"}}

In the logs (with debug enabled):

2024/08/05 17:04:06 [bss/pMoC8hss4a-000288] "GET http://foobar.openchami.cluster/boot/v1/service/data HTTP/1.1" from 172.16.0.253 - 200 65B in 886.28µs                                                           
2024/08/05 17:04:06 Test access to postgres using BootParamsGetAll() succeeded
2024/08/05 17:04:06 DEBUG: Boot parameters returned: [{[] [b4:2e:99:a6:06:47] [] nomodeset ro root=live:http://10.100.0.1:9000/boot-images/compute/slurm/rocky8.10-compute-slurm-base-latest ip=dhcp overlayroot=tmpfs overlayroot_cfgdisk=disabled apparmor=0 selinux=0 console=tty0 console=ttyS0,115200 ip6=off ds=nocloud-net;s=http://10.100.0.1:8000/cloud-init/compute/slurm/ http://10.100.0.1:9000/boot-images/efi-images/compute/slurm/vmlinuz-4.18.0-553.5.1.el8_10.x86_64 http://10.100.0.1:9000/boot-images/efi-images/compute/slurm/initramfs-4.18.0-553.5.1.el8_10.x86_64.img {map[] map[] {      }}}] 

And here is what an unsuccessful query looks like, e.g. if Postgres goes down:

# curl -H "Authorization: Bearer $ACCESS_TOKEN" https://foobar.openchami.cluster/boot/v1/service/data
{"bss-storage-backend":{"name":"postgres","status":"error"}}

In the log:

2024/08/05 17:04:59 [bss/pMoC8hss4a-000300] "GET http://foobar.openchami.cluster/boot/v1/service/data HTTP/1.1" from 172.16.0.253 - 500 61B in 1.443017ms                                                         
2024/08/05 17:04:59 Test access to postgres failed: BootParamsGetAll(): postgres.GetBootParamsAll: Unable to query database: dial tcp: lookup postgres on 127.0.0.11:53: no such host

This PR also adds back in the /service/all endpoint to get all statuses at once:

# curl -H "Authorization: Bearer $ACCESS_TOKEN" https://foobar.openchami.cluster/boot/v1/service/all | jq
{
  "bss-version": "1.31.1",
  "bss-status": "running",
  "bss-status-hsm": "connected",
  "bss-storage-backend": {
    "name": "postgres",
    "status": "connected"
  }
}

[davidallendj]

That makes sense to make the endpoint to something that's agnostic to the storage backend. Having it to something like /data means that we wouldn't have to change it again in the future.

Just curious, does the endpoint just return general data in storage or is it returning something specific?

[synackd]

It essentially just returns just the connection status to whichever backend BSS is using. The current implementation doesn't return any other details besides this.

[davidallendj]

It essentially just returns just the connection status to whichever backend BSS is using. The current implementation doesn't return any other details besides this.

I'm wondering if it should be changed to something to reflect that or if we want to leave it as /data with the intent to put more stuff there later.

[synackd]

I like the idea of being able to add to it later, though I'll admit I'm not sure what else would be useful to add at this point.

You bring up a good point, /data could be interpreted as retrieving data BSS is storing or some metadata, etc. Maybe something like /storage?

[davidallendj]

I like the idea of being able to add to it later, though I'll admit I'm not sure what else would be useful to add at this point.

You bring up a good point, /data could be interpreted as retrieving data BSS is storing or some metadata, etc. Maybe something like /storage?

Yeah, I think /storage or /storage/info or something similar is more informative about the expected response. We can change or add another endpoint for /data if we do decide later to add more stuff.

[synackd]

/storage/status would be consistent with e.g. /service/status. Though /service has other endpoints besides, /status like /version. Even though we don't have any other endpoints to add under /storage right now, do you think it would be a good idea to add /status to it anyway, that way more could be added later if desired?

[davidallendj]

/storage/status would be consistent with e.g. /service/status. Though /service has other endpoints besides, /status like /version. Even though we don't have any other endpoints to add under /storage right now, do you think it would be a good idea to add /status to it anyway, that way more could be added later if desired?

Yeah, I think that would be reasonable. I definitely prefer a more consistent and predictable API when possible.

[synackd]

That makes sense. I'll change it to that, then.

[synackd]

OK, instead of /service/data, the endpoint is now /service/storage/status.

There is also an endpoint documented in Swagger as /service/all, but there wasn't a route for it in routers.go. I also added that back and updated the docs to include the new storage backend struct.

[synackd]

I updated the initial description to add the re-introduction of the /service/all endpoint:

# curl -H "Authorization: Bearer $ACCESS_TOKEN" https://foobar.openchami.cluster/boot/v1/service/all | jq
{
  "bss-version": "1.31.1",
  "bss-status": "running",
  "bss-status-hsm": "connected",
  "bss-storage-backend": {
    "name": "postgres",
    "status": "connected"
  }
}

[davidallendj]

Just a couple of small string-related things to look at.

[davidallendj]

LGTM.