TRD GUI

[habanoz]

A GUI component to configure and manage TRD would be very useful. Such a component would decrease user involvement and improve user-friendliness.

GUI development should be broken into phases. In the second phase, reporting and monitoring can be added.

In the first phase:

• Creating and updating the baking configuration
• Service enable/disable
• Starting and stopping TRD service: Both in service mode and manual modes.
• Monitoring liveness.
• Basic authentication and authorization

In the second phase:

• Reporting (Details to be set)
• Monitoring (Details to be set)

[habanoz]

@jdsika I would like to work on this task.

@utdrmac Is it OK for you?

[utdrmac]

In my initial designs, TRD itself is the http server hosting the HTML and any needed REST API endpoints for GUI functionality. So, I don't understand how the GUI can stop/start TRD, if TRD itself is needed to run the GUI. Sure, you can shut down the TRD from the GUI, but you'd have to start TRD from CLI again in order to see the GUI.

Example: python3 src/main.py -P tzstats -A 127.0.0.1:8732 -O 33 -V on -G 127.0.0.1:8080

The -G flag accepts an IP:PORT to bind the http listener. If not provided, GUI does not run.

The GUI itself would be a few static html pages, with a lot of javascript pulling data via REST back to TRD.

127.0.0.1:8080/api/status <-- current /head from local RPC, approx time to next payouts 127.0.0.1:8080/api/config <-- GET retrieves yaml config, POST or PUT updates config. 127.0.0.1:8080/api/reports/298 <-- returns payouts report for cycle 298 etc...

I feel that something like Angular or React would be overkill for this (feel free to correct me). Jquery and bootstrapcss should be all we need.

[habanoz]

I believe TRD should remain as is. My proposal includes creating a separate GUI component to manage TRD. Use of GUI would be optional. Users preferring CLI should continue as they are used to.

To give an idea following command can be used to start the GUI component. (Actual command can be quiet different): python3 src/gui.py

I feel that something like Angular or React would be overkill for this (feel free to correct me). Jquery and bootstrapcss should be all we need.

I agree. This complies with my perspective. GUI should be simple, plain and useful.

Please continue the discussion so that we end up with the most suitable design.

[utdrmac]

creating a separate GUI component to manage TRD python3 src/gui.py

I 100% disagree with this. Look at every other linux-based tool that provides a web UI. Every single one is integrated into the base application. We should not use a separate script/tool simply to control the UI. A separate script would only increase confusion and add to the overall complexity.

By creating the UI as a module/package within src/, we keep things simple. This method also allows the UI code to directly access variables and modules in use by TRD.

As little as 1 line of code would be added to main.py to launch the http server, if requested by user. All the remaining code would be contained inside src/webui/ so this keeps TRD 99% the way it currently is.

[habanoz]

@utdrmac

Let's first decide on the set of features first. We can continue our discussion on the design later.

I imagine a web-based GUI. Users would be able to remotely connect to the GUI and control/monitor TRD.

• Creating the first configuration file
• Updating config file and restarting TRD
• Adding or removing service definitions
• Making on-demand payouts (Mod 2,3,4)
• Remote monitoring
• I consider report viewing low priority or unnecessary due to existing public tooling. e.g. bakingbad, tzkt.

Why such a GUI would be useful?

1- Some users prefer CLI while some just hate it. They prefer GUI to control the applications. Such a GUI would improve the user experience a lot. 2- Some users keep their setup hard to reach for security. e.g. uses VPN. Using the HTTP-based GUI, users would be able to control/monitor TRD easily without having to access their system using any PC or Mobile device.

[utdrmac]

My purpose for creating/adding a GUI is to improve the overall user experience and simplify for the non-technical (ie: hate CLI). I don't see the need for the GUI to "add or remove service definitions" as this would be required for the gui in the first place.

Imagine a new user: 1. clone TRD repo, 2. add TRD to systemctl with little to no parameters, 3. start the service, 4. Log into GUI, configure everything via GUI. No need to ever touch CLI again.

I consider report viewing low priority

:) I consider this one of the highest priorities. BB does not provide baker reports. BB only provides individual reports for each individual delegate address. yes, tzstats provides a pretty good cycle report for payouts. but it's hard to find.

My top features of a UI:

• create/update config
• viewing cycle/payout status
• view errors
• view reports

[habanoz]

I don't see the need for the GUI to "add or remove service definitions" as this would be required for the gui in the first place.

You are right. One service definition is enough. Either GUI or TRD service definition should suffice.

Imagine a new user: 1. clone TRD repo, 2. add TRD to systemctl with little to no parameters, 3. start the service, 4. Log into GUI, configure everything via GUI. No need to ever touch CLI again.

I image the same.

:) I consider this one of the highest priorities.

Why do you think reports have a high priority while it is currently possible to view report files with any spreadsheet application? Report files are accessible via email and can be viewed with integrated spreadsheet applications e.g. google docs with no effort. I think report viewing is an already solved problem.

I imagine a GUI like a glove around TRD. With no modifications to TRD, a glove-like GUI can be created. I believe it is about taste. I prefer simple components coordinating smoothly rather than building one complex component. I believe it is easier to maintain simple components.

I do not have strong opinions however, we may select one of the following options. May comments are certainly biased so you are welcome to provide your own comments:

• GUI integrated to TRD. Enabled via CLI options. TRD is always up. Only service mode is supported. Other modes also can be supported however trd internals needs to change and the final shape of the CLI interface should be discussed.

• GUI as a separate component, always accessible even when TRD is not running. The GUI creates an internal TRD instance with user parameters and allows monitoring. This approach requires little to no modifications to the current TRD.

Regards

[utdrmac]

Why do you think reports have a high priority while it is currently possible to view report files with any spreadsheet application?

I don't have a spreadsheet application. Google sheets, sure. But that requires that I scp the CSV to my desktop, then open drive, then open sheets, then import csv. It is time-consuming. Or, a GUI would be 1-2 clicks and there's my data, all organized by cycle, ready for me to view. No need to download and import every cycle.

Report files are accessible via email and can be viewed with integrated spreadsheet applications e.g. google docs with no effort.

I disagree with "no effort". Google sheets is a pain.

are welcome to provide your own comments

GUI as a separate component does not follow standards established by the linux command-line community. I cannot find any examples where a piece of software contains separated GUI and core code. Do you know of one that does this?

trd internals needs to change

I disagree here. I do not believe that TRD core will need to change by more 10-15 lines. The bulk of the addition would be the GUI, all located inside src/webui/. The goal is to add the GUI while making the smallest amount of changes to the core code.

Just to make this clear, my goal is not to rewrite everything. I want the least amount of changes possible. Adding the GUI will be very simple; a python SimpleHTTPServer, serving mostly static content with some AJAX JS, accessing functions which simply read data and calling existing functions from different aspects within TRD.

a glove-like GUI can be created

It is quite interesting how different our opinions are. I personally feel that a GUI-wrapper around TRD would require far more changes and be much more complex to maintain than having a module within TRD. I've witnessed countless companies moving away from the "microservices" model back to the traditional design because having 100's of simple components all trying to talk to each other in a coordinated fashion never worked out correctly.

[habanoz]

Openin attached Csv files in Google docs is very easy.

I accept your other arguments. Integrated GUI option looks wiser.