Nomad: [enhancement] Add CLI method to fetch allocation ids based on job name

Created on 17 Jan 2017  路  6Comments  路  Source: hashicorp/nomad

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.

themcli typenhancement

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 status commands before getting to the allocation id.

All 6 comments

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

funkytaco picture funkytaco  路  3Comments

hamann picture hamann  路  3Comments

byronwolfman picture byronwolfman  路  3Comments

Gerrrr picture Gerrrr  路  3Comments

mancusogmu picture mancusogmu  路  3Comments