I am wondering about the future of Nomad Pack vs Levant for templating jobs.
As a Levant user is that it appears that development of Levant has slowed down considerably while nomad pack is the newer method similar to things like helm.
Is Levant planned to no longer be supported and eventually sunset for nomad pack? I just want to know if we should be getting ahead of this change and working towards this goal.
Very much interested to hear an answer to this as well.
Same here, there are so many ways to render a job file.
HCL2 function, template, Levant, Nomad pack, Consul-Template, hcat etc.
They all share part of goal to describe a dynamic or non-dynamic task.
And this will terrify the newcomers like me.
Also super-interested in this!
From nomad-pack’s guides:
Nomad Pack can be thought of as a templating and deployment tool like Levant with the ability to pull from remote registries and deploy multiple resources together, like Helm.
At the same time last Levant release was over 1 year ago (!) - I had to fork some existing github action and build my custom docker image with levant in order to get deployment working on GH 
I mean it works for now, but as @brettpatricklarson said:
I just want to know if we should be getting ahead of this change and working towards this goal
on point
Same here, we had to create an image to make it run in CI. Also there is a drift in syntax check in job definition between Nomad and Levant that causes some errors (made a github issue about it).
So definitely interested in knowing the furtur of these templating tools.
Hi everyone and thanks for your insights and input into this discussion. I realise that development effort has indeed slowed on Levant. We are committed to maintenance releases and critical fixes where needed, however, we do not have any roadmapped work currently for this project. I am trying to find a little time to go through the backlog over the coming weeks/months while we also move the project onto a new release pipeline.
Nomad Pack is still in tech-preview state and so is expected to change and develop a fair amount more before it moves from this state. Development has slowed for the moment in favour of other priorities and projects, this will likely pickup again in the near future.
While the future is never certain, we do expect nomad-pack or the Nomad native CLI to be our preferred ways to manage and run jobs. While nomad-packs purpose is well defined around templating, the Nomad CLI also offers HCLv{1,2} syntax, job deployment monitoring, variable replacement at submission time, and scaling commands, all of which Levant was built for initially to perform.
If you have feature requests for nomad-pack or Nomad please feel free to reach out either via the repositories or in this thread for further discussion or questions.
jrasell and the Nomad team
Thank you for detailed answer @jrasell! <3 This worries me a little bit tho:
We are committed to maintenance releases and critical fixes where needed, however, we do not have any roadmapped work currently for this project.
and
Nomad Pack is still in tech-preview state and so is expected to change and develop a fair amount more before it moves from this state. Development has slowed for the moment in favour of other priorities and projects, this will likely pickup again in the near future.
Along with the fact that levant doesn’t work with all nomad 1.3 features and nomad pack being is such early tech-preview stage it seems community lack proper tooling for setting continuous deployment pipelines? Personally I will probably still rely on levant for time being tho as it seems so far it works for me
Necro-bumping as I’m currently just starting with nomad and want to make a somewhat “future-proof” tooling choice.
My use case revolves around using nomad for CD deployments where the job specs of all jobs that are inter-dependent typically live in a specific git repository, along with templates, such as e.g. initdb.tpl.sql things that I can use in a postgres job that is used by the other services in the repo.
If I want to update a deployment (meaning here a “bundle” of related jobs), I would either checkout the repo and have the necessary env vars (like NOMAD_ADDR) set by direnv (for “manual” operation), or (typically) have a gitlab-ci runner (re-)deploy using (e.g.) env vars from triggering build pipelines that contain the specific version tag of an updated service that should be part of the deployment.
When scaling, I’d still be aiming to keep everything DevOps (dev’s hosts and gitlab-runners) connected via a private WireGuard net (the same that internally connects my cluster nodes), which should mean that having any “deployment state” anywhere else than in the deployment itself seems counter-intuitive. (Comparison of desired state and actual state during deployment should always be possible to determine by simply querying the nomad server anyway?)
My nomad cluster(s) run on nixos VPS and (optionally) on-prem bare metal (possibly in the future also on micro-vm’s), so I’m trying to avoid introducing terraform in the mix since I have my IaC covered with nixos.
This means the tooling I’m looking for would ideally do the following:
count. (A bit like helmfile but without the multi-layered templating nightmare that helm is).nomad client from the repo is unnecessarily complex (why doesn’t artifact support job-spec-local sources?), and typically (in my case) all vars are known at deployment time.Given this background, which of the options (plain nomad (+possibly a script), TF+nomad, levant or nomad-pack) would be most suitable?
Nice to know Hashicorp is on top of this.
So, in brief: Levant is abandonware and Pack is on a single spare-time commiter since like five months ago.
Anyway. Any other news worth sharing?