This change adds a new field in the route_registrar job's health-check object in its spec file: additional_bpm_mount_paths. Using this array of strings, the route_registrar job users can specify additional directories to be mounted in the bpm config yaml of the job. This is needed because sometimes the access to /var/vcap/job and /var/vcap/data/ directories of a specific job is not sufficient for a healthcheck script to run.
What type of change is this?
[ ] [Breaking Change]: the change removes a feature or introduces a behavior change to core functionality (request routing, request logging)
[x] [Minor Feature/Improvement]: the change introduces a new feature or improvement that doesn't alter core behavior
[ ] [Bug Fix]: the change addresses a defect
If you have selected multiple of the above, it may be wise to consider splitting this PR into multiple PRs to decrease the time for minor changes + bugs to be resolved.
Backwards Compatibility
The change is backwards compatible. No existing deployments configuration should break due to this change.
I don't think it should be considered experimental for some period. I think it should go in next major/minor release.
This doesn't need to apply immediately to all routing-release deployments.
How should this be tested?
Are there any non-automated tests that should be performed against this change for validation? Please provide steps, and expected results for before + after the change.
Additional Context
Please provide any additional links or context (issues, other PRs, Slack discussions) to help understand this change.
PR Checklist
[ ] I have viewed, signed, and submitted the Contributor License Agreement.
[x] I have made this pull request to the develop branch.
What is this change about?
This change adds a new field in the
route_registrar
job'shealth-check
object in its spec file:additional_bpm_mount_paths
. Using this array of strings, theroute_registrar
job users can specify additional directories to be mounted in the bpm config yaml of the job. This is needed because sometimes the access to/var/vcap/job
and/var/vcap/data/
directories of a specific job is not sufficient for a healthcheck script to run.What type of change is this?
[Breaking Change]
: the change removes a feature or introduces a behavior change to core functionality (request routing, request logging)[Minor Feature/Improvement]
: the change introduces a new feature or improvement that doesn't alter core behavior[Bug Fix]
: the change addresses a defectIf you have selected multiple of the above, it may be wise to consider splitting this PR into multiple PRs to decrease the time for minor changes + bugs to be resolved.
Backwards Compatibility
The change is backwards compatible. No existing deployments configuration should break due to this change.
I don't think it should be considered experimental for some period. I think it should go in next major/minor release. This doesn't need to apply immediately to all routing-release deployments.
How should this be tested?
Are there any non-automated tests that should be performed against this change for validation? Please provide steps, and expected results for before + after the change.
Additional Context
Please provide any additional links or context (issues, other PRs, Slack discussions) to help understand this change.
PR Checklist
develop
branch.