Rework of worker template so that it is more flexible

[j3t]

Feature Request

I would like to rework the whole Worker Template. It contains a lot of fields (e.g. CPU, Memory) but there are still fields missing (e.g. Env, Args, Command and Entrypoint).

In my opinion, it would be more flexible when we just could define a job template and some placeholders. The default template could be like the following:

{
  "Job": {
    "Region": "eu",
    "ID": "%WORKER_NAME%",
    "Name": "%WORKER_NAME%",
    "Type": "batch",
    "Datacenters": [
      "dc01"
    ],
    "TaskGroups": [
      {
        "Name": "jenkins-worker-taskgroup",
        "Count": 1,
        "RestartPolicy": {
          "Attempts": 0,
          "Interval": 1800000000000,
          "Delay": 15000000000,
          "Mode": "fail"
        },
        "Tasks": [
          {
            "Name": "jenkins-worker",
            "Driver": "docker",
            "Config": {
              "image": "jenkins/inbound-agent"
            },
            "Env": {
              "JENKINS_URL": "http://localhost:8080",
              "JENKINS_AGENT_NAME": "%WORKER_NAME%",
              "JENKINS_SECRET": "%WORKER_SECRET%"
            },
            "Resources": {
              "CPU": 6000,
              "MemoryMB": 1024
            }
          }
        ],
        "EphemeralDisk": {
          "Sticky": false,
          "SizeMB": 1024,
          "Migrate": false
        }
      }
    ]
  }
}

This also simplifies the plugin code a lot because only the placeholders must be replaced and then it can be sent to Nomad.

• Pros
  • worker definition is more flexibility (there are basically no limits)
  • it is more clear how the job looks like which is sent to nomad
  • fewer fields
  • smaller codebase
  • a bunch of feature request can be closed

  • 77

  • 76

  • 62

  • 26

• Cons
  • not backward compatible

What is your opinion?

[multani]

As much as it would improve the flexibility, I see this:

not backward compatible

As a real deal breaker.

I'm not sure if it's possible to reprogram the plugin to add 2 types of templates:

• The first one would be the original one, like it is today
• The second one would be something based on your proposition

This would provide a migration path, without breaking everything. Another possibility would be to migrate the template definitions when the plugin gets upgraded. I have no idea how to do that though.

Something that could still be explored, though, would be to rewrite the internals of the plugin to support the type of functionality you said in this PR (so having a full definition stored somewhere, and being able to update parts of it), and to implement the current worker template system over this new functionality. This would be transparent for the current users, while having more flexible internals. The new internals could be then exposed in a second step (still need to figure out this one.)

This requires a bit a work though, and as you saw, the manpower on the plugin is pretty low at the moment.

[j3t]

I like the possibility to migrate the template definitions. According to https://wiki.jenkins.io/display/JENKINS/Hint+on+retaining+backward+compatibility, we have to keep the old fields but we can mark them as transient and then they are not part of the configuration file anymore.

If you don't mind then I would like start with a PoC.

[j3t]

The migration is straight forward and not an issue at all (see https://github.com/j3t/nomad-plugin/tree/feature-81-more-flexible-worker-template). I have the feeling that this could work without loosing backward compatibility.

[multani]

@j3t Glad to hear! Can you open a draft pull request with your changes? I may have some time at the end of the week to give it a look :+1:

[j3t]

@multani Thanks! https://github.com/jenkinsci/nomad-plugin/pull/82

[mikedld]

Nomad job templates seem to look a lot like Kubernetes pod templates, and Nomad itself does in part what Kubernetes does, in its own way. There's a Kubernetes Jenkins plugin that accepts the template from the pipeline (via podTemplate() step in scripted pipelines and agent{kubernetes{}} section in declarative pipelines), not hard-coded in cloud settings; I can't stop wondering if using the same approach for Nomad plugin would make it even more flexible. Was this ever considered?

[multani]

@mikedld This was discussed a long time ago in https://github.com/jenkinsci/nomad-plugin/issues/20

I made a kind of proof-of-concept in https://github.com/multani/nomad-pipeline (which works) but I lack the time/energy to work on time at the moment.