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 :) > > 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. Thanks, Dejan > Vladislav > > _______________________________________________ > 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
