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 <sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, July 23, 2014 at 7:14 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@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 <do...@a10networks.com<mailto:do...@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 <mspre...@us.ibm.com<mailto:mspre...@us.ibm.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, July 23, 2014 at 2:03 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [heat] health maintenance in autoscaling groups Doug Wiegley <do...@a10networks.com<mailto:do...@a10networks.com>> wrote on 07/23/2014 03:43:02 PM: > From: Doug Wiegley <do...@a10networks.com<mailto:do...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
