[RFE] Per-server port for LBaaS Health Monitoring

[Matt Greene]

[Use-cases]
- Hierarchical health monitoring
The operator wants to monitor member health for the pool separately from application health.

- Micro-service deployment
An application is deployed as docker containers, which consume an ephemeral port.

[Limitations]
LBaaSv2 health monitor is attached to the pool, but will use the protocol-port set in the member object. Certain operators wish to monitor the health of the member (a.k.a member) separately, but in addition to the health of the service/application. This model limits the granularity at which the operator can gauge the health of their cloud.

[Enhancement]
Add an optional application port field in the member object. Default is <None>. Enhance health monitor creation with an optional parameter to use the service or application port. Default is <service port>.

[Armando Migliaccio (armando-migliaccio)]

We're in the process of winding down lbaas efforts into Neutron [1]. I think we're at a cut off point where new LBaaS requests should target Octavia. Let's raise this for discussion so that the drivers team can reach an agreement on the strategy on how to deal with these types of RFEs going forward.

[1] http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html

[Matt Greene (m-greene)]

Additional point of interest: An operator of a large OpenStack cloud, and customer of F5 Networks (my employer) requested this enhancement. We hope and expect to collaborate on design, implementation and upstream to the community. So this request should not be viewed purely as new burden on the neutron/lbaas teams. Their deployment and our implementation for LBaaSv2 are pre-Octavia, so discussion with the drivers team can hopefully identify a path for us to implement (in a fork) with migration path into Octavia.

[Michael Johnson (johnsom)]

Is this a duplicate to https://bugs.launchpad.net/octavia/+bug/1541579?

[Matt Greene (m-greene)]

Yes- it looks like the same RFE.