Hi mike,
Awesome, thanks for chasing that down. Now I need to close the loop and figure
out where that linkage is, so I don't go crazy.
Thanks,
Doug
On Jul 24, 2014, at 10:06 PM, "Mike Spreitzer"
mailto:mspre...@us.ibm.com>> wrote:
Doug Wiegley mailto:do...@a10networks.com>> wrote on
07/23
Doug Wiegley wrote on 07/23/2014 11:24:32 PM:
> Hi Mike,
>
> > and listed the possible values of the status field, including
> "INACTIVE". Other sources are telling me that status=INACTIVE when
> the health monitor thinks the member is unhealthy, status!=INACTIVE
> when the health monitor th
ons)"
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 shou
quot;OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [heat] health maintenance in autoscaling groups
Stephen Balukoff mailto:sbaluk...@bluebox.net>> wrote on
07/23/2014 09:14:35 PM:
> It's
Stephen Balukoff wrote on 07/23/2014 09:14:35 PM:
> 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-- an
2:03 PM
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [heat] health maintenance in autoscaling
> groups
>
> Doug Wiegley wrote on 07/23/2014 03:43:02 PM:
>
&
rg>>
Subject: Re: [openstack-dev] [heat] health maintenance in autoscaling groups
Doug Wiegley mailto:do...@a10networks.com>> wrote on
07/23/2014 03:43:02 PM:
> From: Doug Wiegley mailto:do...@a10networks.com>>
> ...
> The state of the world today: ‘status’ in the n
Doug Wiegley wrote on 07/23/2014 03:43:02 PM:
> From: Doug Wiegley
> ...
> 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
st (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, July 23, 2014 at 1:27 PM
To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [heat] health mai
Doug Wiegley 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
balanc
Excerpts from Mike Spreitzer's message of 2014-07-18 10:38:32 -0700:
> Clint Byrum wrote on 07/18/2014 12:56:32 PM:
>
> > Excerpts from Mike Spreitzer's message of 2014-07-18 09:12:21 -0700:
> > > ...
> > > OK, let's work with these. My current view is this: supposing the
> > > Convergence work
Clint Byrum wrote on 07/18/2014 12:56:32 PM:
> Excerpts from Mike Spreitzer's message of 2014-07-18 09:12:21 -0700:
> > ...
> > OK, let's work with these. My current view is this: supposing the
> > Convergence work delivers monitoring of health according to a member's
> > status in its servic
Excerpts from Mike Spreitzer's message of 2014-07-18 09:12:21 -0700:
> Thomas Herve wrote on 07/17/2014 02:06:13 AM:
>
> > There are 4 resources related to neutron load balancing.
> > OS::Neutron::LoadBalancer is probably the least useful and the one
> > you can *not* use, as it's only there fo
Thomas Herve wrote on 07/17/2014 02:06:13 AM:
> There are 4 resources related to neutron load balancing.
> OS::Neutron::LoadBalancer is probably the least useful and the one
> you can *not* use, as it's only there for compatibility with
> AWS::AutoScaling::AutoScalingGroup. OS::Neutron::Health
> > >The check url is already a part of Neutron LBaaS IIRC.
>
> Yep. LBaaS is a work in progress, right?
You mean more than OpenStack in general? :) The LBaaS API in Neutron has been
working fine since Havana. It's certainly has shortcomings and it seems there
is a big refactoring in plan, tho
Doug Wiegley wrote on 07/16/2014 04:58:52 PM:
> On 7/16/14, 2:43 PM, "Clint Byrum" wrote:
>
> >Excerpts from Mike Spreitzer's message of 2014-07-16 10:50:42 -0700:
> ...
> >> I noticed that health checking in AWS goes beyond convergence. In
AWS
> >>an
> >> ELB can be configured with a URL to
On 7/16/14, 2:43 PM, "Clint Byrum" wrote:
>Excerpts from Mike Spreitzer's message of 2014-07-16 10:50:42 -0700:
>> Clint Byrum wrote on 07/02/2014 01:54:49 PM:
>>
>> > Excerpts from Qiming Teng's message of 2014-07-02 00:02:14 -0700:
>> > > Just some random thoughts below ...
>> > >
>> > > O
Excerpts from Mike Spreitzer's message of 2014-07-16 10:50:42 -0700:
> Clint Byrum wrote on 07/02/2014 01:54:49 PM:
>
> > Excerpts from Qiming Teng's message of 2014-07-02 00:02:14 -0700:
> > > Just some random thoughts below ...
> > >
> > > On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitz
Clint Byrum wrote on 07/02/2014 01:54:49 PM:
> Excerpts from Qiming Teng's message of 2014-07-02 00:02:14 -0700:
> > Just some random thoughts below ...
> >
> > On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:
> > > In AWS, an autoscaling group includes health maintenance
> funct
On Wed, Jul 02, 2014 at 10:54:49AM -0700, Clint Byrum wrote:
> Excerpts from Qiming Teng's message of 2014-07-02 00:02:14 -0700:
> > Just some random thoughts below ...
> >
> > On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:
> > > In AWS, an autoscaling group includes health mainte
On Wed, Jul 02, 2014 at 12:29:31PM -0400, Mike Spreitzer wrote:
> Qiming Teng wrote on 07/02/2014 03:02:14 AM:
>
> > Just some random thoughts below ...
> >
> > On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:
> > > ...
> > > I have not found design discussion of this; have I miss
On Wed, Jul 02, 2014 at 11:02:36AM +0100, Steven Hardy wrote:
> On Wed, Jul 02, 2014 at 03:02:14PM +0800, Qiming Teng wrote:
> > Just some random thoughts below ...
> >
> > On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:
> > > In AWS, an autoscaling group includes health maintenanc
On 02/07/14 02:41, Mike Spreitzer wrote:
Zane Bitter wrote on 07/01/2014 06:58:47 PM:
> On 01/07/14 15:47, Mike Spreitzer wrote:
> > In AWS, an autoscaling group includes health maintenance functionality
> > --- both an ability to detect basic forms of failures and an ability to
> > react p
Excerpts from Qiming Teng's message of 2014-07-02 00:02:14 -0700:
> Just some random thoughts below ...
>
> On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:
> > In AWS, an autoscaling group includes health maintenance functionality ---
> > both an ability to detect basic forms of f
Steven Hardy wrote on 07/02/2014 06:02:36 AM:
> On Wed, Jul 02, 2014 at 03:02:14PM +0800, Qiming Teng wrote:
> > Just some random thoughts below ...
> >
> > On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:
> > > ...
> >
> The resource signal interface used by ceilometer can carry
Qiming Teng wrote on 07/02/2014 03:02:14 AM:
> Just some random thoughts below ...
>
> On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:
> > ...
> > I have not found design discussion of this; have I missed something?
> >
> > I suppose the natural answer for OpenStack would be cen
Mike Spreitzer/Watson/IBM@IBMUS wrote on 07/02/2014 02:41:48 AM:
> Zane Bitter wrote on 07/01/2014 06:58:47 PM:
>
> > On 01/07/14 15:47, Mike Spreitzer wrote:
> > > In AWS, an autoscaling group includes health maintenance
functionality
> > > --- both an ability to detect basic forms of failures
On Wed, Jul 02, 2014 at 03:02:14PM +0800, Qiming Teng wrote:
> Just some random thoughts below ...
>
> On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:
> > In AWS, an autoscaling group includes health maintenance functionality ---
> > both an ability to detect basic forms of failur
Just some random thoughts below ...
On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:
> In AWS, an autoscaling group includes health maintenance functionality ---
> both an ability to detect basic forms of failures and an ability to react
> properly to failures detected by itself o
Zane Bitter wrote on 07/01/2014 06:58:47 PM:
> On 01/07/14 15:47, Mike Spreitzer wrote:
> > In AWS, an autoscaling group includes health maintenance functionality
> > --- both an ability to detect basic forms of failures and an ability
to
> > react properly to failures detected by itself or by a
On 01/07/14 15:47, Mike Spreitzer wrote:
In AWS, an autoscaling group includes health maintenance functionality
--- both an ability to detect basic forms of failures and an ability to
react properly to failures detected by itself or by a load balancer.
What is the thinking about how to get this
In AWS, an autoscaling group includes health maintenance functionality ---
both an ability to detect basic forms of failures and an ability to react
properly to failures detected by itself or by a load balancer. What is
the thinking about how to get this functionality in OpenStack? Since
Open
32 matches
Mail list logo
