Open Stack

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> 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>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> 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>
> Subject: Re: [openstack-dev] [heat] health maintenance in autoscaling
> groups
>
>  Doug Wiegley <dougw at a10networks.com> wrote on 07/23/2014 03:43:02 PM:
>
> > From: Doug Wiegley <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
> 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/20140723/c1707162/attachment.html>