On Wed, Apr 13, 2011 at 3:05 PM, Florian Haas wrote:
> On 2011-04-13 11:06, Andrew Beekhof wrote:
>> On Sat, Mar 19, 2011 at 6:10 PM, Vladislav Bogdanov
>> wrote:
>>> Hi,
>>>
>>> just bumping this to be not forgotten.
>>
>> Actually I'd missed that this was a Pacemaker specific one and
>> therefo
On 2011-04-13 11:06, Andrew Beekhof wrote:
> On Sat, Mar 19, 2011 at 6:10 PM, Vladislav Bogdanov
> wrote:
>> Hi,
>>
>> just bumping this to be not forgotten.
>
> Actually I'd missed that this was a Pacemaker specific one and
> therefore something I needed to look at :-)
Well considering that a b
13.04.2011 12:06, Andrew Beekhof wrote:
> On Sat, Mar 19, 2011 at 6:10 PM, Vladislav Bogdanov
> wrote:
>> Hi,
>>
>> just bumping this to be not forgotten.
>
> Actually I'd missed that this was a Pacemaker specific one and
> therefore something I needed to look at :-)
>
>> RA runs fine for almost
On Sat, Mar 19, 2011 at 6:10 PM, Vladislav Bogdanov
wrote:
> Hi,
>
> just bumping this to be not forgotten.
Actually I'd missed that this was a Pacemaker specific one and
therefore something I needed to look at :-)
> RA runs fine for almost a month, several simulated network outages were
> passe
Hi,
just bumping this to be not forgotten.
RA runs fine for almost a month, several simulated network outages were
passed with full success, so it could be included in some package. I
think pacemaker, because this RA uses pacemaker-specific calls.
Andrew?
(I can support this one)
23.02.2011 11:
> 25.02.2011 00:08, Serge Dubrouski wrote:
>> I wonder if that would be possible to make Pacemaker to move virtual
>> IP from one interface to another (not from one node to another) using
>> an RA like this one.
>
> I just use STP-enabled bridge for this purpose. All ports except one are
> blocked
25.02.2011 00:08, Serge Dubrouski wrote:
> I wonder if that would be possible to make Pacemaker to move virtual
> IP from one interface to another (not from one node to another) using
> an RA like this one.
I just use STP-enabled bridge for this purpose. All ports except one are
blocked by STP unt
I wonder if that would be possible to make Pacemaker to move virtual
IP from one interface to another (not from one node to another) using
an RA like this one.
On Thu, Feb 24, 2011 at 4:16 AM, Vladislav Bogdanov
wrote:
> 23.02.2011 11:53, Vladislav Bogdanov wrote:
>>>
>>> Also note that this is
23.02.2011 11:53, Vladislav Bogdanov wrote:
>>
>> Also note that this is
>> - linux specific
>> - requires kernel >= 2.6.33,
>> afaict no /sys/class/net/*/speed before that
>
> Ahm, was not aware about that. I need to look again at this because I
> need this to run on RHEL6 too. Anybody kno
Hi Lars,
thank you for your time and for so detailed review.
Just to dot half of i's (where it is about coding style):
1. I strongly prefer to cleanly separate data access from main logic by API.
2. I prefer to have non-void functions to return result explicitly
("main" too). This will prevent "c
On Tue, Feb 22, 2011 at 07:24:41PM +0200, Vladislav Bogdanov wrote:
> #!/bin/bash
> #
> # OCF resource agent which monitors state of network interface and records it
> as a value in CIB
> # based on summ of speeds of its active underlying interfaces.
> #
> # Copyright (c) 2011 Vladislav Bogdanov
Hi,
22.02.2011 18:46, Dejan Muhamedagic wrote:
> If there's no connectivity then you can use ping, if there's some
> then what matters is what kind of connection you have. "status"
> is more like on/off. Here you try to find out a specific network
> metric.
>
ok.
's/ifstatus/ifspeed/g' done
>>>
On Tue, Feb 22, 2011 at 05:55:11PM +0200, Vladislav Bogdanov wrote:
> Hi,
>
> 22.02.2011 17:03, Dejan Muhamedagic wrote:
> > A few general observations:
> >
> > - the name (ifstatus) doesn't fit exactly (perhaps ifspeed?)
>
> Main purpose of this RA (at least as I see it) is interface status
> c
Hi,
22.02.2011 17:03, Dejan Muhamedagic wrote:
> A few general observations:
>
> - the name (ifstatus) doesn't fit exactly (perhaps ifspeed?)
Main purpose of this RA (at least as I see it) is interface status
check, speed is used only to reflect that. Any non-zero value means that
interface is o
Hi,
On Tue, Feb 22, 2011 at 03:54:20PM +0200, Vladislav Bogdanov wrote:
> Hi again,
> attached is a bit more polished revision.
A few general observations:
- the name (ifstatus) doesn't fit exactly (perhaps ifspeed?)
- since this is a stateless agent, you should use the existing
functions for
Hi again,
attached is a bit more polished revision.
Best,
Vladislav
22.02.2011 15:01, Vladislav Bogdanov wrote:
> Hi Dejan,
>
> 22.02.2011 13:02, Dejan Muhamedagic wrote:
>> Hi,
>>
>> Where can you get STP stuff from? How to interpret it? And then
>
> Please look at attached RA.
>
> I decided
Hi Dejan,
22.02.2011 13:02, Dejan Muhamedagic wrote:
> Hi,
>
> Where can you get STP stuff from? How to interpret it? And then
Please look at attached RA.
I decided that today is a good time to finally brace myself to find 5
hours to write it, thanks Frederik ;) .
Tested, "works for me" (c) in
Hi,
On Tue, Feb 22, 2011 at 07:34:04AM +0200, Vladislav Bogdanov wrote:
> Hi,
> 21.02.2011 22:29, Florian Haas wrote:
> > On 02/21/2011 08:00 PM, Frederik Schüler wrote:
> >> Hello *,
> >>
> >> as the various ocf:*:ping[d] incarnations don't meet my specific needs,
> >
> > May I ask why and how?
On Tue, Feb 22, 2011 at 09:30:00AM +0100, Dejan Muhamedagic wrote:
> Hi,
>
> On Tue, Feb 22, 2011 at 08:54:14AM +0100, Florian Haas wrote:
> > On 2011-02-22 00:19, Frederik Schüler wrote:
> > > Hi,
> > >
> > > On Monday 21 February 2011 21:29:19 Florian Haas wrote:
> > >>> as the various ocf:*:pi
Hi,
On Tue, Feb 22, 2011 at 08:54:14AM +0100, Florian Haas wrote:
> On 2011-02-22 00:19, Frederik Schüler wrote:
> > Hi,
> >
> > On Monday 21 February 2011 21:29:19 Florian Haas wrote:
> >>> as the various ocf:*:ping[d] incarnations don't meet my specific needs,
> >>
> >> May I ask why and how?
>
On 2011-02-22 00:19, Frederik Schüler wrote:
> Hi,
>
> On Monday 21 February 2011 21:29:19 Florian Haas wrote:
>>> as the various ocf:*:ping[d] incarnations don't meet my specific needs,
>>
>> May I ask why and how?
>
> ocf:pacemaker:ping works, but takes approx. 25-30s to react at all, and
> ap
Hi,
21.02.2011 22:29, Florian Haas wrote:
> On 02/21/2011 08:00 PM, Frederik Schüler wrote:
>> Hello *,
>>
>> as the various ocf:*:ping[d] incarnations don't meet my specific needs,
>
> May I ask why and how?
I was thinking about writing something similar. I need this in a quite
complex networkin
Hi,
On Monday 21 February 2011 21:29:19 Florian Haas wrote:
> > as the various ocf:*:ping[d] incarnations don't meet my specific needs,
>
> May I ask why and how?
ocf:pacemaker:ping works, but takes approx. 25-30s to react at all, and
approx. 40s to complete the failover. But I need an immediat
On 02/21/2011 08:00 PM, Frederik Schüler wrote:
> Hello *,
>
> as the various ocf:*:ping[d] incarnations don't meet my specific needs,
May I ask why and how?
> I
> wrote a small RA using ethtool to detect a network link failure, in order to
> trigger a failover.
Well, what if the link is up b
Hello *,
as the various ocf:*:ping[d] incarnations don't meet my specific needs, I
wrote a small RA using ethtool to detect a network link failure, in order to
trigger a failover.
It's a first shot, comments are welcome.
Best regards
Frederik Schüler
ifstatus
Description: application/shellsc
25 matches
Mail list logo
