Flux-core: wreck parity: need support for job names

[SteVwonder]

Per coffee time discussion today with @frankd412: we need a way to name jobs in the new exec system. Needs a location in the jobspec and probably ultimately the KVS so that users can querying against the names.

[chu11]

was beginning to think about this so that we could add job name into the job-info module and eventual job listing tools.

IIRC, we talked about putting the job name into the jobspec, but I'm not sure where. I would assume under attributes? Then of course need option in flux mini, etc. to set.

[garlick]

In a quick scan I didn't spot anything about job names in RFC 14 or RFC 25. Maybe asking users to do

$ flux mini run --setattr=user.job-name=myjob ...

would be a good start?

[chu11]

Yeah, it's presently not in the jobspec. Was wondering if it should be added there as a special attribute.

$ flux mini run --setattr=user.job-name=myjob ...

Ahh, so you're thinking under 'user'. I initially thought we shouldn't:, per RFC14

Attributes in the user dictionary are unrestricted, and may be used as the application demands. Flux may provide additional tools that can identify jobs based on user attributes.

I thought of the user attributes as arbitrary, but the job-name is sort of special?

[chu11]

Re-reading the initial comment:

ultimately the KVS so that users can querying against the names.

@SteVwonder do you mean looking up a job via name instead of job-id? Perhaps I'm unfamiliar with how some things were done in wreck.

[grondo]

In wreck, a job name was displayed in flux wreck ls if available, o/w argv[0] of the cmdline was used.

grondo@fluke108:~/git/flux-core.git$ flux submit --name=foo sleep 120
submit: Submitted jobid 1
grondo@fluke108:~/git/flux-core.git$ flux submit --name=bar sleep 120
submit: Submitted jobid 2
grondo@fluke108:~/git/flux-core.git$ flux submit sleep 120
submit: Submitted jobid 3
grondo@fluke108:~/git/flux-core.git$ flux wreck ls
    ID NTASKS STATE                    START      RUNTIME    RANKS COMMAND/NAME
     3      1 running    2019-11-19T09:53:13       3.459s        0 sleep
     2      1 running    2019-11-19T09:53:07       9.653s        0 bar
     1      1 running    2019-11-19T09:53:03      14.315s        0 foo

This is the most basic requirement for job names.

Ultimately, our queue listing tool should support filtering based on arbitrary attributes of jobs, of which perhaps job-name is just one supported attribute.

[garlick]

Mark and I were just chatting, and I think we agreed that probably this should go in the system attribute section, like you suggested above.

[grondo]

We also discussed (remembered an old idea) that maybe we should specify a reserved system attribute key which is a dictionary of keys on which jobs can be filtered, and from which a porcelain job listing tool can print valuesm e.g. perhaps attributes.system.job (arbitrary choice).

So system.job.name would be the de facto "job name", but in the future users could use this dictionary as a place to store other metatdata about a job, e.g. tags that identify the type of job, a parameters string to identify how the application was run, etc.