Job reference step does not log step descriptions #1370

Closed
kincl opened this Issue Jul 31, 2015 · 14 comments

Projects

None yet
@kincl
kincl commented Jul 31, 2015

When I reference a job as a step and run the parent job, the output should show:

(step number). (step description)

Instead it always shows:

  1. (referenced job name)

Is this a bug?

@ahonor
Contributor
ahonor commented Aug 3, 2015

@kincl what is your rundeck version?

@pyther
pyther commented Aug 3, 2015

I've created a very simple example to illustrate this problem.

JobC looks good
Screenshot of jobC

However in jobA, jobC is listed multiple times
Screenshot of jobA

jobA

- sequence:
    keepgoing: false
    strategy: node-first
    commands:
    - exec: echo Hello from Job A
    - jobref:
        group: test
        name: jobC
        args: -host ${node.name}
        nodeStep: 'true'
  nodefilters:
    dispatch:
      threadcount: 1
      keepgoing: false
      excludePrecedence: true
      rankOrder: ascending
    filter: 'name: msg31-test1.ccs.ornl.gov'
  loglevel: INFO
  name: jobA
  description: jobA call jobB
  project: Infrastructure
  id: d17657c7-2968-4399-b9e4-dedd152db838
  uuid: d17657c7-2968-4399-b9e4-dedd152db838
  group: test

jobC

- sequence:
    keepgoing: false
    strategy: node-first
    commands:
    - exec: echo Hello World ${option.host}
      description: say hello to node/host
    - exec: echo Hello Again
    - type: localexec
      nodeStep: true
      configuration:
        command: echo Hello from local server
  nodefilters:
    dispatch:
      threadcount: 1
      keepgoing: false
      excludePrecedence: true
      rankOrder: ascending
    filter: ${option.host}
  loglevel: INFO
  name: jobC
  options:
    host:
      required: true
  description: jobC
  project: Infrastructure
  id: 44f8f189-5719-475c-9558-071bbdcf1273
  uuid: 44f8f189-5719-475c-9558-071bbdcf1273
  group: test
@gschueler
Contributor

you need to enter the description you want in the "Step Description" field in the workflow editor.
step-description

@pyther
pyther commented Aug 4, 2015

When I enter a Step Description, I get the same results as the screenshot above, except see my description instead of "test/JobC".

I have modified the jobs providing a description for each step, as this helps explain the behavior I expect/would like to see.

jobA

- sequence:
    keepgoing: false
    strategy: node-first
    commands:
    - exec: echo Hello from Job A
      description: JobA echo1
    - jobref:
        group: test
        name: jobC
        args: -host ${node.name}
        nodeStep: 'true'
      description: run JobC
  nodefilters:
    dispatch:
      threadcount: 1
      keepgoing: false
      excludePrecedence: true
      rankOrder: ascending
    filter: 'name: msg31-test1.ccs.ornl.gov'
  loglevel: INFO
  name: jobA
  description: jobA call jobB
  project: Infrastructure
  id: d17657c7-2968-4399-b9e4-dedd152db838
  uuid: d17657c7-2968-4399-b9e4-dedd152db838
  group: test

jobC

- sequence:
    keepgoing: false
    strategy: node-first
    commands:
    - exec: echo Hello World ${option.host}
      description: echo1_jobc
    - exec: echo Hello Again
      description: echo2_jobc
    - type: localexec
      nodeStep: true
      configuration:
        command: echo Hello from local server
      description: local_command echo
  nodefilters:
    dispatch:
      threadcount: 1
      keepgoing: false
      excludePrecedence: true
      rankOrder: ascending
    filter: ${option.host}
  loglevel: INFO
  name: jobC
  options:
    host:
      required: true
  description: jobC
  project: Infrastructure
  id: 44f8f189-5719-475c-9558-071bbdcf1273
  uuid: 44f8f189-5719-475c-9558-071bbdcf1273
  group: test

JobA
joba_description

JobC
jobc_description

It would be nice to see what steps are being executed for JobC during JobA.

As shown in the screenshot, the output for JobA look as such:

  • msg31.ccs.ornl.gov
    • [command] jobA echo 1
    • [job] run JobC
    • [job] run JobC
    • [job] run JobC

Ideally the output would be similar to this:

  • msg31.ccs.ornl.gov
    • [command] jobA echo 1
    • [job] run JobC
      • [command] echo1_jobC
      • [command] echo2_jobC
      • [local command] local command echo

Where the items in brackets represent the step icon.

In this example we can see each step of test/JobC.

@pyther
pyther commented Aug 4, 2015

I've also discovered an other example of this behavior. In this case, I have a workflow that calls a job if a steps fails. However all output for the called step shows under the failed job.

Patching/System

- sequence:
    keepgoing: false
    strategy: step-first
    commands:
    - exec: test -f /tmp/RUNDECK_PATCH
      errorhandler:
        jobref:
          group: Patching
          name: core
          args: -host ${node.name}
          nodeStep: 'true'
        keepgoingOnSuccess: true
      description: is_patched
    - script: |-
        #!/bin/bash

        if [[ -f /tmp/RUNDECK_PATCH ]]; then
            rm /tmp/RUNDECK_PATCH
        fi
      description: remove RUNDECK_PATCH
  nodefilters:
    dispatch:
      threadcount: 1
      keepgoing: false
      excludePrecedence: true
      rankOrder: ascending
    filter: 'name: msg31-test1.ccs.ornl.gov'
  loglevel: INFO
  name: Systems
  description: Patch Development Systems
  project: Infrastructure
  id: 0fcfd7a2-c7d0-4cb4-99ab-49fddb921483
  uuid: 0fcfd7a2-c7d0-4cb4-99ab-49fddb921483
  group: Patching

Patching/core

- sequence:
    keepgoing: false
    strategy: node-first
    commands:
    - type: localexec
      nodeStep: true
      configuration:
        command: /opt/bin/rundeck_hipchat.sh systems-notification -m "system patching started for ${option.host}"
      description: Hipchat Notification Start
    - type: localexec
      nodeStep: true
      configuration:
        command: /opt/bin/nagios_downtime --comment "system patching" ${option.host} --missingok
      description: add downtime
    - exec: echo sudo yum clean all
      description: yum clean all
    - exec: echo sudo yum update -y
      description: echo yum update
    - exec: touch /tmp/RUNDECK_PATCH
      description: touch RUNDECK_PATCH
    - exec: echo reboot
      description: reboot
    - type: localexec
      nodeStep: true
      configuration:
        command: echo /opt/bin/wait_for_reboot.py ${option.host}
      description: wait for reboot
    - type: localexec
      nodeStep: true
      configuration:
        command: /opt/bin/nagios_downtime --comment "system patching" ${option.host} --missingok --remove
      description: remove downtime
    - type: localexec
      nodeStep: true
      configuration:
        command: /opt/bin/rundeck_hipchat.sh systems-notification -m "system patching completed for ${node.name}"
      description: Hipchat Notification
  nodefilters:
    dispatch:
      threadcount: 1
      keepgoing: false
      excludePrecedence: true
      rankOrder: ascending
    filter: ${option.host}
  loglevel: INFO
  name: core
  options:
    host:
      required: true
      description: hostname
  description: This is the master patching job.
  project: Infrastructure
  id: 7dff0397-222e-4285-8e40-0dae5bc4cea7
  uuid: 7dff0397-222e-4285-8e40-0dae5bc4cea7
  group: Patching

screen shot 2015-08-04 at 8 14 51 am

What I would expect to see is something like this

  • msg31-test.ccs.ornl.gov
    • [command] is_patched
      • [job] patching/core
        • [local command] Hipchat Notification Start
        • [local command] add downtime
        • [command] yum clean all
        • [command] echo yum update -y
        • [command] touch RUNDECK_PATCH
        • [command] reboot
        • [local command] wait for reboot
        • [local command] remove downime
        • [local command] Hipchat Notification

or to keep with a flat hierarchy

  • msg31-test.ccs.ornl.gov
    • [command] is_patched
    • [local command] Hipchat Notification Start
    • [local command] add downtime
    • [command] yum clean all
    • [command] echo yum update -y
    • [command] touch RUNDECK_PATCH
    • [command] reboot
    • [local command] wait for reboot
    • [local command] remove downime
    • [local command] Hipchat Notification
@puremourning

+1

@gschueler
Contributor

I see what you mean now. This is a UI enhancement that has not been implemented yet. Currently only the workflow of the top-level job is used to render the labels for steps in the execution view. It requires looking up the workflow details for referenced jobs and using that info.

@kincl
kincl commented Aug 4, 2015

Hm while I understand the problem I would disagree that it is an enhancement, the UI is definitely not giving the right information. Especially on the "Log Output" view where the step number is always listed as 1.

@jmsizun
jmsizun commented Nov 5, 2015

I do agree in the disagreement :-).
The job and subjobs are correctly executed on the nodes according to what is configured for them, but the labels appearing on the report make the execution really difficult (if not impossible) to follow-up.

Which unfortunately may result on a no-go on those workflows, even if rundeck is perfectly able to execute them.

@edcar13
edcar13 commented Dec 5, 2015

Yep I'd find this useful :-)

@minhuber
minhuber commented Mar 2, 2016

+1

@pbrinkmann

+1

@gschueler gschueler added this to the 2.6.9 milestone Jun 30, 2016
@gschueler gschueler self-assigned this Jun 30, 2016
@gschueler gschueler closed this in #1926 Jun 30, 2016
@gschueler gschueler removed the in progress label Jun 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment