05.07.2013 14:38, Dejan Muhamedagic wrote: > On Fri, Jul 05, 2013 at 09:31:07AM +0300, Vladislav Bogdanov wrote: >> 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. > > Yes, something similar crossed my mind, but I wanted to avoid > too much verbosity.
Understand. May be it is possible to start with just not touch the whole section (like params, meta, utilization, node attributes) if it does not exist in the update, or if it contains just pre-defined value (f.e. "#keep")? Ughm... What if to introduce *optional* replacement policy for the whole section? I mean: params #merge param1="value1" param2="value2" meta #replace ... utilization #keep and so on. With default to #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. > > It seems to be too complicated for most uses :( Though something > similar with more use potential could most probably be designed. > > Thanks, > > Dejan > >> _______________________________________________ >> Linux-HA mailing list >> [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
