Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

api /v1/node/<id>/allocations returns an array of Allocation objects,… #402

Merged
merged 2 commits into from
Nov 12, 2015

Conversation

fernandezvara
Copy link

… not AllocationIndexStub

Endpoint for node allocations returns full allocations information instead of stub ones.

Probably the real goal for the endpoint was on return simpler information, so the endpoint to fix is on the server side instead of the client.

Anytime having that information there helps and simplifies getting info, so probably it can be interesting to have a /api/node/<id>/allocations and a /api/node/<id>/allocations?full=true with extended information.

Endpoint asked with a curl:

curl http://localhost:4646/v1/node/node-4/allocations?pretty=true
[
    {
        "ID": "0fe63e23-e7bf-28ea-c4c3-3703c07e5a13",
        "EvalID": "65824dc6-6416-c600-5a60-d1c4eb7d70ee",
        "Name": "111.cache[3]",
        "NodeID": "node-4",
        "JobID": "111",
        "Job": {
            "Region": "global",
            "ID": "111",
            "Name": "111",
            "Type": "service",
            "Priority": 50,
            "AllAtOnce": false,
            "Datacenters": [
                "ams3"
            ],
            "Constraints": [ ...],
            "TaskGroups": [ ... ]

...
...
]


@diptanu
Copy link
Contributor

diptanu commented Nov 11, 2015

I think the original goal for returning lesser information was that we want listing operations to be performant. Adding more data adds to serialization cost.

@cbednarski cbednarski added theme/api HTTP API and SDK issues stage/thinking labels Nov 11, 2015
@fernandezvara
Copy link
Author

Yes, I know what you telling @diptanu , but since the endpoint returns full information I think it makes sense to get using the API client the full allocation information.

Probably nomad must allow to return the full or lesser information using some parameter being the default the summarised one, since there is already a cost converting on the servers the data to JSON.

So /node//allocations should return the []AllocationIndexStub and ?full=true (or something like that) []Allocation. That way the server and client will de/serialize the same amount of information.

Getting a summarised information forces to make 1 + n API requests instead of just 1.

Another posibility can be adding a function that like AllocationsFull returning the []Allocation and leave the current as is. In our use case the ideal is make just 1 request per server and calculate the current allocation to know if we need to spin up another node.

@dadgar
Copy link
Contributor

dadgar commented Nov 11, 2015

@fernandezvara
Copy link
Author

Documentation updated.

@dadgar
Copy link
Contributor

dadgar commented Nov 12, 2015

@fernandezvara: Thanks!

dadgar added a commit that referenced this pull request Nov 12, 2015
api /v1/node/<id>/allocations returns an array of Allocation objects,…
@dadgar dadgar merged commit 2ecdf14 into hashicorp:master Nov 12, 2015
@fernandezvara fernandezvara deleted the fix-api-node-allocations branch November 20, 2015 13:33
@github-actions
Copy link

github-actions bot commented May 2, 2023

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 2, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
stage/thinking theme/api HTTP API and SDK issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants