Hi Dies,

The CC doesn't see these as steps of a push, they are all distinct API
requests. We cannot make decisions based on previous requests or lack
thereof, it has to be done in the CLI.

Based on a quick test, unknown fields are ignored in POST bodies in V2, so
you can send "health_check_type":"none" on older CC versions.


Thanks,

Nick

On Sun, May 15, 2016 at 5:23 PM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

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?



Regards,

Dies Koper
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



Hi Dies,



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.





Thanks,



Nick



On Wed, May 4, 2016 at 1:13 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi Dies,



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?



Best,


Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.



On Wed, May 4, 2016 at 12:26 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi Dies,



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.





Thanks,



Nick



On Mon, Apr 25, 2016 at 6:09 PM, Koper, Dies <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?



Cheers,

Dies Koper
Cloud Foundry CLI PM