LBaaS Alternative Monitoring IP/Port

https://blueprints.launchpad.net/octavia/+spec/lbaas-health-monitoring-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.

Alternatives

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
Method URI
POST /v2.0/lbaas/pools/{pool_id}/members
PUT /v2.0/lbaas/pools/{pool_id}/members/{member_id}
GET /v2.0/lbaas/pools/{pool_id}/members/{member_id}

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 Type Access Default Value Validation Conversion Description
monitor_port int RW, all null int health check port (optional)
monitor_address string RW, all null types.IPAddressType() health check IP address (optional)

Security impact

None

Notifications impact

None

Other end user impact

None

Performance Impact

None

Other deployer impact

None

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.

Implementation

Assignee(s)

Primary assignee:
a.amerine
Other contributors:
None

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

Dependencies

None

Testing

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.

References