Thinking about this some more, I'm seeing the contours of something general (related to #517 actually):
there is a clusters table and sonalyze clusters queries this
there is a sysinfo table and sonalyze nodes queries this (can't use sysinfo as the verb at the moment b/c already taken for old sysinfo ingest point, we can fix this over time)
there is config table and sonalyze config queries this
there is an sacct table and sonalyze sacct queries this (already implemented)
there is a sample table and sonalyze parse queries this (probably add sample as alias) (already implemented)
Then there are jobs, load, uptime, top, profile, metadata. These are built-in aggregators that currently work only on Sonar + config data but could incorporate Slurm data and sysinfo data - something to consider over time. But for the time being we just leave them alone and maybe document them slightly better.
See https://github.com/NAICNO/Jobanalyzer/issues/604#issuecomment-2363437307. For the time being we just need something basic. Even
clustersis optional, really, but it's clearly a missing piece of the infrastructure.Thinking about this some more, I'm seeing the contours of something general (related to #517 actually):
clusterstable andsonalyze clustersqueries thissysinfotable andsonalyze nodesqueries this (can't usesysinfoas the verb at the moment b/c already taken for old sysinfo ingest point, we can fix this over time)configtable andsonalyze configqueries thissaccttable andsonalyze sacctqueries this (already implemented)sampletable andsonalyze parsequeries this (probably addsampleas alias) (already implemented)Then there are
jobs,load,uptime,top,profile,metadata. These are built-in aggregators that currently work only on Sonar + config data but could incorporate Slurm data and sysinfo data - something to consider over time. But for the time being we just leave them alone and maybe document them slightly better.