-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support power control to same target twice #205
Comments
We do have aliases so blade1477 and blade1477 could just map to the same blade name. I thought the admins told us that they had other ways to do this sort of mapping and that we didn't need to provide support for such stuff in powerman? |
That was my first thought. But behind the scenes I didn't know the fallout. For example, if someone did
I think they do, but this is more of a convenience. vs comments @watson6282 |
FWIW
Two hosts named, one command issued. |
as a quick test
with the exception that
I was initially a little surprised it works.
each
The devil is in the details of course. I'm not sure what fallout there could be by calling But at a very high level ... I think this just works. @watson6282 shall I invest more effort in this? Last we chatted it was an idea. Not sure if you really want to pursue. |
I did a test implementation of this last night to mess with, and it works and seems to solve the problem. Is it feasible to implement host ranges in aliases? E.g.:
|
Haven't looked at the code but it presumably should be doable, and I suppose it's a necessity as listing a bajillion alias lines in the powerman.conf is probably a non-starter. Before I look into that @garlick, do you have a opinion on the calling of |
Except the main use case for aliases is to support mapping one name to multiple plugs. So with a list on the LHS it is ambiguous whether it should expand to each name on the LHS mapping to all the names on the RHS or just one. |
do you think a new config command would be preferred? off the top of my head
|
My thinking was basically "alias with one host as the first argument=one to many, alias with multiple hosts as first argument=one to one." Of course there are weird cases like what do you do if I put in It's not the end of the world if we just end up with num_compute_node lines in the powerman.conf assuming that won't make it barf. A new command would also totally make sense as Al just posted. Certainly avoids ambiguity and directly implicates the one-to-one mapping. In my perfect world I'd love support for things like "all the odd numbers in this hostlist get aliased to this list of nodes" to avoid the big comma-separated lists above, but that's kind of an extreme niche. |
These configs are often script generated on big clusters anyway, so my inclination is that the shorthand command isn't really necessary. Partly it's because we need Al working on high priority Flux work. So perhaps we could open a separate issue and think about whether we want I longer term? |
User asked for an interesting support. In the el cap environment, two compute nodes are attached to one blade. It can be inconvenient to map a compute node to its blade (eg node1478 maps to blade???)
Idea was map two fictitious node names to same blade, ie blade1477 and blade1478 both power control the same blade.
The primary issue is how to deal with user submitting both nodes at same time to power control (i.e. `pm -0 blade1477,blade1478).
Pondering a bit, I think this may be doable if
arglist_find()
could return multiple args (i.e. a single power result could update multiple args). The ranged scripts could handle by callinghostlist_uniq()
before calling the power control target.But I bet there’s stuff I’m not thinking about right now.
Edit: minimally, what errors could occur on non-ranged scripts. But I suppose we aren't checking that multiple "targets" don't already point to the same plug. So perhaps it doesn't matter?
The text was updated successfully, but these errors were encountered: