Registering job with Nomad without running it

Hey,

I want to register job as a part of my ansible playbook without running it (otherwise playbook fails at this stage as clients are not available yet).

How can I accomplish that?

Hi @yevhenii.kurtov,

While reading your problem description, two things came to my mind:

  1. If you can live with not registering your jobs until you actually want to run them, you could simply do a “nomad job plan” (instead of already doing the “job run”).

  2. Use a parametrized job (Parameterized jobs on Nomad | Nomad | HashiCorp Developer), that does not actually run until you dispatch it (“nomad job dispatch”).

Add this to your job:

  parameterized {

  }

I think you are more looking for (2). I already used these kind of jobs for doing snapshots in my cluster (with different kind of snapshots, so I could parametrize and set a variable for the kind of jobs I want to invoke/dispatch). But I think you can define a parametrized jobs without any meaningful parameters and just “invoke” it whenever you actually need to run it (later in the playbook). Haven’t tested it yet without any parameters, but the linked tutorial mentions that it should work without. In any case, the job will only run once “dispatched”.

Cheers

1 Like

What exactly do you want to “register”? What exactly do you mean by “not running”?

Nomad stores running jobs. If you want to “register” a job that is not running, then don’t register it, there is nothing to register.

re not available yet

Does that mean that the job will run? So you want to register a job that will run later? Why not do it?

Hey @andreas.gruhler,

Thanks for tips. Unfortunatelly, I couldn’t mark jobs as parameterized because it required batch scheduler.

After playing around a bit I was able to “register” job with setting count = 0 and -check-index 0.

Now an operator can go into Nomad UI, edit the count number and get off to the races :slight_smile:

Convenient!

2 Likes

perfect! I did not think of this scenario while reading your question, but definitely a viable solution :slight_smile: