QOI status table

[pierrepebay]

In the following table, QOI that are directly supported have green checks (✅).

All other QOI (e.g. shared_block_id) are supported via the attributes or user_defined fields of the JSON.

List of all QOIs supported by LBAF	Implemented in vt-tv ?	Can be easily implemented in vt-tv ?
load (O)	✅	✅
load (R)	✅	✅
id (O)	✅	✅
id (R)	✅	✅
size	...	...
received_volume (O)	✅	✅
received_volume (R)	✅	✅
sent_volume (O)	✅	✅
sent_volume (R)	✅	✅
work (R)	...	...
shared_block_ids (R)	...	...
number_of_shared_blocks (R)	...	...
number_of_homed_blocks (R)	...	...
number_of_uprooted_blocks (R)	...	...
homed_blocks_ratio (R)	...	...
shared_memory (R)	...	...
number_of_objects (R)	✅	✅
object_ids (R)	✅	✅
migratable_load (R)	✅	✅
sentinel_load (R)	✅	✅
max_object_level_memory (R)	...	...
max_memory_usage (R)	...	...
overhead (O)	...	...
rank_id (O)	✅	✅
shared_block_id (O)	...	...

[ppebay]

@cwschilly prior to vt 1.5 (and vt-tv) release, please review and update as necessary, thanks

[ppebay]

@cwschilly from what I was able to test, the table appears up-to-date.

@cwschilly @tlamonthezie why are QOIs such as, e.g., shared_block_ids, not easy to implement? I think (please confirm @lifflander) it important to be able to visualize/report on such variables, for instance when analyzing cluster-based LB.

[cwschilly]

@ppebay I think that "not easy to implement" just means that there isn't a dedicated "getSharedID" function for an object. For any QOI other than the core "easy to implement" options (load, id, sent/recv volume, etc.) the user would pass the information as an attribute of the object, and then we would use the generalized attribute "getters" (implemented with lambda functions) to access it.

While the treatment behind the scenes differs, the user experience is the same as LBAF--you specify shared_id in the object's attributes (or user_defined) field, and then pass shared_id as the object QOI in the input yaml. vt-tv is able to visualize that QOI.