Where can we find Status Values in API V2

  • 13 July 2017
  • 5 replies

Userlevel 1
Badge +9
How do we find all possible status values in the API?
We are building an API based app that tracks component status. Is there a way for us to find this data on our own?
When we drill down into the docs we just see items like 'state (string, optional),'

For example:
  • /operation_mode (What are possible values and meaning of those values?)
  • /health_status (same question)

    This is just a small sample of the data we're looking for. How can we find a more detailed description of these?

  • 5 replies

    Badge +4
    Did you try ?

    That has a little more of an explanation. Let us know if what you need isn't covered there.

    Userlevel 1
    Badge +9
    The Status values and meanings are not listed.

    If those values are defined in souce code please direct us there. Our other option is to systematically break our cluster to see the effects, but that is not a good option as we only have a single-host cluster.

    Thank you,
    Userlevel 4
    Badge +19

    You can refer the below guide.

    You can find the "Status Codes" section in page 25
    Userlevel 1
    Badge +9
    We are not referring to HTTP status. We're speaking about status of individual API data targets.
    For example if you look at v2/disks and grab entities[i], there is a disk_status value.

    We need to know all possible values of entities[0].disk_status, and what those values correlate to in plain english.
    The API explorer tool simply states that its value is a string.

    Also, other examples:
    * {v2/hostss}.entities[i].state
    * {v2/hostss}.entities[i].hypervisor_state
    * {v2/hostss}.entities[i].metadata_store_status* {v2/hostss}.entities[i].failover_cluster_node_state
    Its clear that the developers who wrote the API know the values and meanings of all these, but its not clear to external users/developers.

    These are not the only ones, I'm just providing examples. Bascially any property output by the API which has "state" or "status" in it, needs to be clarified. The alternative is for developers to attempt a systematic failure of their cluster which is not reliable.
    Userlevel 7
    Badge +30
    In short, you're right. We're going through a very large effort to "get right" on all of this internally, which includes updating all of our legacy APIs (pre v3) to swagger 2.0 format, which will bring in a MASSIVE amount of standardization, including examples, etc, as well as a massive amount of tooling that we've built around the v3 API's that will "benefit" the legacy APIs, long story short.

    Feel free to ping me any time