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. > >>> 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
