Koper, Dies <diesk@...>
Hi Nick, Eric,
I have confirmed that with the current CC release we could change the default behaviour on the CLI side without making additional API calls:
In the body of POST /v2/apps?async=true we simply add "health_check_type":"none" if the user specified “--no-route” and that seems to be accepted regardless whether the app defaults to DEA or Diego.
Can you confirm CC does not return an error on older CC versions (before the health_check_type attribute was introduced) if we add this attribute to the API request?
Also, can you confirm you definitely don’t want CC to change its default behaviour to align with what the user (and CLI) sees compared with Diego?
The current API sequence the CLI uses is:
1. POST /v2/apps?async=true – create app
2. POST /v2/routes?async=true&inline-relations-depth=1 – create route(s)
3. PUT /v2/apps/guid/routes/guid – map route(s)
4. PUT /v2/resource_match & PUT /v2/apps/guid/bits?async=true – upload app
5. GET /v2/jobs/guid – check its status
Although at step 1 CC would not know whether the app will get any routes (i.e. whether the user specified “--no-route”), at step 4 CC would, so it could toggle the health-check-type accordingly. Not sure how CC does this for apps deployed to DEA – is it the DEA backend that makes this decision at the timing of 4?
Cloud Foundry CLI PM
From: Nicholas Calugar [mailto:ncalugar(a)pivotal.io]
Sent: Thursday, May 12, 2016 4:34 AM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Re: Re: aligning cf push health-check default value
I spoke with Eric and he explained that this could be the desired UX for a majority of the apps pushed with --no-route. There are more advanced deployment strategies that might set --no-route and bind to routes later, but I think we can expect these users to be explicit with their health check as well. I think my discomfort with this arose when you mentioned to me that we might want to do this in the Cloud Controller. As long as this continues to be explicit from the API perspective, I'm fine with changing the UX of the CLI per your above proposal.
On Wed, May 4, 2016 at 1:13 PM, Shannon Coen <scoen(a)pivotal.io<mailto:scoen(a)pivotal.io>> wrote:
IMO the healthcheck of the app should be determined independently of whether a developer wants their app routable.
My understanding of the implications for you proposal are that a developer could not have a port-based healthcheck without mapping a route. This seems unnecessarily restrictive. Soon developers will be able to specify http healthchecks. Would these be prevented also?
Product Manager, Cloud Foundry
On Wed, May 4, 2016 at 12:26 PM, Nicholas Calugar <ncalugar(a)pivotal.io<mailto:ncalugar(a)pivotal.io>> wrote:
I considered this a bit more after we chatted yesterday and I don't think we should try to create parity between DEAs and Diego in this case. My personal opinion is that behavior should be explicit and these two flags provide a more correct experience with the Diego backend.
On Mon, Apr 25, 2016 at 6:09 PM, Koper, Dies <diesk(a)fast.au.fujitsu.com<mailto:diesk(a)fast.au.fujitsu.com>> wrote:
Hi CLI users,
With apps deployed to DEAs, a health check is performed at application start-up targeting the app’s port, unless you specified `--no-route`, in which case the process is monitored.
With Diego, the health check is performed continuously and the type of check was exposed through an option to the `cf push` command.
This option defaults to `port`, which isn't always appropriate for apps pushed without a route, such as worker apps.
We propose fixing the `--health-check-type` option’s default value to align with the behaviour seen for DEAs, i.e. to use “none” if option `--no-route` is used:
--health-check-type, -u Application health check type (Default: 'none' if '--no-route' is set, otherwise 'port')`
Would anyone object to such change?
Cloud Foundry CLI PM