>>> - Original Message -
>>>>> From: "Yan Gao"
>>>>> To: pacemaker@oss.clusterlabs.org
>>>>> Sent: Monday, January 21, 2013 11:28:40 PM
>>>>> Subject: Re: [Pacemaker] Enable remote monitoring
>>>>>
- Original Message -
> From: "Andrew Beekhof"
> To: "The Pacemaker cluster resource manager"
> Sent: Tuesday, February 5, 2013 2:29:11 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> On Fri, Feb 1, 2013 at 3:37 PM, Gao,Yan wrote:
&g
"
>>>> To: pacemaker@oss.clusterlabs.org
>>>> Sent: Monday, January 21, 2013 11:28:40 PM
>>>> Subject: Re: [Pacemaker] Enable remote monitoring
>>>>
>>>> Hi,
>>>> Here's the code for supporting nagios plugins in lrmd:
>
- Original Message -
> From: "Yan Gao"
> To: pacemaker@oss.clusterlabs.org
> Sent: Thursday, January 31, 2013 10:37:53 PM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> Hi Andrew,
>
> On 01/31/13 14:35, Andrew Beekhof wrote:
> >
>
Hi Andrew,
On 01/31/13 14:35, Andrew Beekhof wrote:
>
> On 24/01/2013, at 3:36 AM, David Vossel wrote:
>
>>
>>
>> - Original Message -
>>> From: "Yan Gao"
>>> To: pacemaker@oss.clusterlabs.org
>>> Sent: Monday, January
On 24/01/2013, at 3:36 AM, David Vossel wrote:
>
>
> - Original Message -
>> From: "Yan Gao"
>> To: pacemaker@oss.clusterlabs.org
>> Sent: Monday, January 21, 2013 11:28:40 PM
>> Subject: Re: [Pacemaker] Enable remote monitoring
>>
Hi Lars,
On 01/24/13 04:20, Lars Marowsky-Bree wrote:
> On 2013-01-23T11:36:10, David Vossel wrote:
>
>>> - probe: A resource defined for a resource container is not probed.
>>> (We can also add a condition in pengine to just avoid probing a
>>> nagios class resource.)
>> Yeah, I think the pengi
Hi David,
Thanks for the comments!
On 01/24/13 00:36, David Vossel wrote:
>
>
> - Original Message -
>> From: "Yan Gao"
>> To: pacemaker@oss.clusterlabs.org
>> Sent: Monday, January 21, 2013 11:28:40 PM
>> Subject: Re: [Pacemaker] Enable rem
On 2013-01-23T11:36:10, David Vossel wrote:
> > - probe: A resource defined for a resource container is not probed.
> > (We can also add a condition in pengine to just avoid probing a
> > nagios class resource.)
> Yeah, I think the pengine should know to never probe a nagios script
> regardless i
- Original Message -
> From: "Yan Gao"
> To: pacemaker@oss.clusterlabs.org
> Sent: Monday, January 21, 2013 11:28:40 PM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> Hi,
> Here's the code for supporting nagios plugins in lrmd:
>
> ht
Hi,
Here's the code for supporting nagios plugins in lrmd:
https://github.com/gao-yan/pacemaker/commits/nagios
A new resource class "nagios" is introduced.
Actions:
- probe: A resource defined for a resource container is not probed. (We
can also add a condition in pengine to just avoid probing
On 12/12/12 17:51, Lars Marowsky-Bree wrote:
> On 2012-12-11T12:53:39, David Vossel wrote:
>
> Excellent progress!
>
> Just one aspect caught my eye:
>
>>> - on-fail defaults "restart-container" for most actions,
>>>
>>> except for stop op (Not sure what it means if a stop fails. A
>>> nagi
On 2012-12-11T12:53:39, David Vossel wrote:
Excellent progress!
Just one aspect caught my eye:
> > - on-fail defaults "restart-container" for most actions,
> >
> > except for stop op (Not sure what it means if a stop fails. A
> > nagios
> > daemon cannot be terminated? Should it always retu
On 12/12/12 15:38, Gao,Yan wrote:
> On 12/12/12 11:14, Gao,Yan wrote:
>> On 12/12/12 01:53, David Vossel wrote:
>>> - Original Message -
>>>> From: "Yan Gao"
>>>> To: pacemaker@oss.clusterlabs.org
>>>> Sent: Tuesday, December
On 12/12/12 11:14, Gao,Yan wrote:
> On 12/12/12 01:53, David Vossel wrote:
>> - Original Message -
>>> From: "Yan Gao"
>>> To: pacemaker@oss.clusterlabs.org
>>> Sent: Tuesday, December 11, 2012 1:23:03 AM
>>> Subject: Re: [Pacemak
On 12/12/12 01:53, David Vossel wrote:
> - Original Message -
>> From: "Yan Gao"
>> To: pacemaker@oss.clusterlabs.org
>> Sent: Tuesday, December 11, 2012 1:23:03 AM
>> Subject: Re: [Pacemaker] Enable remote monitoring
>>
>> Hi,
>>
On Wed, Dec 12, 2012 at 4:53 AM, David Vossel wrote:
> - Original Message -
>> From: "Yan Gao"
>> To: pacemaker@oss.clusterlabs.org
>> Sent: Tuesday, December 11, 2012 1:23:03 AM
>> Subject: Re: [Pacemaker] Enable remote monitoring
>>
- Original Message -
> From: "Yan Gao"
> To: pacemaker@oss.clusterlabs.org
> Sent: Tuesday, December 11, 2012 1:23:03 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> Hi,
> Here's the latest code:
> http
Hi,
Here's the latest code:
https://github.com/gao-yan/pacemaker/commit/4d58026c2171c42385c85162a0656c44b37fa7e8
Now:
- container-type:
* black - ordering, colocating
* white - ordering
Both them are not probed so far.
- on-fail defaults "restart-container" for most actions,
except for s
On 2012-12-07T10:47:08, David Vossel wrote:
> > blackbox - colocated on the node where the container is running
> >- not probed
>
> this makes sense to me.
>
> > whitebox - colocated on the virtual node provided by the container
> >- probed only there
>
> I'm not sure a
On Sun, Dec 9, 2012 at 3:05 PM, Gao,Yan wrote:
> On 12/07/12 23:47, David Vossel wrote:
>>
>>
>> - Original Message -
>>> From: "Lars Marowsky-Bree"
>>> To: "The Pacemaker cluster resource manager"
>>> Sent: Friday, De
On 12/07/12 23:47, David Vossel wrote:
>
>
> - Original Message -
>> From: "Lars Marowsky-Bree"
>> To: "The Pacemaker cluster resource manager"
>> Sent: Friday, December 7, 2012 5:23:07 AM
>> Subject: Re: [Pacemaker] Enable remote mo
- Original Message -
> From: "Lars Marowsky-Bree"
> To: "The Pacemaker cluster resource manager"
> Sent: Friday, December 7, 2012 5:23:07 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> On 2012-12-07T10:38:44, Andrew Beekhof wrote:
On 2012-12-07T15:09:09, Andrew Beekhof wrote:
> >> Ordering: absolutely
> > Would any user not like the implied order? Instead want an asymmetrical
> > or some curious one?
> Conceptually it doesn't make any sense IMHO.
> By definition things cant be in/on the container if the container
> doesn't
On 2012-12-07T10:38:44, Andrew Beekhof wrote:
> > Uhm. Would "container" imply ordering + colocation, or would we still
> > need them grouped (resource_set'ed, whatever)?
> Ordering: absolutely
> Colocation is less clear, I think the default is no but David has suggested
> an additional meta att
On 2012-12-07T20:17:03, Andrew Beekhof wrote:
> >> The one thing we've not addressed yet is probing, thats going to be fun :)
> > I guess there should be some way for the nagios RAs to return
> > NOT_RUNNING if there's nothing yet, no?
> Right, but its talking to an IP address.
> Once the guest i
On Fri, Dec 7, 2012 at 3:19 PM, Gao,Yan wrote:
> On 12/07/12 12:09, Andrew Beekhof wrote:
>> On Fri, Dec 7, 2012 at 3:00 PM, Gao,Yan wrote:
>>> On 12/07/12 07:38, Andrew Beekhof wrote:
On 06/12/2012, at 10:42 PM, Lars Marowsky-Bree wrote:
> On 2012-12-06T22:25:40, Andrew Beekh
On 12/07/12 12:09, Andrew Beekhof wrote:
> On Fri, Dec 7, 2012 at 3:00 PM, Gao,Yan wrote:
>> On 12/07/12 07:38, Andrew Beekhof wrote:
>>>
>>> On 06/12/2012, at 10:42 PM, Lars Marowsky-Bree wrote:
>>>
On 2012-12-06T22:25:40, Andrew Beekhof wrote:
> But any failures of the nagios age
On Fri, Dec 7, 2012 at 3:00 PM, Gao,Yan wrote:
> On 12/07/12 07:38, Andrew Beekhof wrote:
>>
>> On 06/12/2012, at 10:42 PM, Lars Marowsky-Bree wrote:
>>
>>> On 2012-12-06T22:25:40, Andrew Beekhof wrote:
>>>
But any failures of the nagios agents would count against the VM's
migration-th
On 12/07/12 07:38, Andrew Beekhof wrote:
>
> On 06/12/2012, at 10:42 PM, Lars Marowsky-Bree wrote:
>
>> On 2012-12-06T22:25:40, Andrew Beekhof wrote:
>>
>>> But any failures of the nagios agents would count against the VM's
>>> migration-threshold.
>>> So if moving were the right thing to do, i
On 12/07/12 10:50, Andrew Beekhof wrote:
> On Fri, Dec 7, 2012 at 1:44 PM, Gao,Yan wrote:
>> On 12/07/12 10:14, Andrew Beekhof wrote:
>>> On Fri, Dec 7, 2012 at 12:46 PM, Gao,Yan wrote:
> what about:
> container-type=(black | white)
>
> black: colocate with the vm
> whit
On Fri, Dec 7, 2012 at 1:44 PM, Gao,Yan wrote:
> On 12/07/12 10:14, Andrew Beekhof wrote:
>> On Fri, Dec 7, 2012 at 12:46 PM, Gao,Yan wrote:
what about:
container-type=(black | white)
black: colocate with the vm
white: potentially other colocation or location constrai
On 12/07/12 10:14, Andrew Beekhof wrote:
> On Fri, Dec 7, 2012 at 12:46 PM, Gao,Yan wrote:
>>> what about:
>>> container-type=(black | white)
>>>
>>> black: colocate with the vm
>>> white: potentially other colocation or location constraints
>> Or just:
>> contained=(true| false)
>>
>> Detau
On Fri, Dec 7, 2012 at 12:46 PM, Gao,Yan wrote:
>> what about:
>> container-type=(black | white)
>>
>> black: colocate with the vm
>> white: potentially other colocation or location constraints
> Or just:
> contained=(true| false)
>
> Detaults to true?
Doesn't the set up a conceptual oxymor
On 12/07/12 07:42, Andrew Beekhof wrote:
>
> On 07/12/2012, at 10:19 AM, David Vossel wrote:
>
>> - Original Message -
>>> From: "Yan Gao"
>>> To: pacemaker@oss.clusterlabs.org
>>> Sent: Thursday, December 6, 2012 12:28:06 PM
&
On 07/12/2012, at 10:19 AM, David Vossel wrote:
> - Original Message -
>> From: "Yan Gao"
>> To: pacemaker@oss.clusterlabs.org
>> Sent: Thursday, December 6, 2012 12:28:06 PM
>> Subject: Re: [Pacemaker] Enable remote monitoring
>>
>>
On 06/12/2012, at 10:42 PM, Lars Marowsky-Bree wrote:
> On 2012-12-06T22:25:40, Andrew Beekhof wrote:
>
>> But any failures of the nagios agents would count against the VM's
>> migration-threshold.
>> So if moving were the right thing to do, it would have done it already.
>
> OK. I think this
- Original Message -
> From: "Yan Gao"
> To: pacemaker@oss.clusterlabs.org
> Sent: Thursday, December 6, 2012 12:28:06 PM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> Hi,
>
> On 12/06/12 19:42, Lars Marowsky-Bree wrote:
> > On 20
- Original Message -
> From: "Yan Gao"
> To: pacemaker@oss.clusterlabs.org
> Sent: Thursday, December 6, 2012 12:28:06 PM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> Hi,
>
> On 12/06/12 19:42, Lars Marowsky-Bree wrote:
> > On 20
Hi,
On 12/06/12 19:42, Lars Marowsky-Bree wrote:
> On 2012-12-06T22:25:40, Andrew Beekhof wrote:
>
>> But any failures of the nagios agents would count against the VM's
>> migration-threshold.
>> So if moving were the right thing to do, it would have done it already.
>
> OK. I think this was du
On 2012-12-06T22:25:40, Andrew Beekhof wrote:
> But any failures of the nagios agents would count against the VM's
> migration-threshold.
> So if moving were the right thing to do, it would have done it already.
OK. I think this was due to me still being stuck on the workings of an
order constra
On Thu, Dec 6, 2012 at 10:11 AM, Andrew Beekhof wrote:
> On Thu, Dec 6, 2012 at 7:59 PM, Rasto Levrinc wrote:
>> On Thu, Dec 6, 2012 at 2:48 AM, Andrew Beekhof wrote:
>>>
>>> On 05/12/2012, at 9:05 AM, Lars Marowsky-Bree wrote:
>>>
For what it is worth, I'd agree with this; the fact that t
On Thu, Dec 6, 2012 at 9:24 PM, Lars Marowsky-Bree wrote:
> On 2012-12-06T20:04:20, Andrew Beekhof wrote:
>
>> >> Does that make sense though?
>> >> You've not achieved anything a restart wouldn't have done.
>> >> The choice to move the VM should be up to the VM.
>> > If the fail-count of a nagio
On Thu, Dec 6, 2012 at 9:15 PM, Lars Marowsky-Bree wrote:
> On 2012-12-06T20:10:42, Andrew Beekhof wrote:
>
>> > To be honest, *I* couldn't figure out what "failure-delegate" would mean
>> > here. "So, the child delegates its failures to the parent as part of the
>> > child being ordered after th
On 2012-12-06T20:04:20, Andrew Beekhof wrote:
> >> Does that make sense though?
> >> You've not achieved anything a restart wouldn't have done.
> >> The choice to move the VM should be up to the VM.
> > If the fail-count of a nagios resource reaches its own
> > migration-threshold, the colocated
On 2012-12-06T20:10:42, Andrew Beekhof wrote:
> > To be honest, *I* couldn't figure out what "failure-delegate" would mean
> > here. "So, the child delegates its failures to the parent as part of the
> > child being ordered after the parent? Uh? How's that making sense?"
> > ;-)
> No, its a resou
On Thu, Dec 6, 2012 at 7:59 PM, Rasto Levrinc wrote:
> On Thu, Dec 6, 2012 at 2:48 AM, Andrew Beekhof wrote:
>>
>> On 05/12/2012, at 9:05 AM, Lars Marowsky-Bree wrote:
>>
>>> For what it is worth, I'd agree with this; the fact that the most common
>>> constraints are order *AND* colocation and w
On Thu, Dec 6, 2012 at 7:58 PM, Lars Marowsky-Bree wrote:
> On 2012-12-06T12:21:02, Andrew Beekhof wrote:
>
>> > If we want to stick with the terminology, "restart-first" (but -origin
>> > sounds better, so I don't feel that strongly either) as a tri-state (no
>> > (default), yes, treat-as-failur
On Thu, Dec 6, 2012 at 7:47 PM, Lars Marowsky-Bree wrote:
> On 2012-12-06T12:39:02, Andrew Beekhof wrote:
>
>> > [1] and it'd perhaps even be cleaner if, indeed, we had resource sets
>> > instead of groups, and could reference them as aggregates as well. But
>> > that may be a different discussio
On Thu, Dec 6, 2012 at 3:41 PM, Gao,Yan wrote:
> Hi Andrew,
> Thanks for the comments!
>
> On 12/06/12 09:44, Andrew Beekhof wrote:
>>
>> On 05/12/2012, at 11:27 PM, "Gao,Yan" wrote:
>>
>>> Hi,
>>> This is the first step - the support of "restart-origin" for order
>>> constraint along with the te
On Thu, Dec 6, 2012 at 2:48 AM, Andrew Beekhof wrote:
>
> On 05/12/2012, at 9:05 AM, Lars Marowsky-Bree wrote:
>
>> For what it is worth, I'd agree with this; the fact that the most common
>> constraints are order *AND* colocation and we don't have a
>> (link|chain|join) statement that adequately
On 2012-12-06T12:21:02, Andrew Beekhof wrote:
> > If we want to stick with the terminology, "restart-first" (but -origin
> > sounds better, so I don't feel that strongly either) as a tri-state (no
> > (default), yes, treat-as-failure (anyone got a snappy idea for that
> > one?) might make be advi
On 2012-12-05T15:52:43, David Vossel wrote:
> Yeah, I suppose you are right. I wouldn't have thought of these two options
> as being related, but we need that inverse constraint to force the restart of
> A. Utilizing the inverse order constraint internally makes the
> implementation of this
On 2012-12-06T12:39:02, Andrew Beekhof wrote:
> > [1] and it'd perhaps even be cleaner if, indeed, we had resource sets
> > instead of groups, and could reference them as aggregates as well. But
> > that may be a different discussion.
>
> I would very much like to ditch groups for sets, but ther
Hi Andrew,
Thanks for the comments!
On 12/06/12 09:44, Andrew Beekhof wrote:
>
> On 05/12/2012, at 11:27 PM, "Gao,Yan" wrote:
>
>> Hi,
>> This is the first step - the support of "restart-origin" for order
>> constraint along with the test cases:
>>
>> https://github.com/gao-yan/pacemaker/commit
On 05/12/2012, at 9:05 AM, Lars Marowsky-Bree wrote:
> On 2012-12-04T14:48:50, David Vossel wrote:
>
>> The resource ordered set with the 'restart-origin' option gets us half way
>> there in the constraint definition. We still have to build the colocation
>> set between the vm and the resou
On 06/12/2012, at 5:00 AM, "Gao,Yan" wrote:
> On 12/06/12 00:36, David Vossel wrote:
>>
>>
>> - Original Message -
>>> From: "Yan Gao"
>>> To: pacemaker@oss.clusterlabs.org
>>> Sent: Wednesday, December 5, 2
On 05/12/2012, at 11:27 PM, "Gao,Yan" wrote:
> Hi,
> This is the first step - the support of "restart-origin" for order
> constraint along with the test cases:
>
> https://github.com/gao-yan/pacemaker/commits/restart-origin
>
> It looks straight-forward to me. Hope I didn't miss anything ;-)
>
On 05/12/2012, at 4:05 AM, Lars Marowsky-Bree wrote:
> On 2012-12-04T11:45:16, David Vossel wrote:
>
>> I am okay with this constraint option being implemented, as it is the basis
>> for this whole concept. When it comes time to make this usable, don't make
>> the abstraction people use to
On 05/12/2012, at 3:45 AM, David Vossel wrote:
> - Original Message -
>> From: "Lars Marowsky-Bree"
>> To: "The Pacemaker cluster resource manager"
>> Sent: Tuesday, December 4, 2012 6:59:08 AM
>> Subject: Re: [Pacemaker] Enable remote
On 04/12/2012, at 9:20 AM, Lars Marowsky-Bree wrote:
> On 2012-12-03T16:32:14, David Vossel wrote:
>
>>> +
>>> +
>>> +
>>
>> I don't feel strongly about this. Here's what comes to mind for me.
>>
>> force-recover - force recovery of both sides of the constraint if either
>> s
On 12/06/12 04:52, David Vossel wrote:
Hi,
This is the first step - the support of "restart-origin" for order
constraint along with the test cases:
https://github.com/gao-yan/pacemaker/commits/restart-origin
It looks straight-forward to me. Hope I didn't miss
- Original Message -
> From: "Yan Gao"
> To: pacemaker@oss.clusterlabs.org
> Sent: Wednesday, December 5, 2012 12:00:57 PM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> On 12/06/12 00:36, David Vossel wrote:
> >
> >
> > --
On 12/06/12 00:36, David Vossel wrote:
>
>
> - Original Message -
>> From: "Yan Gao"
>> To: pacemaker@oss.clusterlabs.org
>> Sent: Wednesday, December 5, 2012 6:27:05 AM
>> Subject: Re: [Pacemaker] Enable remote monitoring
>>
>>
- Original Message -
> From: "Yan Gao"
> To: pacemaker@oss.clusterlabs.org
> Sent: Wednesday, December 5, 2012 6:27:05 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> Hi,
> This is the first step - the support of "restart-origin" f
Hi,
This is the first step - the support of "restart-origin" for order
constraint along with the test cases:
https://github.com/gao-yan/pacemaker/commits/restart-origin
It looks straight-forward to me. Hope I didn't miss anything ;-)
If restart-origin="true" combines with kind="Optional", it jus
On 2012-12-04T14:48:50, David Vossel wrote:
> The resource ordered set with the 'restart-origin' option gets us half way
> there in the constraint definition. We still have to build the colocation
> set between the vm and the resources so everything runs on the same node
> (perhaps I just ass
- Original Message -
> From: "Lars Marowsky-Bree"
> To: "The Pacemaker cluster resource manager"
> Sent: Tuesday, December 4, 2012 11:05:51 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> On 2012-12-04T11:45:16, David Vossel wrote:
On 2012-12-04T11:45:16, David Vossel wrote:
> I am okay with this constraint option being implemented, as it is the basis
> for this whole concept. When it comes time to make this usable, don't make
> the abstraction people use to configure this relationship live at the crm
> shell... meaning
- Original Message -
> From: "Lars Marowsky-Bree"
> To: "The Pacemaker cluster resource manager"
> Sent: Tuesday, December 4, 2012 6:59:08 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> On 2012-12-04T19:48:18, "Gao,Yan" wrote
On 2012-12-04T19:48:18, "Gao,Yan" wrote:
> > Yes, I think this looks good.
> The patch to the schema I proposed supports this already ;-)
So it seems that nobody had any serious objections to this approach, but
we were fiddling with details and can't actually decide what we like
better, if anyth
On 12/04/12 18:21, Lars Marowsky-Bree wrote:
> On 2012-12-04T12:45:05, "Gao,Yan" wrote:
>
>>> (Ohhh. Did we just find a use for a negative score here? ;-) Just
>>> throwing that out there. It'd fit the model we have so far, is all I'm
>>> saying.)
>> Perhaps to name another "kind" for order const
On 2012-12-04T12:45:05, "Gao,Yan" wrote:
> > (Ohhh. Did we just find a use for a negative score here? ;-) Just
> > throwing that out there. It'd fit the model we have so far, is all I'm
> > saying.)
> Perhaps to name another "kind" for order constraint instead of an
> additional optional attribut
On 12/04/12 06:20, Lars Marowsky-Bree wrote:
> On 2012-12-03T16:32:14, David Vossel wrote:
>
>>> +
>>> +
>>> +
>>
>> I don't feel strongly about this. Here's what comes to mind for me.
>>
>> force-recover - force recovery of both sides of the constraint if either
>> side fails
>
On 2012-12-03T16:32:14, David Vossel wrote:
> > +
> > +
> > +
>
> I don't feel strongly about this. Here's what comes to mind for me.
>
> force-recover - force recovery of both sides of the constraint if either side
> fails
We actually have a precedent here - grep for restart_t
- Original Message -
> From: "Yan Gao"
> To: pacemaker@oss.clusterlabs.org
> Sent: Monday, December 3, 2012 5:49:31 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> Hi,
>
> On 11/13/12 03:52, David Vossel wrote:
> > - Original Mess
Hi,
On 11/13/12 03:52, David Vossel wrote:
> - Original Message -
>> From: "Lars Marowsky-Bree"
>> To: "The Pacemaker cluster resource manager"
>> Sent: Monday, November 12, 2012 1:16:49 PM
>> Subject: Re: [Pacemaker] Enable remote monito
On Mon, Nov 12, 2012 at 10:25:22PM +0100, Arnold Krille wrote:
> On Monday 12 November 2012 10:50:57 Dejan Muhamedagic wrote:
> > Hi Arnold,
> >
> > On Sun, Nov 11, 2012 at 07:37:29PM +0100, Arnold Krille wrote:
> > > On Sun, 11 Nov 2012 18:37:04 +0100 Dejan Muhamedagic
> > >
> > > wrote:
> > >
On Monday 12 November 2012 10:50:57 Dejan Muhamedagic wrote:
> Hi Arnold,
>
> On Sun, Nov 11, 2012 at 07:37:29PM +0100, Arnold Krille wrote:
> > On Sun, 11 Nov 2012 18:37:04 +0100 Dejan Muhamedagic
> >
> > wrote:
> > > On Fri, Nov 09, 2012 at 05:22:08PM +0100, Lars Marowsky-Bree wrote:
> > > > O
On 2012-11-12T14:52:35, David Vossel wrote:
> Yes, introducing the new order constraint attribute would allow all
> this to be possible without the container object, but all the
> dependencies between the vm and the children would have to be
> generated in the constraint section (order and coloca
- Original Message -
> From: "Lars Marowsky-Bree"
> To: "The Pacemaker cluster resource manager"
> Sent: Monday, November 12, 2012 1:16:49 PM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> On 2012-11-12T14:03:24, David Vossel wrote:
>
On 2012-11-12T14:03:24, David Vossel wrote:
> > We want "A" to be restarted if "B" fails. (If A->B are also
> > collocated, we'd also get fail-over after migration-threshold
> > triggers. That may not always be desired.)
> I'm not sure I follow why we'd be concerned about migration-threshold
> he
- Original Message -
> From: "Lars Marowsky-Bree"
> To: "The Pacemaker cluster resource manager"
> Sent: Monday, November 12, 2012 8:24:54 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> On 2012-11-09T17:06:32, David Vossel wrote:
On 2012-11-11T18:55:48, Dejan Muhamedagic wrote:
> There's also one aspect which we didn't consider (or I missed
> it). The new "container" element cannot be part of a group,
> whereas if the monitor op is extended there wouldn't be such a
> constraint.
If we map it to an attribute on an existin
On 2012-11-09T17:06:32, David Vossel wrote:
OK, I should first have read the whole thread. Sorry about that. Brain
whacko.
> > It needs to be a new class because the scripts (I'm pretty sure)
> > follow a completely different API to anything else we support.
Right. That's what I meant, of cours
On 2012-11-09T14:35:47, David Vossel wrote:
> >
> > That's exactly the kind of abstraction a resource agent class can
> > provide though for the nagios agents - no need to have that special
> > knowledge in the PE. The LRM can hide this, which is partly its
> > purpose.
> I know nothing about th
Hi Arnold,
On Sun, Nov 11, 2012 at 07:37:29PM +0100, Arnold Krille wrote:
> On Sun, 11 Nov 2012 18:37:04 +0100 Dejan Muhamedagic
> wrote:
> > On Fri, Nov 09, 2012 at 05:22:08PM +0100, Lars Marowsky-Bree wrote:
> > > On 2012-11-09T14:06:29, Dejan Muhamedagic
> > > wrote:
> > > > > And also doesn'
On Sun, 11 Nov 2012 18:37:04 +0100 Dejan Muhamedagic
wrote:
> On Fri, Nov 09, 2012 at 05:22:08PM +0100, Lars Marowsky-Bree wrote:
> > On 2012-11-09T14:06:29, Dejan Muhamedagic
> > wrote:
> > > > And also doesn't really help with getting the state/readiness of
> > > > services the guest might prov
On Sat, Nov 10, 2012 at 08:39:42AM +1100, Andrew Beekhof wrote:
> On Fri, Nov 9, 2012 at 10:25 PM, Lars Marowsky-Bree wrote:
> > On 2012-11-09T11:04:15, Andrew Beekhof wrote:
> >
> >> So I was just explaining the problem and context to David... his
> >> comment was "aren't these just unmanaged re
Hi David,
On Fri, Nov 09, 2012 at 05:06:32PM -0500, David Vossel wrote:
>[...]
>
> Lars,
Not Lars, but I hope I can give some answers here.
> Does the order in which the members of the container start
> monitoring matter? Do the members need to be serialized or
> anything, or can we just start
On Fri, Nov 09, 2012 at 05:22:08PM +0100, Lars Marowsky-Bree wrote:
> On 2012-11-09T14:06:29, Dejan Muhamedagic wrote:
>
> > > > > Uh? How should this be handled by the RA? Can you elaborate?
> > > > For instance, using expect to wait for the login prompt on the
> > > > console. Or, if that's pos
- Original Message -
> From: "Andrew Beekhof"
> To: "The Pacemaker cluster resource manager"
> Sent: Friday, November 9, 2012 3:36:10 PM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> On Sat, Nov 10, 2012 at 6:35 AM, David Vosse
On Fri, Nov 9, 2012 at 10:25 PM, Lars Marowsky-Bree wrote:
> On 2012-11-09T11:04:15, Andrew Beekhof wrote:
>
>> So I was just explaining the problem and context to David... his
>> comment was "aren't these just unmanaged resources and some
>> constraints?".
>
> They can even be managed - the star
On Sat, Nov 10, 2012 at 6:35 AM, David Vossel wrote:
> - Original Message -
>> From: "Lars Marowsky-Bree"
>> To: "The Pacemaker cluster resource manager"
>> Sent: Friday, November 9, 2012 11:54:16 AM
>> Subject: Re: [Pacemaker] Enable
On Sat, Nov 10, 2012 at 4:54 AM, Lars Marowsky-Bree wrote:
> On 2012-11-09T11:46:59, David Vossel wrote:
>
>> What if we made something similar to the concept of an "un-managed"
>> resource, in that it is only ever monitored, but treated it like a normal
>> resource. Meaning start/stop could s
- Original Message -
> From: "Lars Marowsky-Bree"
> To: "The Pacemaker cluster resource manager"
> Sent: Friday, November 9, 2012 11:54:16 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> On 2012-11-09T11:46:59, David Vossel wrote:
>
On 2012-11-09T11:46:59, David Vossel wrote:
> What if we made something similar to the concept of an "un-managed" resource,
> in that it is only ever monitored, but treated it like a normal resource.
> Meaning start/stop could still execute, but start is really just the first
> "monitor" oper
- Original Message -
> From: "Lars Marowsky-Bree"
> To: "The Pacemaker cluster resource manager"
> Sent: Friday, November 9, 2012 5:25:41 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
>
> On 2012-11-09T11:04:15, Andrew Beekhof wrot
On 2012-11-09T14:06:29, Dejan Muhamedagic wrote:
> > > > Uh? How should this be handled by the RA? Can you elaborate?
> > > For instance, using expect to wait for the login prompt on the
> > > console. Or, if that's possible, employing libvirt to get the
> > > current runlevel. We already discuss
On Fri, Nov 09, 2012 at 12:16:15PM +0100, Lars Marowsky-Bree wrote:
> On 2012-11-08T13:22:34, Dejan Muhamedagic wrote:
>
> > > Uh? How should this be handled by the RA? Can you elaborate?
> > For instance, using expect to wait for the login prompt on the
> > console. Or, if that's possible, emplo
1 - 100 of 117 matches
Mail list logo
