Support "Overriding Node Filters" for Job reference step

[diogokiss]

Hi,

In the Rundeck UI interface (since 2.6.11, at least), when you add a job reference step (let's call it job B) to an existing job (let's call it job A), it is possible to override the node filter/selection from job A, so that job B has different nodes as target.

However, the command job block doesn't seem to allow such a feature. Would it be possible to add it to the project's roadmap?

Terraform Version

$ terraform version
Terraform v0.11.14
+ provider.rundeck v0.3.0

Your version of Terraform is out of date! The latest version
is 0.12.5. You can update by downloading from www.terraform.io/downloads.html

Affected Resource(s)

• rundeck_job

Terraform Configuration Files

resource "rundeck_job" "job-b" {
  name = "job-b"
  project_name = "testing"
  description = "This is job B."

  allow_concurrent_executions = false
  max_thread_count = 1

  command {
    description = "Hello World"
    shell_command = "echo 'Hello World!'"
  }
}

resource "rundeck_job" "job-a" {
  name = "job-a"
  project_name = "testing"
  description = "This is job A."

  allow_concurrent_executions = false
  node_filter_query = "hostname: rundeck.*"
  max_thread_count = 1

  command {
    description = "Does something"
    shell_command = "hostname -f"
  }

  command {
    description = "Does something else using job B."

    job {
      name = "${rundeck_job.job-b.name}"
      run_for_each_node = true
    }
  }
}

Expected Behavior

What should have happened?

It should be possible to define an override for the node filter in the command's job block.

Actual Behavior

What actually happened?

It is not possible to define that. In addition, if we set manually via the interface, the Terraform plan doesn't show any changes.

Steps to Reproduce

1. Run terraform apply against the aforementioned code.

$ terraform11.14 plan -target=rundeck_job.job-a -target=rundeck_job.job-b
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

rundeck_job.job-b: Refreshing state... (ID: 3fbe9d06-9ece-4373-8c47-89c56442b0a5)
rundeck_job.job-a: Refreshing state... (ID: 4b0516aa-3d7a-4b2a-a2bd-3bc55aa5d143)

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  + rundeck_job.job-a
      id:                                <computed>
      allow_concurrent_executions:       "false"
      command.#:                         "2"
      command.0.description:             "Does something"
      command.0.shell_command:           "hostname -f"
      command.1.description:             "Does something else using job B."
      command.1.job.#:                   "1"
      command.1.job.0.name:              "job-b"
      command.1.job.0.run_for_each_node: "true"
      command_ordering_strategy:         "node-first"
      description:                       "This is job A."
      execution_enabled:                 "true"
      log_level:                         "INFO"
      max_thread_count:                  "1"
      name:                              "job-a"
      node_filter_query:                 "hostname: rundeck.*"
      preserve_options_order:            <computed>
      project_name:                      "testing"
      rank_order:                        "ascending"
      schedule_enabled:                  "true"

  + rundeck_job.job-b
      id:                                <computed>
      allow_concurrent_executions:       "false"
      command.#:                         "1"
      command.0.description:             "Hello World"
      command.0.shell_command:           "echo 'Hello World!'"
      command_ordering_strategy:         "node-first"
      description:                       "This is job B."
      execution_enabled:                 "true"
      log_level:                         "INFO"
      max_thread_count:                  "1"
      name:                              "job-b"
      preserve_options_order:            <computed>
      project_name:                      "testing"
      rank_order:                        "ascending"
      schedule_enabled:                  "true"


Plan: 2 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

2. Check the job A's configuration for the step that invokes the job B. It has the Override node filters? option not set.

3. Set manually via UI this option to some other node filtering.

4. Run terraform plan. It will not show any changes.

$ terraform11.14 plan -target=rundeck_job.job-a -target=rundeck_job.job-b
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

rundeck_job.job-b: Refreshing state... (ID: 3fbe9d06-9ece-4373-8c47-89c56442b0a5)
rundeck_job.job-a: Refreshing state... (ID: 4b0516aa-3d7a-4b2a-a2bd-3bc55aa5d143)

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

Important Factoids

I'm testing the Terraform command against a Rundeck running inside a Vagrant box. But, I don't believe that it has any particular effect on this specific scenario.

References

https://docs.rundeck.com/docs/manual/node-steps/builtin-node-steps.html#job-reference-step

[diogokiss]

I guess that this was implemented in https://github.com/terraform-providers/terraform-provider-rundeck/pull/27 and released in https://github.com/terraform-providers/terraform-provider-rundeck/releases/tag/v0.4.0. Is that correct?

[diogokiss]

This issue has been already implemented and has been released.