Open Stack

> 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 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 --- 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?

The state of the world today: ‘status’ in the neutron database is configuration/provisioning status, not 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.

The current possible lbaas values (from neutron/plugins/common/constants.py):

# Service operation status constants
ACTIVE = "ACTIVE"
DOWN = "DOWN"
PENDING_CREATE = "PENDING_CREATE"
PENDING_UPDATE = "PENDING_UPDATE"
PENDING_DELETE = "PENDING_DELETE"
INACTIVE = "INACTIVE"
ERROR = "ERROR"

… 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.

Thanks,
doug

From: Mike Spreitzer <mspreitz at us.ibm.com<mailto:mspreitz at us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, July 23, 2014 at 1:27 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [heat] health maintenance in autoscaling groups

Doug Wiegley <dougw at a10networks.com<mailto:dougw at a10networks.com>> wrote on 07/16/2014 04:58:52 PM:

> You do recall correctly, and there are currently no mechanisms for
> notifying anything outside of the load balancer backend when the health
> monitor/member state changes.

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 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 --- 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?

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.

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.

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.

> There is also currently no way for an external system to inject health
> information about an LB or its members.

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.

Thoughts?

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/1d8c612a/attachment.html>