<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div><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>
</div>
<div><br>
</div>
<div>The state of the world today: ‘status’ in the neutron database is configuration/provisioning status,
<span style="font-weight: bold;">not</span> operational status. Neutron-wide thing. We were discussing adding operational status fields (or a neutron REST call to get the info from the backend) last month, but it’s something that isn’t planned for a serious
conversation until Kilo, at present.</div>
<div><br>
</div>
<div>The current possible lbaas values (from neutron/plugins/common/constants.py):</div>
<div><br>
</div>
<div>
<div># Service operation status constants</div>
<div>ACTIVE = "ACTIVE"</div>
<div>DOWN = "DOWN"</div>
<div>PENDING_CREATE = "PENDING_CREATE"</div>
<div>PENDING_UPDATE = "PENDING_UPDATE"</div>
<div>PENDING_DELETE = "PENDING_DELETE"</div>
<div>INACTIVE = "INACTIVE"</div>
<div>ERROR = "ERROR"</div>
</div>
<div><br>
</div>
<div>… It does look like you can make a stats() call for some backends and get limited operational information, but it will not be uniform, nor universally supported.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>doug</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Mike Spreitzer <<a href="mailto:mspreitz@us.ibm.com">mspreitz@us.ibm.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, July 23, 2014 at 1:27 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [heat] health maintenance in autoscaling groups<br>
</div>
<div><br>
</div>
<div>
<div><tt><font size="2">Doug Wiegley <<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>> 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></div>
</div>
</span>
</body>
</html>