refactor(web): bring back zFCP support (new HTTP / JSON API, queries, and TypeScript)

[jreidinger]

Trello: https://trello.com/c/KMtaVltF (internal link)

This PR could be seen as a follow up of https://trello.com/c/2LC8JEZR (internal link) but in this case bringing back the support for managing zFCP devices on s390x architectures.

It includes:

• Extending the HTTP API to expose zFCP devices management and zFCP related events.
• Adapting the WEB UI for using Tanstack queries and the new HTTP API.
• Adopting Typescript
• Move to route pages.

HTTP / JSON API Examples

This section contains a few examples you can use to explore the API. For the ones using curl, it is required to have a headers.txt file containing the credentials. The file can be generated with:

#!/bin/bash

SERVER=myServer
PASSWORD=myPassword

TOKEN=$(curl --insecure -s -X POST ${SERVER}/api/auth -H 'Content-Type: application/json' -d '{"password": "'${PASSWORD}'"}' | jq -r ".token")
echo "Obtained token '${TOKEN}'"

echo -n "Authorization: Bearer " >headers.txt
echo $TOKEN >>headers.txt

zFCP operations

Probing

$ curl -s -k -X POST ${SERVER}/api/storage/zfcp/probe -H @headers.txt | jq
null

Check if zFCP is supported

$curl -s -k ${SERVER}/api/storage/zfcp/supported -H @headers.txt | jq
true

Check whether allow_lun_scan is globally enabled or not

$curl -s -k ${SERVER}/api/storage/zfcp/config -H @headers.txt | jq
{
  "allowLunScan": false
}

Get Controllers with complete information like WWPNs and LUNs

$ curl -s -k ${SERVER}/api/storage/zfcp/controllers -H @headers.txt | jq
[
  {
    "id": "1",
    "channel": "0.0.fa00",
    "lunScan": false,
    "active": true,
    "lunsMap": {
      "0x500507680d7e284a": [],
      "0x500507680d0e284a": [],
      "0x500507630b181216": [
        "0x4020404900000000"
      ]
    }
  },
  {
    "id": "2",
    "channel": "0.0.fc00",
    "lunScan": false,
    "active": true,
    "lunsMap": {
      "0x500507680d0e284b": [],
      "0x500507630b101216": [
        "0x0000000000000000",
        "0x0001000000000000"
      ],
      "0x500507680d7e284b": []
    }
  }
]

Get Active Disks

$ curl -s -k ${SERVER}/api/storage/zfcp/disks -H @headers.txt | jq
[
  {
    "name": "/dev/sda",
    "channel": "0.0.fa00",
    "wwpn": "0x500507630b181216",
    "lun": "0x4020404900000000"
  },
  {
    "name": "/dev/sdb",
    "channel": "0.0.fc00",
    "wwpn": "0x500507630b101216",
    "lun": "0x0000000000000000"
  }
]

Disk activation

CONTROLLERID=1
WWPN=0x500507630b181216
LUN=0x4020404900000000
curl -s -k -v -X POST ${SERVER}/api/storage/zfcp/controllers/${CONTROLLERID}/wwpns/${WWPN}/luns/${LUN}/activate_disk -H @headers.txt | jq
null

Web UI Screenshots

The web has been adapted according to the recommended components to be used for Pages and content as well the Disk Activation Form has been moved from a Popup to its own route and Page.

Additional notes

The PR also includes minor internal changes related to Storage DASD components, some of them related to page actions.

[dgdavid]

BTW, maybe I miss something at some point but the only suggestion I see is about the naming: #1570 (review)

But not about the full structure. I've no strong opinion about writing them as function or object. But I though we were writing them always as function for consistence since they could receive args for building the query. As far as I can see, @imobachgs has wrote some as function and some as object in the storage part too. We can go ahead with such approach if you guys think it is better, but we should be consistent in all places.

PLEASE, do not take this comment as a suggestion for continue sending changes against this PR. Whatever we decide to choose should be addressed in a change unifying all the queries across the code.

[teclator]

This change was based on this another suggestion #1570 (comment), in that case objects were used, so, I also does not have an strong opinion and agree on unifying.

[dgdavid]

Ok, I see.

As said, let's go ahead and talk about it later, once we finish the queries implementation.

[imobachgs]

This change was based on this another suggestion #1570 (comment), in that case objects were used, so, I also does not have an strong opinion and agree on unifying.

Well, the point of my comment was not the queryKey thingie, but the overall approach of the whole function. I added another note about it (see #1570 (comment)).

[imobachgs]

Suggested change

	// TODO: maybe move it to model? but it needs also additional calls to dbus
	// TODO: maybe move it to model? but it needs also additional calls to D-Bus

[imobachgs]

According to this comment, the call to OwnedPath::try_from will fail, right? So what is the point of this code?

[imobachgs]

We already had a helper to get the ID from a path. See https://github.com/openSUSE/agama/blob/bc057f474f9783717f355af970440e7215b2b705/rust/agama-lib/src/dbus.rs#L73.

[imobachgs]

np: Do you plan to do something with this comment? Otherwise, I would remove the TODO prefix.

[teclator]

@jreidinger I guess it is a question you wanted to raise and discuss, so, will remove the comment but maybe this thread could be used for having that discussion... by now it looks good to me to leave the definition where it is, @imobachgs, what do you think?

[imobachgs]

It is fine. I do not like that we use two different approaches, but let's move on.

[imobachgs]

LGTM. Congrats!