Mark Grondona

> I guess I was just thinking probably the main reasons to resubmit were things in the environment that went wrong, like a bad node, and that running the same...

To resubmit a job it would have to be assigned a new jobid, so this implies (at least for now) that the job be resubmitted to the job-ingest module. (I...

it was originally `modprobe.toml`. Would that be preferable, since it is how you configure the modprobe tool?

Oh yeah! I didn't think of that and alternatives style priority is a great idea.

Ok, this is still a WIP, but I've made the use of `flux modprobe` in `rc1` and `rc3` opt-in (set `FLUX_RC_USE_MODPROBE` in the environment) to allow framework projects like flux-sched...

Also forgot to mention that this now has support for a module `priority` value. Module alternatives are sorted first by `priority` then by load order, so the last module configured...

I've updated this PR with a few other modifications to support better integration with other framework projects like fluxion: - new env var `FLUX_MODPROBE_DISABLE` supports a comma-separated list of modules...

Unfortunately, there still isn't any documentation and I'm working through one last small feature: sysadmins may want enable something like the feasibility service on login nodes on a case-by-case basis,...

Oh, one other small issue here that could use someone's opinion: When using `flux modprobe`, the current approach just sticks `flux modprobe rc1/3` into `rc1` and `rc3`, and keeps the...

I'll just note that the expectation is that there won't be a need for the `rc1.d` and `rc3.d` shell scripts after moving to the modprobe implementation (extra modules are defined...