04.07.2013 19:09, Dejan Muhamedagic wrote: > On Thu, Jul 04, 2013 at 05:40:07PM +0300, Vladislav Bogdanov wrote: >> 04.07.2013 17:25, Dejan Muhamedagic wrote: >>> On Wed, Jul 03, 2013 at 04:33:20PM +0300, Vladislav Bogdanov wrote: >>>> 03.07.2013 15:43, Dejan Muhamedagic wrote: >>>>> Hi Lars, >>>>> >>>>> On Wed, Jul 03, 2013 at 12:05:17PM +0200, Lars Marowsky-Bree wrote: >>>>>> On 2013-07-03T10:26:09, Dejan Muhamedagic <[email protected]> wrote: >>>>>> >>>>>>>> Not sure that is expected by most people. >>>>>>>> How you then delete attributes? >>>>>>> Tough call :) Ideas welcome. >>>>>> >>>>>> Set them to an empty string, or a magic "#undef" value. >>>>>> >>>>>>> It's not only for the nodes. Attributes of resources should be >>>>>>> merged as well. Perhaps to introduce another load method, say >>>>>>> merge, which would merge attributes of elements instead of >>>>>>> replacing them. Though the use would then get more complex (which >>>>>>> seems to be justified here). >>>>>> >>>>>> Well, that leaves open the question of how higher-level objects >>>>>> (primitives, clones, groups, constraints ...) would be affected/deleted. >>>>>> >>>>>> I'm not sure the complexity is really worth it. Merge rules get *really* >>>>>> complex, quickly. And eventually, one ends with the need to annotate the >>>>>> input with how one wants a merge to be resolved (such as "#undef" >>>>>> values). >>>>> >>>>> Perhaps I misunderstood the original intention, but the idea was >>>>> more simple: >>>>> >>>>> primitive r1 params p1="v1" p2="v2" meta m1="mv1" >>>>> >>>>> primitive r1 params p1="nv1" p3="v3" <- merge >>>>> >>>>> --- >>>>> >>>>> primitive r1 params p1="nv1" p2="v2" p3="v3" meta m1="mv1" >>>>> >>>>> If the attribute already exists, then it is overwritten. The >>>>> existing attributes are otherwise left intact. New attributes are >>>>> added. >>>> >>>> I'd simplify that logic to sections. >>> >>> Must say that it seems to me simpler and easier to grasp on the >>> attribute level. Besides, code for that already exists, so it >>> would reduce effort and code size/complexity :) Of course, >>> I can also see some use cases for the attribute-set level >>> operations. >> >> Ok, you know it much better ;) >> >>> >>>> * node attributes (except pacemaker internal ones like $id?) >>>> * node utilization >>>> * primitive params >>>> * primitive meta >>>> * primitive utilization >>>> * clone/ms meta >>>> >>>> If whole section is missing in the update, then leave it as-is. >>>> Otherwise (also if it exists but empty) replace the whole section. >>>> >>>> The only unclear thing is 'op', but this one can be replaced >>>> unconditionally (like in the current logic). >>> >>> I guess that it can be merged just like any other set of >>> attributes. Note that the user is free to specify the >>> operation fully if they really want to replace it completely. >>> >>> The only question is how to remove existing attributes. >> >> Not many choices here I think... Either set to empty or better >> predefined value (empty value may be still valid and used to override >> not-empty default one) like Lars suggested > > Yes, and that would be up to the users. > >> or use some additional >> formatting ( -param_name ). Second way probably requires new load method. > > That's the one I'd be interested in, but for now most of the > possibilities seem to come from the kludge domain :)
You may also look at ldif(5) (part of openldap) to see how this is solved in the LDAP world. May be that could give some valuable pointers (although I do not see how apply that directly). There are trick to replace only one value from a set (or to ensure that records virtual ID is not modified) - use delete/add instead of replace. > >>> BTW, did you ever try the configure filter command? >> >> Hm.. >> Not yet :) >> But how that can help? > > filter is to edit what sed to ed is. It got actually introduced > so that we can do automatic regression testing of the edit > command. You could conceivably, depending on your use case, > produce a script to get what you need. Just not sure how > difficult it would be to get the processing right. Thank you, but this is too complicated for my case. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
