replace flux-srun with flux mini run

[grondo]

During coffee conversation it was discovered that our flux "simple run" command flux srun shares a name with a moderately popular alternate resource manager.

To avoid confusing users and avoid any need, real or perceived, to keep the same options as this other srun, we agreed to rename our simple run interface to a unique name. Either something like flux sfrun (straight-forward run, simple flux run), or flux dsrun (duck soup run).

We could keep flux jobspec srun and add flux jobspec sfrun, thus breaking only users of flux srun for now.

[grondo]

Also mentioned by @SteVwonder, we should carefully review options we add to flux sfrun since our plan is to never change this interface, and we are freed from compatibility with srun. E.g. maybe instead of -n we use -t?

My inclination would be to keep -n since it has the same meaning in srun, mpiexec, orterun, etc. (Well, for mpiexec -np is typical usage and we definitely don't want to copy that.)

[garlick]

flux dsrun seems to be most favored at the moment.

How about "ratrun" (reusable archetypal tool for running?)

[SteVwonder]

@dongahn and I came up with urun for "micro-run", in the same vein as utorrent. It is simple, easy/quick to pronounce, and wouldn't require much explanation to confused users/tutorial attendees 😆 .

[SteVwonder]

Two more half-serious ideas from speaking with @garlick and @grondo

• rename flux srun to flux run and rename @trws's flux run to something else like flux warp
• rename flux srun to flux walk and keep flux run as flux run

[trws]

What's the motivation here? Stephen Herbein <[email protected]> writes:

…

Two more half-serious ideas from speaking with @garlick and @grondo - rename `flux srun` to `flux run` and rename @trws's `flux run` to something else like `flux warp` - rename `flux srun` to `flux walk` and keep `flux run` as `flux run` -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2379 (comment)

[chu11]

I get flux walk, but don't quite get flux warp? Just the best word you could come up with for "running really fast"?

[grondo]

Doesn't necessarily need to mean "running really fast" (jobs are guaranteed to run at the same speed) but run is a simple interface while warp is an advanced or power interface. (just the first word we threw out there.) Think "rebranding the run experience"

The idea is if we choose something like or equivalent to run then there are already 10,000 other variants out there that could potential "confuse" users.

[dongahn]

If we are looking for one letter run, I like
arun (a as in archetypal as @garlick used) or urun (as in micro-run).

I was surprised how many times users have asked about wreckrun during our turorial and user interactions. Personally I appreciate the humor there, but I am worried if end-users will take a command seriously.

Just $0.02.

[tpatki]

I think urun could read wrong if you don't know that the u stands for micro and haven't attended an in-person or video tutorial.

• rename flux srun to flux run and rename @trws's flux run to something else like flux warp

I like flux run (1) because it's simple, (2) you don't have to remember another preceding letter, and (3) you don't confuse with other resource managers such as aprun for cobalt or utorrent or srun or jsrun.

But flux warp is confusing from a user point of view (as in, it's unclear what it does at first glance to a new user). If it's just a faster version or advanced version, per @grondo's point, maybe we can use something simple such as flux htc or flux htcrun, for high-throughput-computing. Not sure if that reflects @trws's optimizations correctly, though.

[dongahn]

I think urun could read wrong if you don't know that the u stands for micro and haven't attended an in-person or video tutorial.

I see. You can also spell this out: microrun.

[garlick]

What's the motivation here?

I think @grondo captured it in the issue description:

During coffee conversation it was discovered that our flux "simple run" command flux srun shares a name with a moderately popular alternate resource manager.

To avoid confusing users and avoid any need, real or perceived, to keep the same options as this other srun, we agreed to rename our simple run interface to a unique name.
[snip]

Feel free to talk us down @trws.

[trws]

On Sep 21, 2019, at 11:01 AM, Jim Garlick <[email protected]<mailto:[email protected]>> wrote: What's the motivation here? I think @grondo<https://github.com/grondo> captured it in the issue description: During coffee conversation it was discovered that our flux "simple run" command flux srun shares a name with a moderately popular alternate resource manager. To avoid confusing users and avoid any need, real or perceived, to keep the same options as this other srun, we agreed to rename our simple run interface to a unique name. [snip] Feel free to talk us down @trws<https://github.com/trws>. I can see that, we joked about calling it `frun` for some years as I recall, so differentiating the srun command from srun makes sense to me. Even calling it slurm_run or simple_run or something wouldn’t be all that bad as it’s more explicit. The question I’m more getting to is which of the two interfaces do we expect to be the normal way to interact with flux? My understanding, which may be wrong, was that srun existed for the sole purpose of providing a simple update path from slurm, and was not intended to be capable of expressing the majority of either their or our interface, which makes me question the idea of calling it `run`. As a user looking at the CLI, I would expect `run` to be whatever command the developers intended me to use when running things in the common case.

[grondo]

As a user looking at the CLI, I would expect run to be whatever command the developers intended me to use when running things in the common case.

I agree @trws. The rename was just an idea thrown out during a coffee convo without any real thought -- more along the lines of redefining what people think of as "running" a job. I think it was kind of a failed idea and got us off track.

I may be off base here, but I'm coming around to the idea of "micro" interfaces for these commands (I personally find the substitution of u for mu in common practice to be slightly off-putting, though I realize that is just me and I'm actively working on it in therapy) We'll at least need a micro submit as well, so why not go with an idea that I think @SteVwonder already proposed and put all these pared-down-so-they-can-be-stable commands under one command like flux micro or flux mini, so you'd have flux micro run and flux micro submit or flux mini run and flux mini submit. (What I like about mini is that it implies "minimal" interfaces, which is really what this is all about.)

If we find we need another command down the road, it can be placed under flux mini as well, instead of populating the top-level command listing.

I also agree that the mini or micro prefix of these commands will rightly direct users that want maximum power to go with the non-minimal versions of commands. 😉

[garlick]

We probably need to implement this this week. Any objections to flux mini run / flux mini submit for the simple/stable interface and flux run / flux batch for the maxi versions?

[trws]

Seems fine, I vaguely prefer "submit" to "batch" as the latter has an association with "batch script" that makes me think it might require a script rather than a binary but it's a small enough issue I wouldn't fight it if others prefer batch. Jim Garlick <[email protected]> writes:

…

We probably need to implement this this week. Any objections to `flux mini run` / `flux mini submit` for the simple/stable interface and `flux run` / `flux batch` for the maxi versions? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2379 (comment)

[garlick]

Sorry I think I meant to type flux run / flux submit.

[dongahn]

mini is okay by me.

[grondo]

Can #2150 and #2370 be folded under this one issue?

[garlick]

Right let's close those now that they've been referenced here.

[garlick]

As a simple first step, I propose we replace flux-srun (the shell script) with flux mini run (python), basically duplicating code in flux jobpspec for jobspec generation and option parsing. The replacement command can call the python binding for flux_job_submit(), and then just exec flux job attach. Follow-on steps could be

• revise flux mini run options
• factor out a python module for jobspec v1 generation from flux-mini and flux-jobspec
• perform attach functionality native in python

We could leave flux srun in place for the moment until we're happy with flux mini run options, then convert tests and drop flux srun.

I can have a crack at this first step if no objections to this approach. @SteVwonder maybe you could look at the jobspec v1 generation module?

[garlick]

I think this is done, minus

factor out a python module for jobspec v1 generation from flux-mini and flux-jobspec

but that seems like cleanup that could come later.