Blocker Description of problem:
The healthCheck and readinessCheck dictionaries under each process in the discovery manifest are being populated with fields and defaults that don't always make sense in the context of the type of the check. For example for this sample manifest:
name: app1 buildpacks: - ruby_buildpack - java_buildpack env: VAR1: value1 VAR2: value2 routes: - route: route.example.com - route: another-route.example.com protocol: http2 services: - name: my-service1 - name: my-service2 - name: my-service-with-arbitrary-params binding_name: my-binding parameters: key1: value1 key2: value2 stack: cflinuxfs4 metadata: annotations: contact: "bob@example.com jane@example.com" labels: sensitive: true processes: - type: web command: start-web.sh disk_quota: 512M health-check-http-endpoint: /healthcheck health-check-type: http health-check-invocation-timeout: 10 instances: 3 memory: 500M log-rate-limit-per-second: 1KB timeout: 10 volume_mounts: - volume_id: web-volume mount_point: /app/data mode: ro - type: worker command: start-worker.sh disk_quota: 1G health-check-type: process instances: 2 memory: 256M log-rate-limit-per-second: 1KB timeout: 15 sidecars: - name: authenticator process_types: [ 'web', 'worker' ] command: bundle exec run-authenticator memory: 800M - name: upcaser process_types: [ 'worker' ] command: ./tr-server memory: 2G
For which the CLI generated the following discovery manifest:
name: app1 labels: sensitive: "true" annotations: contact: bob@example.com jane@example.com env: VAR1: value1 VAR2: value2 routes: - route: route.example.com - route: another-route.example.com protocol: http2 services: - name: my-service1 - name: my-service2 - name: my-service-with-arbitrary-params parameters: key1: value1 key2: value2 bindingName: my-binding processes: - type: web timeout: 10 command: start-web.sh disk: 512M memory: 500M healthCheck: endpoint: /healthcheck timeout: 10 interval: 30 type: http readinessCheck: endpoint: / timeout: 1 interval: 30 type: process instances: 3 logRateLimit: 1KB - type: worker timeout: 15 command: start-worker.sh disk: 1G memory: 256M healthCheck: endpoint: / timeout: 1 interval: 30 type: process readinessCheck: endpoint: / timeout: 1 interval: 30 type: process instances: 2 logRateLimit: 1KB sidecars: - name: authenticator processType: - web - worker command: bundle exec run-authenticator memory: 800 - name: upcaser processType: - worker command: ./tr-server memory: 2 stack: cflinuxfs4 timeout: 60 buildPacks: - ruby_buildpack - java_buildpack instances: 1
We can see fields like endpoint, timeout and interval being populated for the healthCheck and readinessCheck dictionaries under the worker process. As per https://docs.cloudfoundry.org/devguide/deploy-apps/manifest-attributes.html those fields don't make sense when the check type is process.
First of all, as per https://docs.cloudfoundry.org/devguide/deploy-apps/healthchecks.html, even if no health check or readiness check fields are present in the manifest, CF will create implicit checks using defaults:
Cloud Controller creates an LRP for Diego with the specified health check definitions. If no liveness health check is provided, Cloud Controller configures a port liveness health check type. If no readiness health check is provided, Cloud Controller configures a process readiness health check type.
That means the discovery manifest will always include healthCheck and readinessCheck dictionaries under each process, and it should populate them with default values when no explicit values are available in the manifest.
When the health-check-type field from the CF manifest is http, the healthCheck dictionary under the process should include the following fields:
- type (http)
- endpoint (defaults to /)
- invocationTimeout (defaults to 1)
- interval (defaults to 30)
- timeout (defaults to 60)
When the health-check-type field from the CF manifest is port, the healthCheck dictionary under the process should include the following fields:
- type (port)
- invocationTimeout (defaults to 1)
- interval (defaults to 30)
- timeout (defaults to 60)
When the health-check-type field from the CF manifest is process, the healthCheck dictionary under the process should include the following fields:
- type (process)
- timeout (defaults to 60)
When the readiness-check-type field from the CF manifest is http, the readinessCheck dictionary under the process should include the following fields:
- type (http)
- endpoint (defaults to /)
- invocationTimeout (defaults to 1)
- interval (defaults to 30)
When the readiness-check-type field from the CF manifest is port, the readinessCheck dictionary under the process should include the following fields:
- type (port)
- invocationTimeout (defaults to 1)
- interval (defaults to 30)
When the readiness-check-type field from the CF manifest is process, the readinessCheck dictionary under the process should include the following fields:
- type (process)
Version-Release number of selected component (if applicable):
kantra v0.8.0
Additional info:
None
- links to
-
RHBA-2025:150872
Migration Toolkit for Applications bug fix and enhancement update