PVE Temp mod version 2.0

[Meliox]

• Create a common background collector for handling graphics units, UPS, sensors
• Support for Intel devices through intel_gpu_top (fixes Add support for Intel IGPU #69)
• The collector must be expanable to AMD and NVIDIA (Working implementation in Add NVIDIA GPU GUI mod #151 + fixes Add support for NVIDIA GPU #14)
• Display relevant information in gui
• Show visual names for hdd, ssd, nvme (fixes Show HDD and SSD visual names in storage view #91)
• Show visual name for cpu
• Rework install script for extended code segments
• Using background workers, gui is not blocked and should not cause I/O delay (fixes Change how often information is refreshed #63 and fixes Summary page updates irregularly #98). Gui refreshed every 1 second - cannot be changed. Data pull interval for background workers can be adjusted. Default 1000 ms
• ability to start as a service to collect historic data

Example:

Todo:

• fix broken gpu stats

[Meliox]

@eremem

I see a couple of options to make the installation of this possible.

1. download dependicies during installation (perl + js)
2. make a git workflow to compile everything into on script
3. git clone a directory with all files and then install

(the js will be around 800 lines)

Other views and argument against/for?

[eremem]

@Meliox Chosing 1. would effectively eliminate 3... However, I wouldn't necessarily like the idea of needing multiple files for the installation. Could the perl & js files you mention be called somehow from the Proxmox UI code or would they have to be integrated by the installer as it is in the current mainline version?
Generally if it were necessary to split into multiple files though, then some kind of build process with compilation (as in 2.) might be a viable option. In this case, I think, I'd rather implement a build process and let it run to compile a release version, which in turn would be a single bash installer script used to modify the user's Proxmox installation.
Frankly speaking, since I haven't been actively involved in the development for many months, I'm not sure if the effort would be justified. I wonder if the increase in code size could make the current workflow difficult to maintain. Or is the reason for your question an attempt at general improvement/optimization?

[Meliox]

@eremem Improvement wise... This is brand new and would allows expansion to all gpu data as well as not block the ui when the commands is called. Everything is running in separate threads the background. It also enhances the information available. The is done in the separate perl library. The ui will call "api" (the perl script) which returns data from memory. It also follows the normal proxmox implementation of modulea. (I have not all code parts yet to this branch, sorry).

Whether just including a library can be done for the js part I could explore.

The code size is much larger, but relative easy to maintain. The code layout allows it to be easily expanded (e.g. background service to collect gpu data over time and show utilisation graphs like cpu and memory).

If the perl and js are kept separately/merged in a build process, then that would also simplify the bash script itself. And, that is my question, e.g. how to handle the install process to ensure it is easy to use. In the source code I think the files should be separated, but from a user perspective the multiple files is not optimal. Though quite many product do use git clone + install script though. Maybe I am overthinking it...

Finally, I plan to make this a version 2 and leave the existing as-is.

[eremem]

@Meliox I don't think you are overthinking. The installation should be as easy as possible.

To hide the multiple files and to allow installing them w/o the need to compile everything in the current installer script seems to be the case for a debian package. It could be built e.g. using github actions (at least according to a quick google search this should be possible), contain a proper directory structure and be made available as versioned releases for download, with "latest" pointing to the... latest package version. Instead of downloading and running the bash installer script, users would download the latest package and install it with dpkg (in the future a dedicated repository could be a nice touch - I found no hosting function for debian repositories on github though:/). As a bonus the root privileges would be ensured during the installation.

Now, the perl lib and any other "loose" files would be installed from the package on the user's system (saved in their respective directories), together with the bash installer script. The latter would be triggered at the end of the installation too.
Using a debian package would also allow for installing the hooks you mentioned in #154 (the user could be asked if they want them activated) and rerunning the bash installer script by the hooks. The bash installer script could also be extended to ask the user if the settings file should be created with their answers (I think in this case the settings file should be saved in /etc), so that applying the mod by the hooks would require no user's attention (or only minimal for the questions not answered yet, e.g. for new features).

This approach would allow for an easy and automated installation with a minimal effort on the user's side. What do you think? Does this make sense?