Question: why jobspec -> tasks?

[vsoch]

I'm doing some thinking about the Jobspec, and have a simple question. Why is the section (for what I'd call jobs) labeled tasks? https://flux-framework.readthedocs.io/projects/flux-rfc/en/latest/spec_25.html#tasks. E.g., if I look at this jobspec:

    version: 1
    resources:
      - type: node
        count: 4
        with:
          - type: slot
            count: 1
            label: myslot
            with:
              - type: core
                count: 1
    tasks:
      - command: [ "hostname" ]
        slot: myslot
        count:
          total: 5
    attributes:
      system:
        duration: 3600.
        cwd: "/home/flux"
        environment:
          HOME: "/home/flux"

This would be akin to (without the details) running:

$ flux submit hostname
$ flux submit hostname
$ flux submit hostname
$ flux submit hostname
$ flux submit hostname

Right? Would the above be considered 5 separate submits or a batch job? And then add on the bells and whistles for the cwd, environment variables (which I guess have to be the same for each of the 5 submits?) I'm wondering also because I think it would be good if the spec file can support submit with batch and just submit, and I want to understand how it works to grep that.

Intuitively, when I see a yaml file like this for flux, I would look for "jobs" to coincide with a section of commands for my jobs. Resources makes sense alongside that, and attributes seems kind of random (and it seems not ideal that they have to be globally applied to all jobs, but maybe I just don't understand the spec well enough yet).

Is there a big dump of jobspec files somewhere I can look at? E.g., more complex ones? Eventually after we are able to support:

$ flux submit -f jobspec.yaml

We can have an entire repository with these files just showing specific examples. And if we can do this well, I can get this same spec to be what plugs in to flux-cloud so I don't need to have two different specs, and a user doesn't need to write two things to run on HPC vs. the Flux Operator (via flux-cloud).

Thanks for answering my bad questions!

[grondo]

This would be akin to (without the details) running:

No. Jobspec describes a "job" (sometimes also called a "program" in docs), which is made up of one ore more "tasks". Each of your flux submit examples is a separate job, with its own jobspec, running a single task.

You may want to read RFC 14/Canonical Job Specification, which also has many examples.

[vsoch]

Gotcha - we will stick with tasks. But are there more complex examples? I think I've looked through the main ones in the docs. I want to know, for example, how someone would submit a jobspec for a complex workflow. Also, did I interpret the tasks correctly? I think what I'm missing is a command example that matches to each jobspec (e.g., is it batch? submit? both? something else?)

[grondo]

I want to know, for example, how someone would submit a jobspec for a complex workflow

Jobspec describes a single job, not a workflow. I think what you are talking about is something at a higher level that does not (yet) exist. Currently a complex workflow would be defined by submitting a batch job with the workflow initialized and submitted in the batch script.

Also, did I interpret the tasks correctly? I think what I'm missing is a command example that matches to each jobspec (e.g., is it batch? submit? both? something else?)

The specification was written before there were any Flux commands. However, there are command examples for other resource manager systems in the doc.

If you just want to see examples, all of the Flux submission commands take a --dry-run option which will spit the jobspec out on stdout. So you can have an example of anything you can come up with ;-)

[garlick]

Was going to suggest that too.

Hints: add --env=-* to empty the attributes.system.environment dict, and pipe it to jq for pretty printing.