GlancesWebList takes web_x_ssl_verify through config.get_value(), which
returns the raw string, and hands it to requests.head(verify=...).
Requests reads a string verify as the path to a CA bundle, so the value
from the configuration file is looked up as a file name:
verify='false' -> OSError: Could not find a suitable TLS CA
verify='true' -> OSError: ... invalid path: true
verify=False / verify=True -> the request is actually made
ThreadScanner._web_scan catches everything and sets status='Error', so the
URL sits permanently red in the curses view and the WebUI, with only a
debug-level log line to explain it. Setting the key to true, which is what
a user does to turn verification back on explicitly, breaks the scan the
same way as false.
Read it with config.get_bool_value(), the helper the network and diskio
plugins already use for their switches, and keep a non-boolean value as a
string: a path to a CA bundle is a valid value for requests' verify, and
that is the one form that worked before.
The key was undocumented, which is probably how this survived; document it
next to the other web_x_ options in conf/glances.conf and docs/aoa/ports.rst.
The VM table asks for a decoration on four columns:
self.get_views(item=vm['name'], key='cpu_count', option='decoration')
self.get_views(item=vm['name'], key='cpu_time_rate_per_sec', ...)
self.get_views(item=vm['name'], key='memory_usage', ...)
self.get_views(item=vm['name'], key='load_1min', ...)
Nothing ever set one. No vms field declares `alert` or `log`, so the base
`_build_field_decoration` returns 'DEFAULT' for all of them, and
`update_views` only computed `show_engine_name`. Every one of those four
reads has always come back 'DEFAULT', which makes the VM table the one
table that never changes colour -- the sibling containers plugin has done
this since it was written.
Three of the four get thresholds, with the per-VM override and DEFAULT
fallback containers already uses. `cpu_count` keeps its read and no
colour: a core count is not a threshold.
Decorations are written onto the views the base already built rather than
replacing them, so `optional` and `hidden` survive -- containers replaces
the whole per-item view, which is why its curses code reads nested 'cpu'
and 'mem' keys instead of field names.
Thresholds are commented out in the shipped conf, so the table stays
exactly as it is until someone opts in.
Verified with tests/test_vms_decorations.py (9 passed) and by reverting
each claim: measuring memory against a fixed maximum instead of the VM's
own memory_total fails 4 tests, dropping the per-VM override fails 1.
A `value is None` guard was written first and removed: `get_alert` already
answers DEFAULT for a missing value, because the percentage it computes
raises TypeError and is caught, so no test could tell the guard from its
absence. A test pins that behaviour instead.
update_views() replaced the base class's per-field views with a dict naming
only load, freq and mem, so views[npu_id]['temperature'] did not exist. Both
readers then fell back to no style: msg_curse's get_views() returns 'DEFAULT'
for a missing key, and the WebUI's getDecoration returns undefined. An Intel
NPU -- the one driver that reports the reading -- was printed plain at any
temperature.
Adds the key and the alert, mirroring the GPU plugin, which has had the same
three alerts (proc/mem/temperature) all along. A card whose driver leaves the
reading None (AMD, Rockchip) keeps a view with no decoration rather than being
alerted on nothing.
conf/glances.conf gains the matching [npu] temperature thresholds, using the
same 60/70/80 ladder as [gpu]: without limits get_alert() returns DEFAULT, so
the code half alone would change nothing.
- Add [mpp] section to conf/glances.conf with disable=True
- Add docs/aoa/mpp.rst documentation page and index entry
- Add unit test test_026_mpp with Rockchip MPP test fixtures
datrixlab