vmfloaty reports an error on latest API version output

[mattkirby]

When running vmfloaty on the latest vmpooler revisions I get an error from the client.

error: 765: unexpected token at ''. Use --trace to view backtrace

When run with a backtrace I see

$user_home/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/json-2.1.0/lib/json/common.rb:156:in `parse': 765: unexpected token at '' (JSON::ParserError)

Here's the API response from '/api/v1/status'. Piping the output to jq allows me to iterate through it alright so it's not immediately clear to me where the issue is, however I suspect it's to do with parsing changes introduced with puppetlabs/vmpooler@1024532 .

{
  "boot": {
    "duration": {
      "average": 107.7,
      "min": 70.21,
      "max": 125.53,
      "total": 646.0
    },
    "count": {
      "total": 6
    }
  },
  "capacity": {
    "current": 6,
    "total": 6,
    "percent": 100.0
  },
  "clone": {
    "duration": {
      "average": 58.9,
      "min": 23.3,
      "max": 77.43,
      "total": 353.39
    },
    "count": {
      "total": 6
    }
  },
  "pools": {
    "centos-7-x86_64": {
      "ready": 2,
      "running": 0,
      "pending": 0,
      "max": 2,
      "lastBoot": "2018-04-19 21:37:06 +0000",
      "alias": [
        "centos-7-64",
        "centos-7-amd64"
      ]
    },
    "sles-12-x86_64": {
      "ready": 2,
      "running": 0,
      "pending": 0,
      "max": 2,
      "lastBoot": "2018-04-19 21:37:03 +0000",
      "alias": [
        "sles-12-64",
        "sles-12-amd64"
      ]
    },
    "redhat-7-x86_64": {
      "ready": 2,
      "running": 0,
      "pending": 0,
      "max": 2,
      "lastBoot": "2018-04-19 21:37:06 +0000",
      "alias": [
        "redhat-7-64",
        "redhat-7-amd64"
      ]
    }
  },
  "queue": {
    "pending": 0,
    "cloning": 0,
    "booting": 0,
    "ready": 6,
    "running": 0,
    "completed": 0,
    "total": 6
  },
  "status": {
    "ok": true,
    "message": "Battle station fully armed and operational.",
    "uptime": 1993.9
  }
}%

[demophoon]

I chatted with @mattkirby about this and determined that an nginx proxy rewrite rule inbetween vmfloaty and the vmpooler api endpoint was the root cause. Nothing more is needed for this issue.