Hi, I'm contemplating using nomad-pack to well.. package all the jobs of my application in one neat package.
Here's my dream workflow:
A. Include new job:
- Write/Develop a vanilla nomad job, with variables and good old
${var.myvar} or var.myvar variable references. Note that my favourite source of variable is currently environment variables ( i.e. NOMAD_VAR_myvar)
- Include the job without any modification into my existing pack.
- Repeat for other jobs.
B. Modify a job:
- Extract the job definition from the pack
- Modify independently
- Re-pack the job.
I'd like to work this way to avoid having to redeploy the whole pack to my dev environment each time I want to work on a given job.
As far as I understand, the way nomad-pack manages variables makes the workflow A impossible. I would have to change my job so the variable it uses (and the template syntax to access them) is now nomad-pack specific.
I suppose workflow B could be supported by the render command, but then I would lose the variable definitions.
I guess supporting workflow A would require nomad-pack to:
- Allow variables to be the superset of all variables mentioned in individual jobs.
- Allow individual jobs to keep using the
${var.} or var. syntax
- Allow variables to come from environment variables. (Not a strong requirement).
Does all of this make sense or am I missing something fundamental?
Hi, I'm contemplating using nomad-pack to well.. package all the jobs of my application in one neat package.
Here's my dream workflow:
A. Include new job:
${var.myvar}orvar.myvarvariable references. Note that my favourite source of variable is currently environment variables ( i.e.NOMAD_VAR_myvar)B. Modify a job:
I'd like to work this way to avoid having to redeploy the whole pack to my dev environment each time I want to work on a given job.
As far as I understand, the way nomad-pack manages variables makes the workflow A impossible. I would have to change my job so the variable it uses (and the template syntax to access them) is now nomad-pack specific.
I suppose workflow B could be supported by the render command, but then I would lose the variable definitions.
I guess supporting workflow A would require nomad-pack to:
${var.}orvar.syntaxDoes all of this make sense or am I missing something fundamental?