Description
When running an workload that exposes some kind of service through a port automatically on boot, for example, a web server, it could be useful to further restrict the READY=YES reporting done by onegate by further checking whether the workload has finished binding to the port specified in the VM Template.
Instead of the VM reporting at the time the context service has finished execution, the report will be delayed until the port is up in the VM localhost address.
Use case
Make a stricter definition of the READY state which itself is already a stricter definition of the RUNNING state.
Interface Changes
A new variable ONEGATE_PORT_CHECK will be added within the CONTEXT section. This variable will hold the value of the port that will be checked by one-context. If such variable doesn't exist, then the behavior will be as usual.
Progress Status
[x] Code committed
[x] Testing - QA
[x] Documentation (Release notes - resolved issues, compatibility, known issues)
Description When running an workload that exposes some kind of service through a port automatically on boot, for example, a web server, it could be useful to further restrict the
READY=YESreporting done by onegate by further checking whether the workload has finished binding to the port specified in the VM Template.Instead of the VM reporting at the time the context service has finished execution, the report will be delayed until the port is up in the VM localhost address.
Use case Make a stricter definition of the READY state which itself is already a stricter definition of the RUNNING state.
Interface Changes A new variable
ONEGATE_PORT_CHECKwill be added within the CONTEXT section. This variable will hold the value of the port that will be checked byone-context. If such variable doesn't exist, then the behavior will be as usual.Progress Status