V3/Processes: HealthCheckType "none" not supported / JsonParsingException

[eaglerainbow]

This is in reference to promregator/promregator#72 (comment) where a user of Promregator detected a situation which leads to a JsonParsingException when reading the data of endpoint /v3/processes from a CF platform with API version 2.94.0.

In a nutshell:

• There is an app in state "RUNNING" with guid 978e4999-c62c-4dc5-98ea-1412983e92e6
• This app has the health-check functionality switched off.
• The call cf curl '/v3/processes?app_guids=978e4999-c62c-4dc5-98ea-1412983e92e6&organization_guids=8acf895e-ce26-42d7-819d-c3f4a3b251d5&page=1&per_page=50&space_guids=ecfd1d01-e32b-41fb-a474-1fb63dd813e8' returns the following document (copy & paste from promregator#72):

  {
     "pagination": {
        "total_results": 1,
        "total_pages": 1,
        "first": {
        "href": "https://api.sys.our.cloud.com/v3/processes?app_guids=978e4999-c62c-4dc5-98ea-1412983e92e6&organization_guids=8acf895e-ce26-42d7-819d-c3f4a3b251d5&page=1&per_page=50&space_guids=ecfd1d01-e32b-41fb-a474-1fb63dd813e8"
        },
        "last": {
           "href": "https://api.sys.our.cloud.com/v3/processes?app_guids=978e4999-c62c-4dc5-98ea-1412983e92e6&organization_guids=8acf895e-ce26-42d7-819d-c3f4a3b251d5&page=1&per_page=50&space_guids=ecfd1d01-e32b-41fb-a474-1fb63dd813e8"
        },
        "next": null,
        "previous": null
     },
     "resources": [
        {
           "guid": "978e4999-c62c-4dc5-98ea-1412983e92e6",
           "type": "web",
           "command": "[PRIVATE DATA HIDDEN IN LISTS]",
           "instances": 1,
           "memory_in_mb": 1024,
           "disk_in_mb": 1024,
           "health_check": {
              "type": "none",
              "data": {
                 "timeout": null
              }
           },
           "created_at": "2018-05-09T13:13:29Z",
           "updated_at": "2018-08-31T05:47:26Z",
           "links": {
              "self": {
                 "href": "https://api.sys.our.cloud.com/v3/processes/978e4999-c62c-4dc5-98ea-1412983e92e6"
              },
              "scale": {
                 "href": "https://api.sys.our.cloud.com/v3/processes/978e4999-c62c-4dc5-98ea-1412983e92e6/actions/scale",
                 "method": "POST"
              },
              "app": {
                 "href": "https://api.sys.our.cloud.com/v3/apps/978e4999-c62c-4dc5-98ea-1412983e92e6"
              },
              "space": {
                 "href": "https://api.sys.our.cloud.com/v3/spaces/ecfd1d01-e32b-41fb-a474-1fb63dd813e8"
              },
              "stats": {
                 "href": "https://api.sys.our.cloud.com/v3/processes/978e4999-c62c-4dc5-98ea-1412983e92e6/stats"
              }
           }
        }
     ]
  }

  Mind here that resources[0].health_check.type == "none"
• Promregator is triggering the same call with the following pieces of source code: https://github.com/promregator/promregator/blob/ec2aaa0ff74716011de6ea17fb2ac803841d04c9/src/main/java/org/cloudfoundry/promregator/cfaccessor/ReactiveCFAccessorImpl.java#L381 and https://github.com/promregator/promregator/blob/ec2aaa0ff74716011de6ea17fb2ac803841d04c9/src/main/java/org/cloudfoundry/promregator/cfaccessor/ReactiveCFAccessorImpl.java#L232
• This combination causes an exception org.cloudfoundry.reactor.util.JsonParsingException: Cannot construct instance of org.cloudfoundry.client.v3.processes.HealthCheckType, problem: Unknown health check type: none
• Current version of cf-java-client in use by Promregator is 3.11.0.RELEASE.
• Current source code version of

  cf-java-client/cloudfoundry-client/src/main/java/org/cloudfoundry/client/v3/processes/HealthCheckType.java

  Line 25 in c656f6a

  public enum HealthCheckType {

  is identical to the version being used. The enum is missing "none".

For further details, please feel free to also have a look at promregator/promregator#72

@jensbaitingerbosch Ping to you, that I have created this issue for your case.

Thanks for looking at this case!

[eaglerainbow]

One more thing, which might be worth to mention:

For that app, we have the following timestamps:

   "created_at": "2018-05-09T13:13:29Z",
   "updated_at": "2018-08-31T05:47:26Z",

That is to say: The apps are "quite fresh" and thus it does not look like some "ugly legacy case"...

[eaglerainbow]

Moreover, it might interesting to mention that http://v3-apidocs.cloudfoundry.org/version/3.57.0/index.html#the-health_check-object states that

The type of health check to perform. Valid values are http, port, and process. Default is port.

which is contradicting to the "real world". Also the CF CLI documentation lists only the three types. However, besides this "none", I wouldn't have an idea, how the server should indicate a disabled health-check, as resources[*].health_check is a mandatory object of type health_check.

==> looks like an API definition error.

[jensbaitingerbosch]

Thanks, it looks better with 0.5.0-beta2. Still getting another exception, I assume that there are no apps that exposes the metrics deployed yet in the space I configured. This issue can be closed.

[eaglerainbow]

Just for the record: The comment by @jensbaitingerbosch most likely should have gone into promregator/promregator#72 (comment) instead of this issue.

This issue can be closed.

I would like to still keep this issue open here, even though the situation is solved for @jensbaitingerbosch. Other users still might face the same trouble (and might not be able to upgrade to Promregator 0.5.0-rc2). But given the current state, it's fine to work on this topic with lower priority.

[jensbaitingerbosch]

Just for the records: The comment by @jensbaitingerbosch most likely should have gone into promregator/promregator#72 (comment) instead of this issue.

Ups, sorry

[twoseat]

@eaglerainbow Thanks for the report. My guess is the app is created using the v2 api - you'll see the options there are http, port, process, and none. Note that none is deprecated in favour of process, which probably answers your question about how to indicate that health-check is disabled.

In general the v3 apis are pretty relaxed about backwards compatibility. That will be fine once the whole world is v3, but until then it can cause problems such as this. While we try to follow the spec, we also allow for reality, so I'll add none to the list of allowed options (but would recommend the use of process!)

[eaglerainbow]

Sounds all good to me.
If it's even clear that none maps 1:1 to process, we could even consider to only allow none internally (i.e. on the wire), but the client maps to process when sent to the consuming application. With that we could prevent that the V3 interface gets blurred. And this kind of logic does not need to be implemented for each and every consumer. Just a thought....
As already mentioned: no urgency with this case here - the user already has an alternative solution, and no new user popped up so far.