Hi João.

I think we managed to fix the issue.  Let me explain how.

Qluman was reporting an error:

Traceback ...:

...

File "/usr/lib/python3/dist-packages/qluman-14/client/qt/TreeWidget.py", line 538, in compute_gpu_details data["type"].index(gpu) TypeError: must be str, not NoneType

We asked ChatGPT for help and its reply seemed reasonable (check the chat).  In fact, I had been messing around with slurm gres configuration to fix a minor issue on a node with 2 different types of gpus.  At some point I may have cleared the config, and when I tried to create a new one, I could no longer do that.

How we fixed:

- We used mariadb to inspect the database.  We found that some records in SlurmGresGroups table had type=NULL.

- We updated those records to have the expected GPU types.

- Restarted the `qluman-server` service on the head node.

- Almost immediately Qluman started showing the nodes on the Enclosure view.  We could also see the updated information on the slurm gres config window.

- We checked the "Write files" window, confirmed the changes met our expectations, and committed them.

So, I cannot remember the exact details of the situatiom, but Qluman allowed me to do a change that led to an invalid state, which I could no longer revert.

Regards,

João Rodrigues

ChatGPT is scarrily accurate diagnosing the problem and how to fix it without the GUI. If it works now this is great but editing the underlying database entries is dangerous as there are many assumptions build into the software how those entries relate to each other. And if they get out of sync you get problems like the initial one. So always do this with caution and ALWAYS only after making a backup.

A simpler fix would probably have been to remove the GPU entries in the GRES group if the type can't be set properly.

---

From: João Rodrigues via Qlustar General <qlustar-general@qlustar.org>
Sent: Sunday, July 19, 2026 16:14
To: qlustar-general@qlustar.org
Subject: [Qlustar General] Stange Qluman quirks

 

CUIDADO: Email de um sistema externo. Cuidado com links, anexos e pedidos de dados/senhas. CAUTION: Email from an external system. Be careful with links, attachments, and requests for data/passwords.

I recently upgraded our cluster from Qlustar 13 to 14.  Since yesterday I noticed strange behaviors in Qluman GUI:
1. When using Hardware or GPU wizards, no nodes are shown in the "selected" list, even though I selected one in the "Enclosure view" window.
2. On the "Slurm Config" window, when creating a new "Gres group", I select a Type of GPU, but when pressing enter or tab, it is cleared.

3. Today, the "Enclosure view" is completely blank.

 
Since I noticed these problems yesterday, I have avoided writing changes to files.

What could be causing this?

João Rodrigues

_______________________________________________
Qlustar General mailing list -- qlustar-general@qlustar.org
To unsubscribe send an email to qlustar-general-leave@qlustar.org

Regarding 1: Given that the GRES data was broken the GPU wizard probably run into the same exception as the EnclosureView. They use some of the same functions to parse the GPU infos for nodes. So the wizard not seeing nodes would be excepted for this kind of error.

Regarding 3: If the data inconsistency was introduced while then client was open then the EnclosureView retains all the entries it already has. It just can't update the broken entries anymore. But when you restart all the entries are processed in one group to build the initial tree and the exception caused by the bad data will break that leaving an empty tree. So again, very much expected I'm sorry to say. I'm working on catching this case so the Enclosure View (and GPU wizard) will still work despite the unexpected GRES entry.

Now to the main Problem. Item 2. This is very much unexpected.

Do you remember any exception or displayed errors from qluman-qt at that point? The selected string should simply have been saved in the Database but it seems somehow qlumand stored NULL instead and when the update is then pushed back out to GUI clients the client updates the display and shows an empty field. The question is: Why did it store NULL instead of the selected string.

Could you please also check /var/log/qluman/qlumand.log around the time you create the GRES group to see if the server had any exceptions causing the bad data to be stored in the DB? Maybe we can find the initial cause for this problem to prevent other users to run into the same issue in the future.

Regards,

Goswin von Brederlow