Re: [Linux-ha-dev] [Openais] An OCF agent for LXC (Linux Containers) - Linux-HA-Dev Digest, Vol 89, Issue 30

2011-04-29 Thread Darren Thompson
Florian/TEAM

Thank you for the update.

I'll thread my remaining replies into the message :-)

On Thu, 2011-04-28 at 07:46 -0600,
linux-ha-dev-requ...@lists.linux-ha.org wrote:

 Date: Thu, 28 Apr 2011 11:56:30 +0200
 From: Florian Haas florian.h...@linbit.com
 Subject: Re: [Linux-ha-dev] [Openais] An OCF agent for LXC (Linux
 Containers)
 To: High-Availability Linux Development List
 linux-ha-dev@lists.linux-ha.org
 Message-ID: 4db939ce.5000...@linbit.com
 Content-Type: text/plain; charset=utf-8
 
 On 2011-04-28 10:21, Darren Thompson wrote:
  Florina/TEAM
  
  Thanks for your input and the link to the guidelines
  
  I have updated my original ocf file in line with the guidlines, it
 even
  gave me a few tips on how to do things better so was well worth
 the
  time spent.
  
  Please find the updated ocf file for LXC contianers as a cluster
  resource attached.
  
  Since I'm not an actual developer (or even a career coder)
 
 Do you think I am?

Until Today, i have had no experience whatsoever with github, so
compared to me... yes...

 
  I do not have
  the facility to host my own github fork so would appreciate
 someone
  adopting this and integrating it into their git repository.
 
 OK, I have added this to a separate lxc branch in my own github
 fork.
 I'd appreciate if you could at least get yourself an account on github
 so you can comment on commit line notes.
 
 I have added my comments to this page:
 
 https://github.com/fghaas/resource-agents/commit/73f80b31f1cee5eff1c2fe2b968f4ea593e8f405

Yep, done.. I responded to nearly all of the you points (most of the
time to say, yep... agree).

You posted my first attempt and not the latest version, is it possible
to add that one as it addresses some( most hopefully) of the issues you
identified.

There are still some valid points you have raised however, So I'm going
to try to incorporate them into a third version.

Is there some clever way of re-integrating all of this? (did I mention
that I'm not normally a coder).

 
 
 Some of those may have already been addresses in your updated version,
 but to keep things simple I've kept my comments to one commit for the
 time being.
 
 Florian
 
 PS: We can stop CC'ing the openais list, this is in no way
 Corosync/OpenAIS related.

Agreed, I will stop pestering that list now :-)

Darren
attachment: face-smile.png___
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/


[Linux-HA] ocf:pacemaker:ping: dampen

2011-04-29 Thread Ulrich Windl
Hi,

I think the description for dampen in OCF:pacemaker:ping 
(pacemaker-1.1.5-5.5.5 of SLES11 SP1) is too terse:

parameter name=dampen unique=0
longdesc lang=en
The time to wait (dampening) further changes occur
/longdesc
shortdesc lang=enDampening interval/shortdesc
content type=integer default=5s/
/parameter

What does that do?

Regards,
Ulrich


___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


Re: [Linux-HA] ocf:pacemaker:ping: dampen

2011-04-29 Thread Dominik Klein
It waits $dampen before changes are pushed to the cib. So that
eventually occuring icmp hickups do not produce an unintended failover.

At least that's my understanding.

Regards
Dominik

On 04/29/2011 09:22 AM, Ulrich Windl wrote:
 Hi,
 
 I think the description for dampen in OCF:pacemaker:ping 
 (pacemaker-1.1.5-5.5.5 of SLES11 SP1) is too terse:
 
 parameter name=dampen unique=0
 longdesc lang=en
 The time to wait (dampening) further changes occur
 /longdesc
 shortdesc lang=enDampening interval/shortdesc
 content type=integer default=5s/
 /parameter
 
 What does that do?
 
 Regards,
 Ulrich
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


Re: [Linux-HA] ocf:pacemaker:ping: dampen

2011-04-29 Thread Andrew Beekhof
On Fri, Apr 29, 2011 at 9:27 AM, Dominik Klein d...@in-telegence.net wrote:
 It waits $dampen before changes are pushed to the cib. So that
 eventually occuring icmp hickups do not produce an unintended failover.

 At least that's my understanding.

correcto
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


[Linux-HA] Antw: ocf:pacemaker:ping: dampen

2011-04-29 Thread Ulrich Windl
Update:

I found out that the parameter is passed to attrd_updater as -d, where the 
documentation is just as bad:

 -d, --delay=value  The time to wait (dampening) in seconds further changes 
occur

I found no manual page for it.

Regards,
Ulrich


 Ulrich Windl ulrich.wi...@rz.uni-regensburg.de schrieb am 29.04.2011 um
09:22 in Nachricht 4dba833d02a15...@gwsmtp1.uni-regensburg.de:
 Hi,
 
 I think the description for dampen in OCF:pacemaker:ping 
 (pacemaker-1.1.5-5.5.5 of SLES11 SP1) is too terse:
 
 parameter name=dampen unique=0
 longdesc lang=en
 The time to wait (dampening) further changes occur
 /longdesc
 shortdesc lang=enDampening interval/shortdesc
 content type=integer default=5s/
 /parameter
 
 What does that do?
 
 Regards,
 Ulrich
 
 
 ___
 Linux-HA mailing list
 Linux-HA@lists.linux-ha.org 
 http://lists.linux-ha.org/mailman/listinfo/linux-ha 
 See also: http://linux-ha.org/ReportingProblems 
 

 
 

___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


Re: [Linux-HA] ocf:pacemaker:ping: dampen

2011-04-29 Thread Dominik Klein
 correcto

wow.
again! :)
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


[Linux-HA] DRBD MC 0.9.2 / Pacemaker GUI

2011-04-29 Thread Rasto Levrinc
Hi,

This is the next DRBD MC release 0.9.2. DRBD MC is DRBD, Pacemaker and
cluster virtual manager GUI.

In this release the parts of the GUI that enable to setup a live VM
migration were enhanced and fixed. The virtual manager works now in a
cluster as promised.

Another nice feature, that someone can combine with the previous, is the
possibility to create LVs, resize them, snapshot them etc.

Just think about it...
LVM - DRBD - HB/Corosync+Pacemaker - VMs - live migration, it comes
all together. Now, there's an idea for the next video. :)

You can get DRBD MC here:
http://oss.linbit.com/drbd-mc/
http://oss.linbit.com/drbd-mc/DMC-0.9.2.jar
http://oss.linbit.com/drbd-mc/drbd-mc-0.9.2.tar.gz

1. You don't need Java on the cluster servers only on your desktop.
2. Download the DMC-0.9.2.jar file.
3. Make sure you use SUN Java not the OpenJDK 1.6.
4. Start it: java -jar DMC-0.9.2.jar
5. It connects to the cluster via SSH.
6. If you use it without DRBD, you have to click Skip button on couple of
   places.

DRBD MC is compatible with Heartbeat 2.1.3 to the Pacemaker 1.1.5 with
Corosync or Heartbeat and DRBD 8.

The most important changes:
* divert existing drbd.ko for squeeze Linbit packages
* show host menu tooltips in DRBD view
* enable load DRBD menu, if it is not loaded
* change default application size
* Java style cleanup
* LV Resize plugin
* LV Create plugin
* LV Snapshot plugin
* fix remove button not working in new VM hardware
* fix apply button being disabled sometimes by mistake
* fix removing of a group, that has resources with constraints
* don't edit global drbd config if there are no resources
* fix some menu items showing twice
* make applying of changes smoother
* add operation timeouts dynamically
* add scientific linux version detection
* add README file
* add scripts/ directory
* fix saving of modified info in a cluster with VMs
* change directory structure
* fix changing of parameters in VM GUI in a cluster
* add junit framework
* fix modifying of VM options
* fix plugin subdirectories
* add --id-dsa, --id-rsa and --known-hosts options
* make block device editable
* fix min max checking in DRBD config
* fix updating of DRBD view
* store the same UUID on both nodes
* use machine=pc instead of pc-0.12 for now
* fix saving of new VMs not working on all hosts
* add allow-migrate option
* fix ptest not showing group services
* fix opensuse installation
* enable fine-grained sudo, don't make everything in bash -c
* change fenced to fencing...
* add annotations
* better VM input error handling
* show if a node was fenced
* remove superfluous warnings with libvirt 0.8.*
* better stacktrace for failed commands
* show pending status
* don't exit on errors when parsing
* why-a-field-is-disabled interface
* on_poweroff option
* Add CPU match fields in VM GUI

Rasto Levrinc

-- 
: Dipl-Ing Rastislav Levrinc
: DRBD MC http://oss.linbit.com/drbd-mc/
: DRBD/HA support and consulting http://www.linbit.com/
DRBD(R) and LINBIT(R) are registered trademarks of LINBIT, Austria.


___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


Re: [Linux-HA] Auto Failback despite location constrain

2011-04-29 Thread Stallmann, Andreas
Ha!

It works. But still, there are two strange (side) effects:

Firstly, mgmt01 still takes over, if it was disconnected from the net for a 
time shorter than five minutes. I mgmt01 stays disconnected for more than 5 
min, no auto fallback will happen after it's reconnected again.

Secondly, when mgmt01 comes back after 5min or more, the resources *will* stay 
on mgmt01 (good so far), but do *restart* on mgmt02 (and that's equally bad as 
if the services would fallback, because we run phone conferences on the server 
and those disconnect on every restart of the resources/services).

Any ideas *why* the resources restart and how to keep them from doing so?

Any ideas *why* mgmt01 has to stay disconnected for 5min or more to prevent an 
auto fallback? If the network is flapping for some reason, this would lead to 
flapping services, too, and that's really (really!) not desireable.

Cheers and thanks again for your support,

Andreas

-Ursprüngliche Nachricht-
Von: linux-ha-boun...@lists.linux-ha.org 
[mailto:linux-ha-boun...@lists.linux-ha.org] Im Auftrag von Stallmann, Andreas
Gesendet: Freitag, 29. April 2011 10:39
An: General Linux-HA mailing list
Betreff: Re: [Linux-HA] Auto Failback despite location constrain

Hi!

 If the resource ends up on the non-preferred node, those settings will
 cause it to have an equal score on both nodes, so it should stay put.
 If you want to verify, try ptest -Ls to see what scores each resource has.
Great, that's the command I was looking for!

Before the failover the output is:

group_color: nag_grp allocation score on ipfuie-mgmt01: 100
group_color: nag_grp allocation score on ipfuie-mgmt02: 0

When the nag_grp has failed over to ipfuie-mgmt02 it is:

group_color: nag_grp allocation score on ipfuie-mgmt01: -INFINITY
group_color: nag_grp allocation score on ipfuie-mgmt02: 0

Strange, isn't it? I would have expected, that the default-resource-stickiness 
had any influence on the values, but obviously it has not.
When mgmt01 comes back, we see (pretty soon) again:

group_color: nag_grp allocation score on ipfuie-mgmt01: 100
group_color: nag_grp allocation score on ipfuie-mgmt02: 0

Thus, the resource fails over to mgmt01 again. Which is not what we intended.

 Anyway, the problem is this constraint:

 location cli-prefer-nag_grp nag_grp \
rule $id=cli-prefer-rule-nag_grp inf: #uname eq ipfuie-mgmt01 and 
#uname eq ipfuie-mgmt01

TNX, I shortly thought of applying a vast amount of necessary cruelty on the 
colleague who did a migrate without the following unmigrate. I unmigrated 
the resources now (the location constrain is gone now), but the result is the 
same; the  resource-stickyness is not taken into account. AAARGH!!! (As 
Terry Pratchett says: Three exclamation marks, a clear sign of an insane 
mind... that's were configuring clusters gets me ... )

Please help, otherwise I might think of doing something really nasty like, 
like, like... like for example switching to windows! Ha! ;-)

Thanks in advance for your ongoing patience with me,

Andreas

___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


CONET Solutions GmbH, Theodor-Heuss-Allee 19, 53773 Hennef.
Registergericht/Registration Court: Amtsgericht Siegburg (HRB Nr. 9136) 
Geschäftsführer/Managing Directors: Jürgen Zender (Sprecher/Chairman), Anke 
Höfer ___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


CONET Solutions GmbH, Theodor-Heuss-Allee 19, 53773 Hennef.
Registergericht/Registration Court: Amtsgericht Siegburg (HRB Nr. 9136)
Geschäftsführer/Managing Directors: Jürgen Zender (Sprecher/Chairman), Anke 
Höfer
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

[Linux-HA] get haresources2cib.py

2011-04-29 Thread Vinay Nagrik
Hello Group,

Kindly tell me where can I download

haresources2cib.py file

from.

Please also tell me can I convert haresources file on a node where I am not
running high availability service and then can I copy the converted ..xml
file in

/var/lib/heartbeat

directory on which I am running the high availability.

Also does

cib file

must resiede under

/var/lib/heartbeat

directory or can it reside under any directory like under

/etc.

please let me know.  I am just a beginner.

Thanks in advance.

-- 
Thanks

Nagrik
___
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems