[LMCROSSITXSADEPLOY-3316] Introduce health-check-interval module parameter#1852
Closed
IvanBorislavovDimitrov wants to merge 4 commits into
Closed
[LMCROSSITXSADEPLOY-3316] Introduce health-check-interval module parameter#1852IvanBorislavovDimitrov wants to merge 4 commits into
IvanBorislavovDimitrov wants to merge 4 commits into
Conversation
Wires a new optional Integer module parameter `health-check-interval` through the client/core layer in parallel with the existing readiness-health-check-interval. Touched layers: - SupportedParameters: declare HEALTH_CHECK_INTERVAL constant and register it in MODULE_PARAMETERS. - StagingParametersParser: read the descriptor entry and populate Staging.healthCheckInterval. - Staging / CloudProcess: expose @nullable Integer accessors so both the desired and existing-app sides of staging-change comparison carry the field. - RawCloudProcess: harvest the value from HealthCheck.getData().getInterval(). - CloudControllerRestClientImpl#buildHealthCheck: forward the value via Data.builder().interval(...). The cf-java-client setter ignores null, so omitting the parameter produces a byte-identical request. - HealthCheckInfo: add the field to the value object compared by StagingApplicationAttributeUpdater so an interval-only change triggers a staging update; also adds the missing hashCode override. JIRA:LMCROSSITXSADEPLOY-3316
Extends AdditionalModuleParametersReporter to surface the liveness health-check family (type, http endpoint, timeout, invocation timeout, interval) when any of those parameters is present on a module — in parallel with the existing readiness reporting. The new reportUsageOfHealthCheckParameters method mirrors the readiness method verbatim and is intentionally kept as a sibling rather than refactored into a generic helper (rule of three has not been met). Wording is the same MessageFormat shape as the readiness log line, substituting "readiness health check parameters" with "health check parameters" so existing Dynatrace observability on the readiness line is unaffected. JIRA:LMCROSSITXSADEPLOY-3316
- CloudModelBuilderTest fixtures: add health-check-interval to two mtad-health-check-*.yaml inputs and the matching expected JSON outputs (port=30, http-with-endpoint=45). The third http-without-endpoint case is left without the parameter to keep the "omitted -> null" assertion case intact. - ApplicationsCloudControllerClientIntegrationTest: set healthCheckInterval on the staging used in the createApplication test, then assert the value round-trips through the controller via CloudProcess.getHealthCheckInterval(). New constant HEALTH_CHECK_INTERVAL=60 added to IntegrationTestConstants. - CreateOrUpdateStepWithExistingAppTest: add a parameterized row whose only delta between old and new staging is healthCheckInterval, and propagate the field through the mocked CloudProcess so equality comparison sees both sides; verifies an interval-only change drives StagingApplicationAttributeUpdater to update. - ReadinessHealthCheckUtilTest: new test asserting that setting healthCheckInterval alone (without any readiness parameter) does NOT flip the readiness gate (FR-7-style guarantee). - RestartAppStepTest, PollStartAppStatusExecutionTest, PrepareToStopDependentModuleStepTest: propagate the new field through their existing Staging literals. - AdditionalModuleParametersReporterTest (new): three focused tests asserting that the reporter (a) handles a module declaring only health-check-interval, (b) handles the full liveness family, and (c) handles a module with no health-check parameters at all, without throwing. JIRA:LMCROSSITXSADEPLOY-3316
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, achieving feature parity with Cloud Foundry's liveness health-check interval setting. End users can now author MTAs like:The interval is parsed from the descriptor, propagated through the
Stagingimmutable, sent to the controller via the CF Java client, harvested back intoCloudProcessfor diagnostics, and surfaced in the additional-module-parameters reporter alongside the existing health-check fields.Jira
Changes by module
StaginggainsgetHealthCheckInterval().RawCloudProcessharvests the interval;CloudProcessexposes it.CloudControllerRestClientImplforwards it on app create/update.HealthCheckInfoextended with the new field plus updatedhashCode/ equality.SupportedParameters.HEALTH_CHECK_INTERVALconstant added.StagingParametersParserreads the parameter intoStaging.apps-with-health-check-type-*.json,mtad-health-check-type-*.yaml) updated.AdditionalModuleParametersReporterreports the liveness interval.CreateOrUpdateStepWithExistingAppTest,PollStartAppStatusExecutionTest,PrepareToStopDependentModuleStepTest,RestartAppStepTest) andReadinessHealthCheckUtilTestextended to cover the new field.Tests
multiapps-controller-client/.../HealthCheckInfoTest(11 cases) — round-trips the interval through the immutable, exercises null handling and equality.multiapps-controller-core/.../StagingParametersParserTest(+2 cases) — interval parsing happy-path and absent-value path.AdditionalModuleParametersReporterTest(3 cases on the new liveness-reporter path),CloudModelBuilderTestfixtures,ApplicationsCloudControllerClientIntegrationTest.mvn -pl multiapps-controller-client -am test -Dtest=HealthCheckInfoTest && mvn -pl multiapps-controller-core -am test -Dtest=StagingParametersParserTest -Dsurefire.failIfNoSpecifiedTests=falseNotes
Add unit tests for health-check-intervalwas assembled by the PR agent from staged test files left on the branch; production code was untouched.