Request flux module load rank option #94
Labels
Comments
|
Agreed this is needed. I can add this sooner rather than wait for the flux-module/modctl rewrite. |
garlick
added a commit
to garlick/flux-core
that referenced
this issue
Dec 17, 2014
Redesigned modctl can operate on a hierarchy of dynamically loaded modules (e.g. comms modules, modules that load modules, etc). In addition the new modctl: Fixes flux-framework#57 flux-module list works around lack of sync with usleep Fixes flux-framework#56 flux-module cannot unload a module it did not load Fixes flux-framework#94 Request flux module load rank option modctl speaks RFC 5 to services that implement module extensions. It implements an "mrpc" based protocol that executes module operations in parallel on a user-specified nodeset. The modctl "API" is no longer exported via libflux-core and is kept private between modctl and flux-module. The use of mrpc greatly simplifies the design compared to the previous modctl. However, the new design has following caveats: - does not yet implement scalable .so loading through the KVS - there is no "smart" data reduction of RFC 5 responses, except what libmrpc achieves by KVS object squashing - some scenarios exist where modctl or the flux-module may hang in a kvs_fence(), e.g. node failure or flux-module abort at just he wrong place Some of these scalability and resiliency issues can be solved more generally through changes to mrpc. This is likey preferable to building a more complex, standalone modctl system with these characteristics.
grondo
pushed a commit
to grondo/flux-core
that referenced
this issue
Dec 12, 2019
Add NEWS entry for flux-security v0.3.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I would like the ability to specify the rank(s) on which to load a module. Eg.,
flux module load --rank=0 sched
The text was updated successfully, but these errors were encountered: