Bug 1381621

In the latest version of origin (1.3), the node's name is printed to stderr, while the actual json object containing the pods is printed to stdout (so parsing, at least, is not an issue). 

However, I like your idea of grouping pod lists with their associated node in a json / yaml object, and have opened a PR to add this here: https://github.com/openshift/origin/pull/11216

The parsing in 1.3 continues to be an issue as the json is stacked on top of each other.  The user is then expected to parse the output into json.

Example:
{
    "metadata": {
        "selfLink": "/api/v1/pods",
        "resourceVersion": "102478"
    },
    "items": []
}
{
    "metadata": {
        "selfLink": "/api/v1/pods",
        "resourceVersion": "123456"
    },
    "items": []
}

The previous example is what is returned and does not load into json because it is not a single hash or a list of hashes.  Its just stacked json.

I appreciate the work in the PR, it will greatly improve our ability to work with the output of oadm manage-node.

Thanks Juan.

Hi Kenny,

Per this comment on the PR thread[1], adding the suggested format to json and yaml output would make that output incompatible with other `oc` / `oadm` commands, as it would no longer follow a valid API object spec.

This comment[2] suggests alternatives for parsing the current output on origin 1.3

[1] https://github.com/openshift/origin/pull/11216#issuecomment-251500534
[2] https://github.com/openshift/origin/pull/11216#issuecomment-251500820

Revised the previously submitted PR. Rather than modify api objects when printing, list of pods from all nodes will be merged into a single list:

Example:
{
    "metadata": {
        "selfLink": "/api/v1/pods",
        "resourceVersion": "102478"
    },
    "items": [
        ... // items from nodes 'ip-172-31-59-33.ec2.internal' and 'ip-172-31-59-34.ec2.internal'
    ]
}

this ensures that the output is easy to parse, and does not "break" the printed object's compatibility with other openshift commands.

Updated PR: https://github.com/openshift/origin/pull/11216

Output now prints objects in an `api.List`, this ensures that the entire output can be parsed as a single json or yaml object, while maintaining compatibility with the rest of `oc` commands.

Please test the case where there are multiple notes returned by the query. That will show the enhancements made. Thanks.

Please test the case where there are multiple notes returned by the query. That will show the enhancements made. Thanks.

Hmm.. tested on multi-nodes OCP env, 3.4 is not reproduced, but 3.2, 3.3 reproduced:
oadm v3.4.0.16+cc70b72 (not reproduced)
oadm v3.3.1.3 (reproduced)
oadm v3.2.2.2 (reproduced)


# oadm manage-node --selector="role=node"  --list-pods -o json

Listing matched pods on node: ip-172-18-13-3.ec2.internal

{
    "metadata": {
        "selfLink": "/api/v1/pods",
        "resourceVersion": "12445"
    },
    "items": [...]
}

Listing matched pods on node: ip-172-18-4-108.ec2.internal

{
    "metadata": {
        "selfLink": "/api/v1/pods",
        "resourceVersion": "12524"
    },
    "items": [...]
}

kwoodson would you need this fix backported to OCP 3.3? It is currently in 3.4 which has not released yet.

xiaocwan Marking this bug as ON_QA once more. We are not backporting to 3.2, and the bug's severity is not high enough to be backported to 3.3.

3.4 has not released yet, but the bugfix can be verified on the latest master.

cc ffranz

# oadm manage-node --selector="role=node"  --list-pods -o json > pods.json
check pods.json, there is not extra line "Listing matched pods on node: ip-xxx.xxx.xxx.internal"

Verified on oc/openshift v3.4.0.17+b8a03bc

(In reply to Juan Vallejo from comment #11)
> kwoodson would you need this fix backported to OCP 3.3? It is
> currently in 3.4 which has not released yet.

It would be nice to have this backported but it is not crucial at this time.