playfab / thundernetes-ui Goto Github PK

Sometimes, during development, we need to generate random GUIDs to allocate GameServers. It would be useful if this was somehow provided in the Game Server view.

On GameServerBuild view, we should show errors when Patch fails.

Can we default patch numbers to the existing standingBy and max to avoid the user sending zero values by mistake?

It would be useful if we showed a different color (red?) for GameServers that have crashed.

(maybe for a different PR) can we do an empty string check here?

Originally posted by @dgkanatsios in #30 (comment)

Can we show the protocol (TCP/UDP) on portsToExpose?

Game Server view can be a long list for GameServerBuilds with a large number of GameServers. Can we have a paging mechanism?

Can we show the max here? This will make it clear for users if their actual standingBy is less than the desired.

We should provide the ability to the user to clone an existing GameServerBuild, by providing the cloned one as a starting point for a new one. Depends on #36

We should add links to Thundernetes on GitHub and Thundernetes website.

Sometimes Patch is not working on GameServerBuild view - that might be related to #19

It would be useful if we could delete GameServers (e.g. stuck ones) in the GameServer view.

there was another error where the /gameservers returned 500 (there was an issue with the GameServerAPI on the cluster) and the web page showed an empty page instead of an error.

Originally posted by @dgkanatsios in #30 (comment)

Using the useEffect hook to retrieve data can lead to many problems in the future, we should move to use libraries such as React Query to avoid this.

(maybe for a different PR) allocating with an existing session ID should show a message?

Originally posted by @dgkanatsios in #30 (comment)

It would be useful if we were able to sort with different columns on GameServer view. E.g. with creation date or last updated date

It would be useful to use a sessionID to search in the Active GameServers in the GameServer view.

is this intended?

Originally posted by @dgkanatsios in #30 (comment)

When we are in the GameServerBuild view, the autorefresh overwrites the value in the standingBy/max textboxes. Maybe we could have them separately?

Currently it is using the crypto module, but this is not available in all browsers.

Can we show to the user the server IP:PORT after clicking the allocate button? This way the user can use this IP:PORT tuple to run their tests.

We should support the option to create a GameServerBuild. We could have a textbox where the user will enter the YAML of the GameServerBuild they want to create.
Ideally

• we can have a starter YAML template to provide the user with a starting point
• we can do some validation of the YAML (at least the structure of it) before we send it to the server

Can we show Status and the Spec, since Status (the actual state) is of more interest to the user?

Currently the script expects an environment variable (REACT_APP_GAMESERVERAPI_URL) with the cluster configuration. Maybe we can make it a JSON file which can be mounted via a ConfigMap on a Pod?

We should also display meaningful errors to the user, when it fails to be parsed.

We should explain that the 2/2 number is the "desired/actual" number of standingBy servers.

I ended up deploying a GameServerBuild with the same name/buildID on two different clusters and this seemed to have made the system lose some context. For example, when I click on the different build names on the left, the GameServerBuild view is not updated.

We should provide an easy way to visually differentiate between StandingBy and Active GameServers.

We should provide a way for the user to configure authentication to the gameserverapi.

This is dependent on a work item on Thundernetes for gameserverapi to be secured.

Once we move into GameServer view, it's not clear in which GameServerBuild we are looking at.

It would be useful if we showed a different color (red?) for GameServerBuilds that have an Unhealthy status.

The app should be available as a container image, this image should be able to be configured without having to rebuild it.