LBaaS Alternative Monitoring IP/Port

In the current state, the health monitor IP address/port pair is derived from a load balancer’s pool member’s address and protocol port. In some use cases it would be desirable to monitor a different IP address/port pair for the health of a load balanced pool’s member than the already specified address and protocol port. Due to the current state this is not possible.

Problem description

The use case where this would be desirable would be when the End User is making the health monitor application on the member available on a IP/port that is mutually exclusive to the IP/port of the application that is being load balanced on the member. The End User would find this advantageous when attempting to limit access to health diagnostic information by not allowing it to be served over the main ingress IP/port of their application.

Beyond limiting access to any health APIs, it allows the End Users to design different methods of health monitoring, such as creating distinct daemons responsible for the health of their hosts applications.

Proposed change

The creation of a pool member would now allow the specification of an IP address and port to monitor health. The process used to assess the health of pool members would now use this new IP address and port to diagnose the member.

If a health monitor IP address or port is not specified the default behavior would be to use the IP address and port specified by the member.

There would likely need to be some Horizon changes to support this feature, however by maintaining the old behavior as the default we will not create a strong dependency.


An alternative is to not allow this functionality, and force all End Users to ensure their health checks are available over the member’s load balanced IP address and protocol port.

As stated in the Problem Description this would force End Users to provide additional security around their health diagnostic information so that they do not expose it to unintended audiences. Pushing this requirement on the End User is a heavier burden and limits their configuration options of the applications they run on Openstack that are load balanced.

Data model impact

The Member data model would gain two new member fields called monitor_port and monitor_address. These two member fields would store the port and IP address, respectively, that the monitor will query for the health of the load balancer’s listener’s pool member.

It is important to have the default behavior fall back on the address and protocol port of the member as this will allow any migrations to not break existing deployments of Openstack.

Any Member data models without this new feature would have the fields default to the value of null to signify that Octavia’s LBaaS service should use the member’s protocol port to assess health status.

REST API impact

There are two APIs that will need to be modified, only slightly, to facilitate this change.

Octavia LBaaS APIs









The POST and PUT calls will need two additional fields added to their JSON body data for the request and the JSON response data.

The GET call will need two additional fields as well, however they would only be added to the JSON response data.

The fields to be added to each is:

Added Fields

Attribute Name



Default Value

Validation Conversion




RW, all



health check port (optional)



RW, all



health check IP address (optional)

Security impact


Notifications impact


Other end user impact


Performance Impact


Other deployer impact


Developer impact

Other plugins do not have to implement this feature as it is optional due to the default behavior. If they decide to implement this feature, they would just need to supply the protocol port in their POSTs and PUTs to the health monitor APIs.



Primary assignee:


Other contributors:


Work Items

  • Alter the Member Data Model

  • Alter Pool Member APIs

  • Update API reference documentation to reflect changes

  • Write or Alter Unit, Functional, and Tempest Tests to verify new functionality




Integration tests can be written to verify functionality. Generally, it should only require an existing Openstack deployment that is running LBaaS to verify health checks.

Documentation Impact

The REST API impact will need to be addressed in documentation so developers moving forward know about the feature and can use it.