[ClusterLabs] Antw: Proposed change for 1.1.16: ending python 2.6 compatibility
>>> Ken Gaillot schrieb am 05.07.2016 um 19:31 in >>> Nachricht <577beef9.4000...@redhat.com>: > As you may be aware, python 3 is a significant, backward-compatible > restructuring of the python language. Most development of the python 2 > series has ended, and support for python 2 will completely end in 2020. > > Pacemaker currently uses python only in its test suites. At some point, > we may convert a few existing Pacemaker-provided resource agents and > fence agents to python as well. > > Currently, Pacemaker's python code is compatible with python 2.6 and > 2.7. We definitely need to start moving toward python 3 compatibility. > It is possible to support both 2.7 and 3 with the same code, but we need > to lose compatibility with 2.6. (Maintaining a separate branch of code > for 2.6 would not be worth the effort.) > > So, I propose that Pacemaker stop supporting python 2.6 as of the next > version (1.1.16, expected sometime in the fall or winter). Not all our > python code is likely to be python3-compatible by that time, but we can > start moving in that direction. I just checked three servers: SLES10 SP4 uses python 2.4, but no pacemaker SLES11 SP4 uses python 2.6 SLES12 SP1 uses python 2.7 As SP4 is the last SP for SLES11, I guess there won't be any update for pacemaker (not to talk about python) In SLES12 there is a python3 available, but not installed by default. > > If anyone has any reasons to do this differently, let me know. As this > only affects the test suites currently, and most Linux distributions > have stopped supporting python 2.6 already, I expect more "what took you > so long" responses than "slow down" ;-) Maybe push python 3 first ;-) > -- > Ken Gaillot > > ___ > Users mailing list: Users@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
[ClusterLabs] Problem with one resource
Hello.
I have one resource which is in unmanaged state and have no idea why :-/
[root@srv3-cz ~]# pcs resource
kafelki13-lvm (ocf::heartbeat:LVM): FAILED srv3-cz (unmanaged)
[root@srv3-cz ~]# pcs resource show kafelki13-lvm
Resource: kafelki13-lvm (class=ocf provider=heartbeat type=LVM)
Attributes: volgrpname=iipimage-kafelki13 exclusive=true
Operations: start interval=0s timeout=30
(kafelki13-lvm-start-interval-0s)
stop interval=0s timeout=30 (kafelki13-lvm-stop-interval-0s)
monitor interval=10 timeout=30
(kafelki13-lvm-monitor-interval-10)
"pcs resource debug-start" command has the following output:
[root@srv3-cz ~]# pcs resource debug-start kafelki13-lvm --full
Operation start for kafelki13-lvm (ocf:heartbeat:LVM) returned 0
> stdout: volume_list="srv3cz"
> stdout: volume_list="srv3cz"
> stderr: + 05:38:24: 55: OUR_TAG=pacemaker
> stderr: + 05:38:24: 155: VG_MODE=
> stderr: + 05:38:24: 657: '[' 1 -ne 1 ']'
> stderr: + 05:38:24: 663: case $1 in
> stderr: + 05:38:24: 676: '[' -z iipimage-kafelki13 ']'
> stderr: ++ 05:38:24: 700: gawk '/Logical Volume Manager/ {print
$5"\n"; exit; }
> stderr: /LVM version:/ {printf $3"\n"; exit;}'
> stderr: ++ 05:38:24: 699: vgchange --version
> stderr: + 05:38:24: 699: LVM_VERSION='2.02.130(2)-RHEL7'
> stderr: + 05:38:24: 700: rc=0
> stderr: + 05:38:24: 703: '[' 0 -ne 0 ']'
> stderr: + 05:38:24: 703: '[' -z '2.02.130(2)-RHEL7' ']'
> stderr: + 05:38:24: 708: LVM_MAJOR=2
> stderr: + 05:38:24: 710: VOLUME=iipimage-kafelki13
> stderr: + 05:38:24: 711: OP_METHOD=start
> stderr: + 05:38:24: 713: '[' -n '' ']'
> stderr: + 05:38:24: 718: case "$1" in
> stderr: + 05:38:24: 721: LVM_validate_all
> stderr: + 05:38:24: LVM_validate_all:545: check_binary gawk
> stderr: + 05:38:24: check_binary:56: have_binary gawk
> stderr: + 05:38:24: have_binary:68: '[' '' = 1 ']'
> stderr: ++ 05:38:24: have_binary:71: echo gawk
> stderr: ++ 05:38:24: have_binary:71: sed -e 's/ -.*//'
> stderr: + 05:38:24: have_binary:71: local bin=gawk
> stderr: ++ 05:38:24: have_binary:72: which gawk
> stderr: + 05:38:24: have_binary:72: test -x /usr/bin/gawk
> stderr: + 05:38:24: LVM_validate_all:559: lvm dumpconfig
global/use_lvmetad
> stderr: + 05:38:24: LVM_validate_all:559: grep 'use_lvmetad.*=.*1'
> stderr: + 05:38:24: LVM_validate_all:560: '[' 1 -eq 0 ']'
> stderr: ++ 05:38:24: LVM_validate_all:569: vgck iipimage-kafelki13
> stderr: + 05:38:24: LVM_validate_all:569: VGOUT=
> stderr: + 05:38:24: LVM_validate_all:570: '[' 0 -ne 0 ']'
> stderr: + 05:38:24: LVM_validate_all:600: '[' 2 = 1 ']'
> stderr: ++ 05:38:24: LVM_validate_all:603: vgdisplay -v
iipimage-kafelki13
> stderr: + 05:38:24: LVM_validate_all:603: VGOUT=' Using volume
group(s) on command line.
> stderr: --- Volume group ---
> stderr: VG Name iipimage-kafelki13
> stderr: System ID
> stderr: Formatlvm2
> stderr: Metadata Areas1
> stderr: Metadata Sequence No 25
> stderr: VG Access read/write
> stderr: VG Status resizable
> stderr: MAX LV0
> stderr: Cur LV1
> stderr: Open LV 0
> stderr: Max PV0
> stderr: Cur PV1
> stderr: Act PV1
> stderr: VG Size 20.00 TiB
> stderr: PE Size 4.00 MiB
> stderr: Total PE 5242879
> stderr: Alloc PE / Size 5242879 / 20.00 TiB
> stderr: Free PE / Size 0 / 0
> stderr: VG UUID ew4hlQ-9gVX-hlY8-4thM-YUXg-2gAS-OCvdwz
> stderr:
> stderr: --- Logical volume ---
> stderr: LV Path /dev/iipimage-kafelki13/kafelki13
> stderr: LV Namekafelki13
> stderr: VG Nameiipimage-kafelki13
> stderr: LV UUID nsuSGr-W6Dq-pnQL-aBCD-mye9-EAkV-foIi7D
> stderr: LV Write Accessread/write
> stderr: LV Creation host, time netbackup-ms, 2016-07-04 14:49:53
+0200
> stderr: LV Status NOT available
> stderr: LV Size20.00 TiB
> stderr: Current LE 5242879
> stderr: Segments 1
> stderr: Allocation inherit
> stderr: Read ahead sectors auto
> stderr:
> stderr: --- Physical volumes ---
> stderr: PV Name /dev/mapper/mpaths
> stderr: PV UUID fEHavV-InnO-OlgA-H3vg-HsUc-tNmN-2j3bgw
> stderr: PV Status allocatable
> stderr: Total PE / Free PE5242879 / 0
> stderr:'
> stderr: + 05:38:24: LVM_validate_all:605: '[' 0 -ne 0 ']'
> stderr: + 05:38:24: LVM_validate_all:614: ocf_is_true true
> stderr: + 05:38:24: ocf_is_true:101: case "$1" in
> stderr: + 05:38:24: ocf_is_true:102: true
> stderr: + 05:38:24: LVM_validate_all:621: ocf_is_clone
> stderr: + 05:38:24: ocf_is_clone:497: '[' '!' -z '' ']'
> stde
Re: [ClusterLabs] Proposed change for 1.1.16: ending python 2.6 compatibility
On 05/07/16 01:31 PM, Ken Gaillot wrote: > As you may be aware, python 3 is a significant, backward-compatible > restructuring of the python language. Most development of the python 2 > series has ended, and support for python 2 will completely end in 2020. > > Pacemaker currently uses python only in its test suites. At some point, > we may convert a few existing Pacemaker-provided resource agents and > fence agents to python as well. > > Currently, Pacemaker's python code is compatible with python 2.6 and > 2.7. We definitely need to start moving toward python 3 compatibility. > It is possible to support both 2.7 and 3 with the same code, but we need > to lose compatibility with 2.6. (Maintaining a separate branch of code > for 2.6 would not be worth the effort.) > > So, I propose that Pacemaker stop supporting python 2.6 as of the next > version (1.1.16, expected sometime in the fall or winter). Not all our > python code is likely to be python3-compatible by that time, but we can > start moving in that direction. > > If anyone has any reasons to do this differently, let me know. As this > only affects the test suites currently, and most Linux distributions > have stopped supporting python 2.6 already, I expect more "what took you > so long" responses than "slow down" ;-) If this can be done without breaking RHEL 6 deployments (and it sounds like it wouldn't be an issue), then I say go for it. A key to good HA is simplicity, and maintaining two branches (or getting stuck on a dead-end branch) seems to go against that ethos. -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] DC of the election will be an infinite loop.
On 06/27/2016 11:41 PM, 飯田 雄介 wrote: > Hi, all > > I added two lines to comment on cib.xml using crmsh. > > === > # cat test.crm > node 167772452: test-3 > # comment line 1 > # comment line 2 > property cib-bootstrap-options: \ > have-watchdog=false \ > dc-version=1.1.14-1.el7-70404b0 \ > cluster-infrastructure=corosync > === > > And was re-start the cluster, the election of the DC was to an infinite loop. > > Environment > We are using the Pacemaker-1.1.14. > > Where I tried to look at the log, > It looks like the handling of the comment node is not good. > It looks like the problem occurs when there are two or more lines of comment. > > Problem seems to occur on or after modification of the following. > https://github.com/ClusterLabs/pacemaker/commit/1073786ec24f3bbf26a0f6a5b0614a65edac4301 > > Does this behavior is a known bug? > > I will attach a crm_report of when the problem occurred. > > Regards, > Yusuke Hi Yuusuke, It does look like a bug. I will investigate further. ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
[ClusterLabs] Proposed change for 1.1.16: ending python 2.6 compatibility
As you may be aware, python 3 is a significant, backward-compatible restructuring of the python language. Most development of the python 2 series has ended, and support for python 2 will completely end in 2020. Pacemaker currently uses python only in its test suites. At some point, we may convert a few existing Pacemaker-provided resource agents and fence agents to python as well. Currently, Pacemaker's python code is compatible with python 2.6 and 2.7. We definitely need to start moving toward python 3 compatibility. It is possible to support both 2.7 and 3 with the same code, but we need to lose compatibility with 2.6. (Maintaining a separate branch of code for 2.6 would not be worth the effort.) So, I propose that Pacemaker stop supporting python 2.6 as of the next version (1.1.16, expected sometime in the fall or winter). Not all our python code is likely to be python3-compatible by that time, but we can start moving in that direction. If anyone has any reasons to do this differently, let me know. As this only affects the test suites currently, and most Linux distributions have stopped supporting python 2.6 already, I expect more "what took you so long" responses than "slow down" ;-) -- Ken Gaillot ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Antw: Doing reload right
On 07/04/2016 03:52 AM, Vladislav Bogdanov wrote: > 01.07.2016 18:26, Ken Gaillot wrote: > > [...] > >> You're right, "parameters" or "params" would be more consistent with >> existing usage. "Instance attributes" is probably the most technically >> correct term. I'll vote for "reload-params" > > May be "reconfigure" fits better? This would at least introduce an > action name which does not intersect with LSB/systemd/etc. > > "reload" is for service itself as admin would expect, "reconfigure" is > for its controlling resource. > > [...] I like "reconfigure", but then the new parameter attribute should be "reconfigurable", which could be confusing. "All my parameters are reconfigurable!" I suppose we could call the attribute "change_triggers_reconfigure". ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Antw: Re: Antw: Doing reload right
On 07/04/2016 02:01 AM, Ulrich Windl wrote: > For the case of changing the contents of an external configuration file, the > RA would have to provide some reloadable dummy parameter then (maybe like > "config_generation=2"). That is a widely recommended approach for the current "reload" implementation, but I don't think it's desirable. It still does not distinguish changes in the Pacemaker resource configuration from changes in the service configuration. For example, of an RA has one parameter that is agent-reloadable and another that is service-reloadable, and it gets a "reload" action, it has no way of knowing which of the two (or both) changed. It would have to always reload all agent-reloadable parameters, and trigger a service reload. That seems inefficient to me. Also, only Pacemaker should trigger agent reloads, and only the user should trigger service reloads, so combining them doesn't make sense to me. ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] How about making pacemaker OCF_ROOT_DIR more portable ?
On 07/04/2016 10:07 PM, Li Junliang wrote: > Hi all, > Currently, OCF_ROOT_DIR in configure.ac for pacemaker is fixed > to /usr/lib/ocf. But in resource-agents project , we can set > OCF_ROOT_DIR by setting "--with-ocf-root=xxx" . So , there may be two > different OCF directories . Would it be better that we add configure > argument like --with-ocf-root setting ? > > Best wishes, Yes, I agree. Historically, Pacemaker has not provided such an option because the exact path is specified in the OCF standard. So, compiling Pacemaker with a different value would make it incompatible with standard OCF agents. However, I do think it's worth giving the user the option to do so, as long as they're aware of the implications. There is one way to change it currently. The configure script looks for the presence of glue_config.h or hb_config.h from the cluster-glue package. If that exists, it will look there for the value of OCF_ROOT_DIR (normally "/usr/lib/ocf") and OCF_RA_DIR (normally "$OCF_ROOT_DIR/resource.d). It would be a bit hacky, but if you don't use cluster-glue, you could create a header file by that name with the desired values. ___ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
