NodeID no longer returned from /agent/self

[aprice]

Client: 1.0.2
Server: 0.8.1

PS C:\Users\Administrator> consul info
agent:
        check_monitors = 0
        check_ttls = 0
        checks = 1
        services = 1
build:
        prerelease =
        revision = b55059f
        version = 1.0.2
consul:
        known_servers = 1
        server = false
runtime:
        arch = amd64
        cpu_count = 2
        goroutines = 59
        max_procs = 2
        os = windows
        version = go1.9.2
serf_lan:
        coordinate_resets = 0
        encrypted = false
        event_queue = 0
        event_time = 8
        failed = 0
        health_score = 0
        intent_queue = 0
        left = 0
        member_time = 510
        members = 11
        query_queue = 0
        query_time = 1

In Consul versions prior to 1.0, the /agent/self endpoint would return a key Config.NodeID containing the local node's ID. In versions after 1.0, the key is missing, and no breaking change was documented for this in the release notes. I have a mixed cluster so I have compared side-by-side the output for the route for a 0.9.3 agent and a 1.0.2 agent, and they do not return the same details. I could not find anything related to changes to this endpoint in the release notes.

[slackpad]

Hi @aprice sorry about that - that was documented in the change log in this section:

Config Section of Agent Self Endpoint has Changed: The /v1/agent/self endpoint's Config section has often been in flux as it was directly returning one of Consul's internal data structures. This configuration structure has been moved under DebugConfig, and is documents as for debugging use and subject to change, and a small set of elements of Config have been maintained and documented. See Read Configuration endpoint documentation for details. [GH-3532]

I do think the NodeID field is reasonable to add back into the more explicitly-supported Config section though, so I'll mark this as an enhancement.

[aprice]

I must have scanned right past it - sorry about that. We are using it to allow services to get the local node ID for self-registration via the catalog API. We've had to postpone the upgrade to 1.0 until we can build a solution that works with both the old and new API response formats (or until the field is put back).