Skip to content

conf: add mapall upcall to xCAT group bindings#624

Closed
thiell wants to merge 1 commit into
clustershell:masterfrom
thiell:mapall-xcat
Closed

conf: add mapall upcall to xCAT group bindings#624
thiell wants to merge 1 commit into
clustershell:masterfrom
thiell:mapall-xcat

Conversation

@thiell

@thiell thiell commented Jun 12, 2026

Copy link
Copy Markdown
Collaborator

Adopt the new mapall upcall in the xCAT example group bindings: one lsdef -t group -i members call replaces one lsdef call per group, for both static and dynamic groups. Group names containing : are skipped and remain resolvable through map.

doc/sphinx/config.rst updated to match.

Signed-off-by: Stephane Thiell <sthiell@stanford.edu>
@thiell thiell added this to the 1.10 milestone Jun 12, 2026
@thiell thiell requested a review from kcgthb June 12, 2026 21:49

@kcgthb kcgthb left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I'm not really sure about this one. 🤔

mapall works great when the cost of resolving all groups is the same, or close, to the cost of resoling one group.

But that's not the case for xCAT. There could be a number of xCAT groups that have little reason to ever be invoked via clush, and resolving all members of groups (especially dynamic groups) could be pretty costly on large systems with many groups. And in that case, resolving all groups knowing that the vast majority will never be used, doesn't seem like a very significant optimization.

There's a cluster I know where resolving all members of every single group takes much more time than cache_time :D

# time lsdef -t group -i members >/dev/null

real    3m32.317s
user    0m0.327s
sys     0m0.079s

This is largely due to the fact that resolving members of a dynamic group is an expensive SQL query in the xCAT DB (the membership is... dynamic, not defined statically) and those SQL queries are pretty much serialized, I believe.

So on a system with many dynamic groups (like this:

# lsdef -c -t group -i grouptype | awk -F: '{print $NF}' | sort | uniq -c
     31  grouptype=
    272  grouptype=dynamic

I'm not sure that a mapall call could be a real improvement, pretty much the opposite. :\

@degremont

Copy link
Copy Markdown
Collaborator

That's exactly the kind of data we are looking for. mapall is designed for use case where the request to get all groups is similar to get few groups (1-3). If the time is especially more expensive, no need to add it.

Do you have other scenarios, where the config is simpler? What is the perf difference in that situation?

Let's drop it. It could always be added later if that useful.

@thiell

thiell commented Jun 15, 2026

Copy link
Copy Markdown
Collaborator Author

Thanks for the feedback! Agreed, that doesn't make sense to use mapall for xCAT in that case.

@thiell thiell closed this Jun 17, 2026
@thiell thiell removed this from the 1.10 milestone Jun 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants