fix: adjust startup, liveness and readiness probes settings

[rm3l]

Description of the change

Startup probe settings seem to have been added in the upstream Backstage Chart
in [1], but the current settings do not allow the RHDH Chart for the
liveness probe to be triggered sufficiently enough for the app to be
considered live.
This adjust such settings by accounting for the worst case scenario
where the application might take a bit long to start.

This also aligns the probe endpoints with the upstream chart.

[1] backstage/charts#216

Existing or Associated Issue(s)

• Fixes https://issues.redhat.com/browse/RHIDP-5106
• Relates to https://issues.redhat.com/browse/RHIDP-4968

Additional Information

Checklist

• Chart version bumped in Chart.yaml according to semver.
• Variables are documented in the values.yaml and added to the README.md. The pre-commit utility can be used to generate the necessary content. Use pre-commit run -a to apply changes.
• JSON Schema template updated and re-generated the raw schema via pre-commit hook.
• List tests pass for Chart using the Chart Testing tool and the ct lint command.

[rm3l]

/uncc @kadel
/cc @PatAKnight @gustavolira

[rm3l]

/cherry-pick release-1.4

[openshift-cherrypick-robot]

@rm3l: once the present PR merges, I will cherry-pick it on top of release-1.4 in a new PR and assign it to you.

In response to this:

/cherry-pick release-1.4

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[kadel]

This fixes the problem that we have, but why not just remove the probe definitions from the RHDH sub-chart and rely on the inherited values from the upstream RHDH chart? I've tested them and it should work

[nickboldt]

when cherrypicking this to the release-1.4 branch we can safely update that chart from 2.23.0 to 2.23.1 as the 2.24.0 version was created when we branched for the 1.4.0 release.

so the same patch has to be applied to https://github.com/redhat-developer/rhdh-chart/blob/release-1.4/charts/backstage/Chart.yaml 2.23.0 -> 2.23.1

https://artifacthub.io/packages/helm/rhdh-chart/backstage

[rm3l]

This fixes the problem that we have, but why not just remove the probe definitions from the RHDH sub-chart and rely on the inherited values from the upstream RHDH chart? I've tested them and it should work

That was exactly the issue. The upstream chart defines the probes (including the startup probe) here, but the default thresholds and periods do not seem sufficient to cover the RHDH application.
Also note that this was also not always reproducible. On some clusters, it worked, but in some others, the startup probe didn't and the pod got restarted until it failed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[openshift-cherrypick-robot]

@rm3l: #50 failed to apply on top of branch "release-1.4":

Applying: Adjust startup, liveness and readiness probes settings
Applying: Update Chart version
Using index info to reconstruct a base tree...
M	charts/backstage/Chart.yaml
M	charts/backstage/README.md
Falling back to patching base and 3-way merge...
Auto-merging charts/backstage/README.md
CONFLICT (content): Merge conflict in charts/backstage/README.md
Auto-merging charts/backstage/Chart.yaml
CONFLICT (content): Merge conflict in charts/backstage/Chart.yaml
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0002 Update Chart version

In response to this:

/cherry-pick release-1.4

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.