Idea for RFC to collect small improvements

[mwiebe]

Since publishing the Open Job Description specification, we've run into many potential small improvements that would make writing job templates easier or increase their expressiveness. We'd like to write an RFC that rolls many of these into one extension like FEATURE_BUNDLE_1.

Two questions for feedback:

1. What should the extension be called? Is FEATURE_BUNDLE_1 good?
2. What additional small fixes would you like to see?

Here are the small features we've identified so far (adding to the list based on discussions):

1. More format strings (Timeouts as Format Strings #69).
   1. The timeout property in <Action>.
   2. The min and max properties in <AmountRequirement>
   3. The notifyPeriodInSeconds property in <CancelationMethodNotifyThenTerminate>
2. Generalize the onRun action property in <StepActions> to be either a single <Action> as defined currently, or be a list of <Action>s. While in Wiki: Multiple tasks within a single job, HOW? #68, we found an alternative way, by allowing a list of sequential actions in the onRun of a task, each command can get separate timeout and cancelation behavior.
3. Ability to control EOLs in embedded files. Currently files are always created for the OS family (\n on POSIX, \r\n on WINDOWS). A new per-embedded-file attribute endOfLine: [AUTO|LF|CRLF] (default AUTO) would give this control.
4. Syntax sugar for script interpreters commonly used in templates in <Action> objects. These script intepreters currently include bash, python, cmd, powershell, and node (see Support nodejs scripts? #37). This will make it easier to write simple job templates without having to copy an example or refer to the spec, and remove some commonly repeated boilerplate to focus the template on the important commands being run.
   1. For bash

      actions:
          onRun:
              # the 'command' property becomes optional, and one of 'command',
              # 'bash', 'python', 'cmd', or 'powershell' must be provided.
              bash:
                  # bash code here
      
      ### syntax sugar equivalent to:
      
      actions:
          onRun:
              command: bash
              args: ["{{Task.File.<implicitly generated file>}}"]
      embeddedFiles:
          - name: <implicitly generated file>
            filename: "<something autogenerated>.sh"
            type: TEXT
            data:
                # bash code here
      

   2. For python, like bash but substitute python. File extensions '.py'.
   3. For cmd, like bash but substitute cmd and args are ["/C", "{{Task.File.<implicitly generated file>}}"]. File extension '.bat'.
   4. For powershell, like bash but substitute powershell and args are ["-File", "{{Task.File.<implicitly generated file>}}"] File extension '.ps1'.
   5. For node, like bash but substitute node. File extension '.js'.
5. Increase the maximum lengths of names used in the spec. Particularly when a template is generated programmatically, it's natural to concatenate identifiers from the input to get a unique name. The current length limits prevent that from working naturally. Identifier names can similarly be generated by concatenating identifiers, so we likely want to treat them similarly.
   1. JobName (currently 128), StepName (currently 64), EnvironmentName (currently 64). Increase these all to 512.
   2. AmountCapabilityName (currently 100). Leave as is, open to discussions.
   3. FileName (Currently 64) Increase to 256.
   4. Identifier (Currently 64) Increase to 512.

[leongdl]

Question - would something like job metadata fit into "Small improvements" or warrant its own RFC?

[mwiebe]

My first inclination would be its own RFC, because of how broad that scope is. What would the change to the spec look like? What new functionality would it allow that job parameters don't already cover? The syntax sugar for script interpreters is probably the upper limit for the kind of thing that would fit.

[epmog]

Would increasing the max number of characters allowed for <...>Name properties be included here?

Specifically increase the following to something like 256 or 1024:

1. JobName (currently 128)
2. StepName (currently 64)

Others to maybe rethink but I haven't heard any complaints about:

1. EnvironmentName - currently 64)
2. AmountCapabilityName - might be fine at 100
3. FileName - is a little small at 64, but might be fine.

[mwiebe]

Yes, these changes would fit well.

[mwiebe]

I've added this one to the list in the description, thanks.

[epmog]

Proposed values look reasonable to me, thanks!

[edwards-aws]

Discussion for point 2 moved to #97