[Linux-ha-dev] [PATCH] Low: SAPInstance: make sure sidadm is not uninitialized, when calling cleanup_instance
Hi, here is a second one. Ok to just post the URL's ? Or should the diff still be send to the mailing list ? https://github.com/AlexanderKrauth/resource-agents/commit/4fdd1a420f23abc5005fa290a33d7fa902571d55 Thanks Alex ___ 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-dev] [PATCH] Medium: SAPInstance/SAPDatabase: correcting the unique values of RAs parameters
Hi, my first try doing a patch with the new github repo. Can you please check my last push. Is it ok to issue a pull request ? https://github.com/AlexanderKrauth/resource-agents/commit/3acc297348c39dff6107e4c87ce666f98161ae9c https://github.com/AlexanderKrauth/resource-agents/commit/3d511867233c818c377fba4cc84f0c87b11b44dd Thanks Alex ___ 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/
Re: [Linux-ha-dev] [PATCH] Medium: SAPInstance/SAPDatabase: correcting the unique values of RAs parameters
Hi, On Fri, Dec 09, 2011 at 11:42:23AM +0100, alexander.kra...@basf.com wrote: Hi, my first try doing a patch with the new github repo. Can you please check my last push. Is it ok to issue a pull request ? Looks fine to me. Cheers, Dejan https://github.com/AlexanderKrauth/resource-agents/commit/3acc297348c39dff6107e4c87ce666f98161ae9c https://github.com/AlexanderKrauth/resource-agents/commit/3d511867233c818c377fba4cc84f0c87b11b44dd Thanks Alex ___ 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-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] [PATCH] Low: SAPInstance: make sure sidadm is not uninitialized, when calling cleanup_instance
Hi, On Fri, Dec 09, 2011 at 11:42:26AM +0100, alexander.kra...@basf.com wrote: Hi, here is a second one. Ok to just post the URL's ? Or should the diff still be send to the mailing list ? If you submit a pull request the maintainers get an email about it. That should be enough. Of course, if you think something should be discussed and prefer doint that on the ML, then it's also fine to post patches to the ML. Cheers, Dejan https://github.com/AlexanderKrauth/resource-agents/commit/4fdd1a420f23abc5005fa290a33d7fa902571d55 Thanks Alex ___ 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-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Additional changes made via DHCPD review process
Hi Dejan, It has been recommended, that required options should not have default values. The initial version of the script had a default for that variable, but chrooted_path was not required. During the revision's suggested by Andreas and Florian, chrooted was converted into a required, and unique, variable, with no default. As for an ocft test case, I've not had a chance to look into that in enough detail to be able to create any. I am hoping to be able to look it over this weekend. On 12/09/2011 01:30 AM, Dejan Muhamedagic wrote: Hi, On Tue, Dec 06, 2011 at 01:39:04PM -0400, Chris Bowlby wrote: Hi All, Ok, I'll look into csync, and will concede the point on the RA syncing the out of chrooted configuration file. I still need to find a means to monitor the DHCP responses however, as that will just improve the reliability of the cluster itself, as well as the service. I'm really not sure how to do that. Didn't review the agent, but on a cursory look, perhaps you could provide the default for chrooted_path (/var/lib/dhcp). BTW, did you think of adding an ocft test case? Thanks, Dejan On 12/06/2011 12:20 PM, Alan Robertson wrote: I agree about avoiding the feature to sync config files. My typical recommendation is to use drbdlinks and put it on replicated or shared storage. In fact, I do that at home, and are doing it for a current customer. By the way, Sean has recently revised drbdlinks to support the OCF API. (In fact, it supports all of the OCF, heartbeat-v1 and LSB APIs). http://www.tummy.com/Community/software/drbdlinks/ You can find his source control for it on github: https://github.com/linsomniac/drbdlinks Quoting Florian Haasflor...@hastexo.com: On Tue, Dec 6, 2011 at 4:44 PM, Dejan Muhamedagicde...@suse.de wrote: Hi, On Tue, Dec 06, 2011 at 10:59:20AM -0400, Chris Bowlby wrote: Hi Everyone, I would like to thank Florian, Andreas and Dejan for making suggestions and pointing out some additional changed I should make. At this point the following additional changes have been made: - A test case in the validation function for ocf_is_probe has been reversed tp ! ocf_is_probe, and the test/[ ] wrappers removed to ensure the validation is not occuring if the partition is not mounted or under a probe. - An extraneous return code has been removed from the else clause of the probe test, to ensure the rest of the validation can finish. - The call to the DHCPD daemon itself during the start phase has been wrapped with the ocf_run helper function, to ensure that is somewhat standardized. The first two changes corrected the Failed Action... Not installed issue on the secondary node, as well as the fail-over itself. I've been able to fail over to secondary and primary nodes multiple times and the service follows the rest of the grouped services. There are a few things I'd like to add to the script, now that the main issues/code changes have been addressed, and they are as follows: - Add a means of copying /etc/dhcpd.conf from node1 to node2...nodeX from within the script. The logic behind this is as follows: I'd say that this is admin's responsibility. There are tools such as csync2 which can deal with that. Doing it from the RA is possible, but definitely very error prone and I'd be very reluctant to do that. Note that we have many RAs which keep additional configuration in a file and none if them tries to keep the copies of that configuration in sync itself. Seconded. Whatever configuration doesn't live _in_ the CIB proper, is not Pacemaker's job to replicate. The admin gets to either sync files manually across the nodes (csync2 greatly simplifies this; no need to reinvent the wheel), or put the config files on storage that's available to all cluster nodes. Cheers, Florian ___ 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-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-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-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-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
Re: [Linux-ha-dev] Additional changes made via DHCPD review process
On Fri, Dec 9, 2011 at 6:30 AM, Dejan Muhamedagic de...@suse.de wrote: Hi, On Tue, Dec 06, 2011 at 01:39:04PM -0400, Chris Bowlby wrote: Hi All, Ok, I'll look into csync, and will concede the point on the RA syncing the out of chrooted configuration file. I still need to find a means to monitor the DHCP responses however, as that will just improve the reliability of the cluster itself, as well as the service. I'm really not sure how to do that. Didn't review the agent, but on a cursory look, perhaps you could provide the default for chrooted_path (/var/lib/dhcp). BTW, did you think of adding an ocft test case? Please, cut the new guy some slack. :) Evidently this is Chris' first contributed RA, and he has been enormously responsive to our suggestions, and has drastically improved his agent from his first submission. I'm sure he'll get to ocft in due course. Cheers, Florian ___ 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/
Re: [Linux-ha-dev] Additional changes made via DHCPD review process
Hi Chris, On Fri, Dec 09, 2011 at 10:33:05AM -0400, Chris Bowlby wrote: Hi Dejan, It has been recommended, that required options should not have default values. Definitely they cannot have defaults. Sorry, I should've been more precise. The initial version of the script had a default for that variable, but chrooted_path was not required. During the revision's suggested by Andreas and Florian, chrooted was converted into a required, and unique, variable, with no default. I don't care much either way, it's just that I think that many of our RA just make use of the defaults coming from the standard installation and used by init scripts. Of course, if it makes sense, perhaps in this case it doesn't, I've never really looked into dhcpd configuration. The only point is that most configurations should work with as little effort as possible and I guess that people would usually run a single instance of dhcpd. As for an ocft test case, I've not had a chance to look into that in enough detail to be able to create any. I am hoping to be able to look it over this weekend. Whenever. It's just something which could help you to easier test the script. Cheers, Dejan On 12/09/2011 01:30 AM, Dejan Muhamedagic wrote: Hi, On Tue, Dec 06, 2011 at 01:39:04PM -0400, Chris Bowlby wrote: Hi All, Ok, I'll look into csync, and will concede the point on the RA syncing the out of chrooted configuration file. I still need to find a means to monitor the DHCP responses however, as that will just improve the reliability of the cluster itself, as well as the service. I'm really not sure how to do that. Didn't review the agent, but on a cursory look, perhaps you could provide the default for chrooted_path (/var/lib/dhcp). BTW, did you think of adding an ocft test case? Thanks, Dejan On 12/06/2011 12:20 PM, Alan Robertson wrote: I agree about avoiding the feature to sync config files. My typical recommendation is to use drbdlinks and put it on replicated or shared storage. In fact, I do that at home, and are doing it for a current customer. By the way, Sean has recently revised drbdlinks to support the OCF API. (In fact, it supports all of the OCF, heartbeat-v1 and LSB APIs). http://www.tummy.com/Community/software/drbdlinks/ You can find his source control for it on github: https://github.com/linsomniac/drbdlinks Quoting Florian Haasflor...@hastexo.com: On Tue, Dec 6, 2011 at 4:44 PM, Dejan Muhamedagicde...@suse.de wrote: Hi, On Tue, Dec 06, 2011 at 10:59:20AM -0400, Chris Bowlby wrote: Hi Everyone, I would like to thank Florian, Andreas and Dejan for making suggestions and pointing out some additional changed I should make. At this point the following additional changes have been made: - A test case in the validation function for ocf_is_probe has been reversed tp ! ocf_is_probe, and the test/[ ] wrappers removed to ensure the validation is not occuring if the partition is not mounted or under a probe. - An extraneous return code has been removed from the else clause of the probe test, to ensure the rest of the validation can finish. - The call to the DHCPD daemon itself during the start phase has been wrapped with the ocf_run helper function, to ensure that is somewhat standardized. The first two changes corrected the Failed Action... Not installed issue on the secondary node, as well as the fail-over itself. I've been able to fail over to secondary and primary nodes multiple times and the service follows the rest of the grouped services. There are a few things I'd like to add to the script, now that the main issues/code changes have been addressed, and they are as follows: - Add a means of copying /etc/dhcpd.conf from node1 to node2...nodeX from within the script. The logic behind this is as follows: I'd say that this is admin's responsibility. There are tools such as csync2 which can deal with that. Doing it from the RA is possible, but definitely very error prone and I'd be very reluctant to do that. Note that we have many RAs which keep additional configuration in a file and none if them tries to keep the copies of that configuration in sync itself. Seconded. Whatever configuration doesn't live _in_ the CIB proper, is not Pacemaker's job to replicate. The admin gets to either sync files manually across the nodes (csync2 greatly simplifies this; no need to reinvent the wheel), or put the config files on storage that's available to all cluster nodes. Cheers, Florian ___ 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-Dev: Linux-HA-Dev@lists.linux-ha.org
Re: [Linux-ha-dev] Additional changes made via DHCPD review process
On Fri, Dec 9, 2011 at 4:40 PM, Dejan Muhamedagic de...@suse.de wrote: Hi Chris, On Fri, Dec 09, 2011 at 10:33:05AM -0400, Chris Bowlby wrote: Hi Dejan, It has been recommended, that required options should not have default values. Definitely they cannot have defaults. Sorry, I should've been more precise. The initial version of the script had a default for that variable, but chrooted_path was not required. During the revision's suggested by Andreas and Florian, chrooted was converted into a required, and unique, variable, with no default. I am with Dejan on this one. People sometimes have their own ideas what required and default means in this case and make these arguments almost unusable. If /var/lib/dhcpd is what most people would have to type in, don't make it required and make it a default. If someone enters nothing, the default value should be used. So somewhat confusingly even if it is required parameter for your RA, it is a non-required OCF parameter. :) Rasto I don't care much either way, it's just that I think that many of our RA just make use of the defaults coming from the standard installation and used by init scripts. Of course, if it makes sense, perhaps in this case it doesn't, I've never really looked into dhcpd configuration. The only point is that most configurations should work with as little effort as possible and I guess that people would usually run a single instance of dhcpd. -- Dipl.-Ing. Rastislav Levrinc rasto.levr...@gmail.com Linux Cluster Management Console http://lcmc.sf.net/ ___ 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] resource unmanaged/failed
How much do they have now? They have 12G RAM. How much is in use by the radius servers? total used free sharedbuffers cached Mem: 12038 11606431 0 2 6479 -/+ buffers/cache: 5124 6913 Swap: 7632 3398 4233 And now I'm seeing again resource unmanaged/failed :( Resource Group: raddb raddb_ip (ocf::heartbeat:IPaddr2): Started radius1 (unmanaged) FAILED Failed actions: raddb_ip_monitor_15000 (node=radius1, call=4, rc=-2, status=Timed Out): unknown exec error raddb_ip_stop_0 (node=radius1, call=5, rc=-2, status=Timed Out): unknown exec error ___ 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] Q: OCFS on Dual-Primary DRBD: Wrong medium type
Hi! I have configured a Dual-Primary DRBD as disk for OCFS. Occasionally the Filesystem RA reports a Wrong medium type: Dec 7 16:44:46 h02 lrmd: [10930]: info: RA output: (prm_ocfs_fs_samba:1:start:stderr) /dev/drbd_r0: Wrong medium type What could be the reasons for that? (The problem occurred when the other node of the cluster had killed itself, and the cluster tried to recover from unclean state) 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] Q: OCFS on Dual-Primary DRBD: Wrong medium type
On Fri, Dec 9, 2011 at 1:56 PM, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de wrote: Hi! I have configured a Dual-Primary DRBD as disk for OCFS. Occasionally the Filesystem RA reports a Wrong medium type: Dec 7 16:44:46 h02 lrmd: [10930]: info: RA output: (prm_ocfs_fs_samba:1:start:stderr) /dev/drbd_r0: Wrong medium type What could be the reasons for that? (The problem occurred when the other node of the cluster had killed itself, and the cluster tried to recover from unclean state) Most likely, the Filesystem is trying to mount your DRBD while it's in the Secondary role. Usually caused an incorrect or missing order or colo constraint between Filesystem and drbd. And, please, if that is indeed the case: no lecture on DRBD doing or reporting the wrong thing here. It's not. Cheers, Florian -- Need help with High Availability? http://www.hastexo.com/now ___ 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] Q: OCFS on Dual-Primary DRBD: Wrong medium type
On Fri, Dec 9, 2011 at 2:00 PM, Florian Haas flor...@hastexo.com wrote: What could be the reasons for that? (The problem occurred when the other node of the cluster had killed itself, and the cluster tried to recover from unclean state) Most likely, the Filesystem is trying to mount your DRBD while it's in the Secondary role. Usually caused an incorrect or missing order or colo constraint between Filesystem and drbd. Apologies for the confusing omission. I meant to say Usually caused _by_ an incorrect Cheers, Florian -- Need help with High Availability? http://www.hastexo.com/now ___ 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
