<tt><font size=2>Doug Wiegley <dougw@a10networks.com> wrote on 07/16/2014
04:58:52 PM:<br>
<br>
> You do recall correctly, and there are currently no mechanisms for<br>
> notifying anything outside of the load balancer backend when the health<br>
> monitor/member state changes.</font></tt>
<br>
<br><tt><font size=2>But there *is* a mechanism for some outside thing
to query the load balancer for the health of a pool member, right?  I
am thinking specifically of </font></tt><a href="http://docs.openstack.org/api/openstack-network/2.0/content/GET_showMember__v2.0_pools__pool_id__members__member_id__lbaas_ext_ops_member.html"><tt><font size=2>http://docs.openstack.org/api/openstack-network/2.0/content/GET_showMember__v2.0_pools__pool_id__members__member_id__lbaas_ext_ops_member.html</font></tt></a><tt><font size=2>
--- whose response includes a "status" field for the member.
 Is there documentation for what values can appear in that field,
and what each value means?</font></tt>
<br><tt><font size=2><br>
Supposing we can leverage the pool member status, there remains an issue:
establishing a link between an OS::Neutron::PoolMember and the corresponding
scaling group member.  We could conceivably expand the scaling group
code so that if the member type is a stack then the contents of the stack
are searched (perhaps recursively) for resources of type OS::Neutron::PoolMember,
but that is a tad too automatic for my taste.  It could pick up irrelevant
PoolMembers.  And such a level of implicit behavior is outside our
normal style of doing things.</font></tt>
<br>
<br><tt><font size=2>We could follow the AWS style, by adding an optional
property to the scaling group resource types --- where the value of that
property can be the UUID of an OS::Neutron::LoadBalancer or an OS::Neutron::Pool.
 But that still does not link up an individual scaling group member
with its corresponding PoolMember.</font></tt>
<br>
<br><tt><font size=2>Remember that if we are doing this at all, each scaling
group member must be a stack.  I think the simplest way to solve this
would be to define a way that a such stack can put in its outputs the ID
of the corresponding PoolMember.  I would be willing to settle for
simply saying that if such a stack has an output of type string and name
"__OS_pool_member" then the value of that output is taken to
be the ID of the corresponding PoolMember.  Some people do not like
reserved names; if that must be avoided then we can expand the schema language
with a way to identify which stack output carries the PoolMember ID.  Another
alternative would be to add an optional scaling group property to carry
the name of the stack output in question.</font></tt>
<br><tt><font size=2><br>
> There is also currently no way for an external system to inject health<br>
> information about an LB or its members.<br>
</font></tt>
<br><tt><font size=2>I do not know that the injection has to be to the
LB; in AWS the injection is to the scaling group.  That would be acceptable
to me too.</font></tt>
<br>
<br><tt><font size=2>Thoughts?</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>