Re: [Linux-HA] Storing arbitrary metadata in the CIB
On 23/08/2013, at 5:54 PM, Ferenc Wagner wf...@niif.hu wrote: Andrew Beekhof and...@beekhof.net writes: On 22/08/2013, at 10:08 PM, Ferenc Wagner wf...@niif.hu wrote: Our setup uses some cluster wide pieces of meta information. Think access control lists for resource instances used by some utilities or some common configuration data used by the resource agents. Currently this info is stored in local files on the nodes or replicated in each primitive as parameters. Are you aware that resources can - have multiple sets of parameters, and No, I'm not sure what you're referring to here. http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Explained/#s-reusing-config-elements A typical resource: primitive id=ping-1 class=ocf type=ping provider=pacemaker instance_attributes id=ping-1-params nvpair id=ping-1-debug name=debug value=true/ nvpair id=ping-1-host_list name=host_list value=172.16.1.4/ nvpair id=ping-1-name name=name value=connected/ /instance_attributes operations op id=ping-1-monitor-60s interval=60s name=monitor/ /operations /primitive One with multiple sets of attributes: primitive id=ping-1 class=ocf type=ping provider=pacemaker instance_attributes id=ping-1-params nvpair id=ping-1-debug name=debug value=true/ nvpair id=ping-1-host_list name=host_list value=172.16.1.4/ nvpair id=ping-1-name name=name value=connected/ /instance_attributes instance_attributes id=ping-1-extra-params nvpair id=ping-1-extra name=extra value=something/ /instance_attributes operations op id=ping-1-monitor-60s interval=60s name=monitor/ /operations /primitive One with attributes defined by the previous resource: primitive id=ping-2 class=ocf type=ping provider=pacemaker instance_attributes id=ping-2-params nvpair id=ping-2-host_list name=host_list value=172.16.1.3/ nvpair id=ping-2-name name=name value=connected/ /instance_attributes instance_attributes id-ref=ping-1-extra-params/ operations op id=ping-2-monitor-60s interval=60s name=monitor/ /operations /primitive I guess not rsc_defaults or node specific parameters of clones. Maybe rules? I can't see them immediately useful. Could you please provide a pointer into Pacemaker 1.1 explained? (Btw. 5.7.2.3. Disabling a Monitor Operation misses the re-enable example at the end of the section.) - share sets of parameters Do you mean by using resource templates? Those indeed sound useful, thanks for the pointer! Used templates could store shared resource parameters, and unused templates could store global cluster parameters used by our management utilities. I'll give this a shot. -- Thanks, Feri. ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Storing arbitrary metadata in the CIB
Andrew Beekhof and...@beekhof.net writes: On 22/08/2013, at 10:08 PM, Ferenc Wagner wf...@niif.hu wrote: Our setup uses some cluster wide pieces of meta information. Think access control lists for resource instances used by some utilities or some common configuration data used by the resource agents. Currently this info is stored in local files on the nodes or replicated in each primitive as parameters. Are you aware that resources can - have multiple sets of parameters, and No, I'm not sure what you're referring to here. I guess not rsc_defaults or node specific parameters of clones. Maybe rules? I can't see them immediately useful. Could you please provide a pointer into Pacemaker 1.1 explained? (Btw. 5.7.2.3. Disabling a Monitor Operation misses the re-enable example at the end of the section.) - share sets of parameters Do you mean by using resource templates? Those indeed sound useful, thanks for the pointer! Used templates could store shared resource parameters, and unused templates could store global cluster parameters used by our management utilities. I'll give this a shot. -- Thanks, Feri. ___ 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] Storing arbitrary metadata in the CIB
22.08.2013 15:08, Ferenc Wagner wrote: Hi, Our setup uses some cluster wide pieces of meta information. Think access control lists for resource instances used by some utilities or some common configuration data used by the resource agents. Currently this info is stored in local files on the nodes or replicated in each primitive as parameters. I find this suboptimal, as keeping them in sync is a hassle. It is possible to store such stuff in the fake parameter of unmanaged Dummy resources, but that clutters the status output. Can somebody offer some advice in this direction? Or is this idea a pure heresy? You may use meta attributes of any primitives for that. Although crmsh doe not like that very much, it can be switched to a relaxed mode. ___ 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] Storing arbitrary metadata in the CIB
Vladislav Bogdanov bub...@hoster-ok.com writes: 22.08.2013 15:08, Ferenc Wagner wrote: Our setup uses some cluster wide pieces of meta information. You may use meta attributes of any primitives for that. Although crmsh doe not like that very much, it can be switched to a relaxed mode. OK, but the point is that this data is not specific to any resource, but cluster-global, so that would be unnatural. -- Cheers, Feri. ___ 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] Storing arbitrary metadata in the CIB
On 22/08/2013, at 10:08 PM, Ferenc Wagner wf...@niif.hu wrote: Hi, Our setup uses some cluster wide pieces of meta information. Think access control lists for resource instances used by some utilities or some common configuration data used by the resource agents. Currently this info is stored in local files on the nodes or replicated in each primitive as parameters. Are you aware that resources can - have multiple sets of parameters, and - share sets of parameters The combination might be useful here. I find this suboptimal, as keeping them in sync is a hassle. It is possible to store such stuff in the fake parameter of unmanaged Dummy resources, but that clutters the status output. Can somebody offer some advice in this direction? Or is this idea a pure heresy? -- Thanks, Feri. ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
