Introduce health-check-interval parameter for liveness probe#1850
Closed
IvanBorislavovDimitrov wants to merge 8 commits into
Closed
Introduce health-check-interval parameter for liveness probe#1850IvanBorislavovDimitrov wants to merge 8 commits into
IvanBorislavovDimitrov wants to merge 8 commits into
Conversation
Surface a new MTA module parameter `health-check-interval` (Integer, seconds) that controls the liveness health-check interval for a CF application. Mirrors the existing `readiness-health-check-interval` end-to-end: - New SupportedParameters constant registered in MODULE_PARAMETERS. - StagingParametersParser reads the value and forwards it through the ImmutableStaging builder. - Staging interface and CloudProcess gain a getHealthCheckInterval() accessor; Immutables regenerates the builders. - CloudControllerRestClientImpl.buildHealthCheck forwards the value via Data.builder().interval(...) so the CF API call carries it. - RawCloudProcess populates the new field from healthCheckData.getInterval() so updates round-trip correctly. - HealthCheckInfo carries the new field so StagingApplicationAttributeUpdater detects redeploys that change only the liveness interval. - Parser unit tests cover both present and absent cases. Behaviour is fully additive: omitting the parameter is byte-for-byte identical to the pre-change baseline. JIRA:LMCROSSITXSADEPLOY-3316
Extend the existing parameterized drift-detection test with two rows that exercise the new liveness interval field: one where the value changes between existing and new staging (should trigger an update) and one where it matches (should not). Plumb the value through prepareClient so the mocked getApplicationProcess echoes the configured interval back. JIRA:LMCROSSITXSADEPLOY-3316
Cover the new RawCloudProcess#derive branch that copies the liveness health check interval from the cf-java-client Data into the derived CloudProcess. Three cases: explicit interval is propagated, absent interval surfaces as null, and a HealthCheck with null Data does not NPE and yields a null interval. JIRA:LMCROSSITXSADEPLOY-3316
JIRA:LMCROSSITXSADEPLOY-3316
Adds an explicit guard in StagingParametersParser that throws a ContentException with a clear message when health-check-interval is zero or negative, plus tests covering both rejection cases. JIRA:LMCROSSITXSADEPLOY-3316
Adds a boundary case for health-check-interval=1 to lock in the inclusive-zero exclusion enforced by StagingParametersParser. JIRA:LMCROSSITXSADEPLOY-3316
Remove the parser-side rejection of zero/negative health-check-interval values to keep parity with healthCheckTimeout and readinessHealthCheckInterval, which forward any non-null Integer to the Cloud Controller without validation. The CF Java client and Cloud Controller remain the source of truth for value validity. JIRA:LMCROSSITXSADEPLOY-3316
Extend AdditionalModuleParametersReporter to log a separate line when a module specifies the new health-check-interval (liveness) parameter. The existing readiness log line is left untouched because it is observed by Dynatrace. Add a package-private constructor that accepts a Logger so the new liveness branch is verifiable in unit tests; the public constructor delegates to it with the static SLF4J logger. JIRA:LMCROSSITXSADEPLOY-3316
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds support for the
health-check-intervalMTA module parameter, bringing feature parity with native Cloud Foundry. Application descriptors can now configure the interval (in seconds) between liveness health-check probes.The parameter was previously not exposable through MTA because the underlying CF Java client did not surface it; recent client versions do, so this change wires it through the controller.
What changed
multiapps-controller-client
StagingandHealthCheckInfocarry the newhealthCheckIntervalfield.RawCloudProcessround-trips the field when adapting the CF client'sProcessresource.CloudControllerRestClientImplforwards the value to the CF Java client when staging an app.multiapps-controller-core
SupportedParametersregistershealth-check-intervalso it is recognised at parse time.StagingParametersParserreads the parameter and rejects non-positive values.multiapps-controller-process
AdditionalModuleParametersReporterincludes the parameter in usage telemetry.CreateOrUpdateAppStepnow triggers an update when the interval changes.Tests
RawCloudProcessTestHealthCheckInfoTestStagingParametersParserTestAdditionalModuleParametersReporterTestCreateOrUpdateStepWithExistingAppTestVerified locally with:
Tracking
JIRA:LMCROSSITXSADEPLOY-3316