Hi.
I was trying to build a simple CI pipeline, and then i stumbled upon a need to get IP/port pair of allocation. It seems that it is not possible to get that using current CLI commands: you can either get allocation by id or job by name, but can't get allocations of a job; inspect command provides a -short flag, but i can't see any allocation info in JSON output even if it is not present. I've seen that it is done trivially via API (and via Consul API if service is registered properly), but implementing proper API is a bit more challenging task rather than automate CLI output processing.
So, basically, i suggest implementing CLI new command or enhance existing command to output job allocation ids in JSON or other parseable format.
Hey @etki,
I would suggest not building integration on the CLI as we do not promise backwards compatibility there but we do on the API. In particular 0.6.0 will bring a reworked CLI and this should be possible then!
@dadgar Sorry for answering that late. I know that even Nomad isn't the biggest project in the world, feature requests just flood everything up and it is hard even to bring software into stable state. However, interacting via CLI is usually the only option for early adopters: if you're using CI that provides you with shell access only (i'm not sure if there is jenkins plugin for deployments, but travis, codeship, etc. certainly doesn't have first-class integration, at least yet), you're cornered to use CLI tools. So it's kinda unavoidable unless Nomad has first-class integrations, and that would certainly happen after more critical features are implemented.
kubectl, which serves just the same purpose, is barely letting API responses through, but it takes away all the authorization/endpoint configuration so you don't need to pass it to curl or deliver other way, it just happens somewhere and integrates perfectly (i can easily fetch deployed applications published ports using some easy cli magic). I feel that Nomad can do the same thing without too much hassle, when API itself is stable (it already is, i guess) you can just expose it via some command / formatting options and just hide all the authorization/connection details in config (i'm talking about NOMAD_ADDR and possible proxy-based basic auth).
This is absolutely basic functionality, I can't believe that this wasn't a feature from day one.
Please implement this.
This issue looks outdated unless I am missing something. Here's the output from nomad job status that shows alloc ids.
preetha@preetha-work ~ $nomad job status example
ID = example
Name = example
Submit Date = 2018-03-07T15:38:34-06:00
Type = service
Priority = 50
Datacenters = dc1
Status = running
Periodic = false
Parameterized = false
Summary
Task Group Queued Starting Running Failed Complete Lost
cache 0 0 3 0 0 0
Latest Deployment
ID = 4f4ea5d7
Status = running
Description = Deployment is running
Deployed
Task Group Desired Placed Healthy Unhealthy
cache 3 3 0 0
Allocations
ID Node ID Task Group Version Desired Status Created Modified
23e5cd03 844afa58 cache 1 run running 17s ago 16s ago
7c70cb06 844afa58 cache 1 run running 17s ago 16s ago
be573c94 844afa58 cache 1 run running 1m49s ago 17s ago
My two cents: (agreeing with the op)
It isn't easy to get to the current allocation id of a job, which may have multiple allocations over time.
My simple use case has 1 task in 1 job, so maybe not as same as large scale deployments with multiple tasks, etc.
To add: getting to the latest allocation id of a periodic job is also something that is non-trivial.
I have to run a couple of status commands before getting to the allocation id.
Is this functionality available yet, to get the latest Allocation ID on a particular Job ID
Most helpful comment
My two cents: (agreeing with the op)
It isn't easy to get to the current allocation id of a job, which may have multiple allocations over time.
My simple use case has 1 task in 1 job, so maybe not as same as large scale deployments with multiple tasks, etc.
To add: getting to the latest allocation id of a periodic job is also something that is non-trivial.
I have to run a couple of
statuscommands before getting to the allocation id.