Open Stack

Though, this is probably a good time to talk requirements, and to start thinking about whether this is an lbaas issue, or an advanced services (*aaS) issue, so we can have some useful discussions at the summit, and not solve this scaling metrics problem 8 different ways.

Doug


From: Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>>
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 7:14 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

It's probably worth pointing out that most of the Neutron LBaaS team are spending most of our time doing a major revision to Neutron LBaaS. How stats processing should happen has definitely been discussed but not resolved at present-- and in any case it was apparent to those working on the project that it has secondary importance compared to the revision work presently underway.

I personally would like to have queries about most objects in the stats API to Neutron LBaaS return a dictionary or statuses for child objects which then a UI or auto-scaling system can interpret however it wishes. Your points are certainly well made, and I agree that it might also be useful to inject status information externally, or have some kind of hook there to get event notifications when individual member statuses change. But this is really a discussion that needs to happen once the current code drive is near fruition (ie. for Kilo).

Stephen


On Wed, Jul 23, 2014 at 1:27 PM, Doug Wiegley <dougw at a10networks.com<mailto:dougw at a10networks.com>> wrote:
Great question, and to my knowledge, not at present.  There is an ongoing discussion about a common usage framework for ceilometer, for all the various *aaS things, but status I not included (yet!).  I think that spec is in gerrit.

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 2:03 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/23/2014 03:43:02 PM:

> From: Doug Wiegley <dougw at a10networks.com<mailto:dougw at a10networks.com>>
> ...
> 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.

Thanks for the prompt response.  Let me just grasp at one last straw: is there any chance that Neutron will soon define and implement Ceilometer metrics that reveal PoolMember health?

Thanks,
Mike

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140724/f9fe80e3/attachment.html>