All,
following the current internet trends, all our github repositories will
switch from the "master" branch to "main".
This email is not meant to spark any discussion around the merit of
those trends or offend anyone, it´s simple and technical and I would
like to keep it that way.
This
Hi sbd - developers & users!
Thanks to everybody for contributing to tests and
further development.
Changes since 1.5.1
- improve/fix cmdline handling
- tell the actual watchdog device specified with -w
- tolerate and strip any leading spaces of commandline option values
- Sanitize
On Mon, Nov 15, 2021 at 3:32 PM S Rogers wrote:
>>
>> The only solution here - as long as fencing node on external
>> connectivity loss is acceptable - is modifying ethmonitor RA to fail
>> monitor operation in this case.
>
> I was hoping to find a way to achieve the desired outcome without
I am pleased to announce the latest maintenance release of Corosync
3.1.6 available immediately from GitHub release section at
https://github.com/corosync/corosync/releases or our website at
http://build.clusterlabs.org/corosync/releases/.
This release contains MAJOR bugfix of totem protocol
We are pleased to announce the release of libqb 2.0.4
Source code is available at:
https://github.com/ClusterLabs/libqb/releases/
Please use the signed .tar.gz or .tar.xz files with the version number
in rather than the github-generated "Source Code" ones.
The most important fix in this
All,
We are pleased to announce the general availability of kronosnet v1.23.
This version contains MAJOR bug fixes and everybody is strongly
encouraged to upgrade as soon as possible.
The defrag buffer fixes introduced in v1.22, revealed a long standing
bug in corosync, 2 serious bugs in
>>> S Rogers schrieb am 15.11.2021 um 13:32 in
>>> Nachricht
<8c836815-8fac-115e-4eb0-c1e73933c...@gmail.com>:
...
> Unfortunately, in some situations this cluster will be deployed in a
> completely isolated network so there may not even be a router that we
> can use as a ping target, and we
On 15/11/2021 12:03, Klaus Wenninger wrote:
On Mon, Nov 15, 2021 at 12:19 PM Andrei Borzenkov
wrote:
On Mon, Nov 15, 2021 at 1:18 PM Klaus Wenninger
wrote:
>
>
>
> On Mon, Nov 15, 2021 at 10:37 AM S Rogers
wrote:
>>
>> I had thought about doing that,
On Mon, Nov 15, 2021 at 12:19 PM Andrei Borzenkov
wrote:
> On Mon, Nov 15, 2021 at 1:18 PM Klaus Wenninger
> wrote:
> >
> >
> >
> > On Mon, Nov 15, 2021 at 10:37 AM S Rogers
> wrote:
> >>
> >> I had thought about doing that, but the cluster is then dependent on the
> >> external system, and if
On Mon, Nov 15, 2021 at 1:18 PM Klaus Wenninger wrote:
>
>
>
> On Mon, Nov 15, 2021 at 10:37 AM S Rogers wrote:
>>
>> I had thought about doing that, but the cluster is then dependent on the
>> external system, and if that external system was to go down or become
>> unreachable for any reason
On Mon, Nov 15, 2021 at 10:37 AM S Rogers wrote:
> I had thought about doing that, but the cluster is then dependent on the
> external system, and if that external system was to go down or become
> unreachable for any reason then it would falsely cause the cluster to
> failover or worse it could
I had thought about doing that, but the cluster is then dependent on the
external system, and if that external system was to go down or become
unreachable for any reason then it would falsely cause the cluster to
failover or worse it could even take the cluster down completely, if the
external
Have you tried with ping and a location constraint for avoiding hosts that
cannot ping an extrrnal system.
Best Regards,Strahil Nikolov
On Mon, Nov 15, 2021 at 0:07, S Rogers wrote:
Using on-fail=fence is what I initially tried, but it doesn't work
unfortunately.
It looks like this is
13 matches
Mail list logo
