28.10.2014 21:15, David Vossel wrote: > > > ----- Original Message ----- >> 22.10.2014 12:02, Dejan Muhamedagic wrote: >>> On Mon, Oct 20, 2014 at 07:12:23PM +0300, Vladislav Bogdanov wrote: >>>> 20.10.2014 18:23, Dejan Muhamedagic wrote: >>>>> Hi Vladislav, >>>> >>>> Hi Dejan! >>>> >>>>> >>>>> On Mon, Oct 20, 2014 at 09:03:40AM +0300, Vladislav Bogdanov wrote: >>>>>> Hi Kristoffer, >>>>>> >>>>>> do you plan to add support for recently added "remote node attributes" >>>>>> feature to chmsh? >>>>>> >>>>>> Currently (at least as of 2.1, and I do not see anything relevant in the >>>>>> git log) crmsh fails to update CIB if it contains node attributes for >>>>>> remote (bare-metal) node, complaining that duplicate element is found. >>>>> >>>>> No wonder :) The uname effectively dubs as an element id. >>>>> >>>>>> But for bare-metal nodes it is natural to have ocf:pacemaker:remote >>>>>> resource with name equal to remote node uname (I doubt it can be >>>>>> configured differently). >>>>> >>>>> Is that required? >>>> >>>> Didn't look in code, but seems like yes, :remote resource name is the >>>> only place where pacemaker can obtain that node name. >>> >>> I find it surprising that the id is used to carry information. >>> I'm not sure if we had a similar case (apart from attributes). >>> >>>>>> If I comment check for 'obj_id in id_set', then it fails to update CIB >>>>>> because it inserts above primitive definition into the node section. >>>>> >>>>> Could you please show what would the CIB look like with such a >>>>> remote resource (in crmsh notation). >>>>> >>>> >>>> >>>> node 1: node01 >>>> node rnode001:remote \ >>>> attributes attr=value >>>> primitive rnode001 ocf:pacemaker:remote \ >>>> params server=192.168.168.20 \ >>>> op monitor interval=10 \ >>>> meta target-role=Started >>> >>> What do you expect to happen when you reference rnode001, in say: >> >> That is not me ;) I just want to be able to use crmsh to assign remote >> node operational and utilization (?) attributes and to work with it >> after that. >> >> Probably that is not yet set in stone, and David may change that >> allowing to f.e. new 'node_name' parameter to ocf:pacemaker:remote >> override remote node name guessed from the primitive name. >> >> David, could you comment please? > > why we would want to separate the remote-node from the resource's primative > instance name?
It breaks existing crmsh internal concept that every object in a CIB has unique name. This also breaks syntax of some existing commands, as Dejan says, f.e. crm configure show rnode001 or crm configure edit rnode001 (?) >From what I see it is very hard to modify crmsh to support objects with different types but with equal names, and that will definitely break its maturity. On the other hand, this feature is relatively new (has it ever been released?) so it is much simpler to "fix" that breakage in pacemaker. Best, Vladislav > > -- David > >> >> Best, >> Vladislav >> >>> >>> crm configure show rnode001 >>> >>> I'm still trying to digest having hostname used to name some >>> other element. Wonder what/where else will we have issues for >>> this reason. >>> >>> Cheers, >>> >>> Dejan >>> >>>> Best, >>>> Vladislav >>>> >>>>> Given that nodes are for the most part referenced by uname >>>>> (instead of by id), do you think that a configuration where >>>>> a primitive element is named the same as a node, the user can >>>>> handle that in an efficient manner? (NB: No experience here with >>>>> ocf:pacemaker:remote :) >>>> >>>> >>>> >>>>> >>>>> Cheers, >>>>> >>>>> Dejan >>>>> >>>>> >>>>>> >>>>>> Best, >>>>>> Vladislav >>>>>> _______________________________________________ >>>>>> 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 >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> _______________________________________________ >>> 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 >>> >> >> _______________________________________________ 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
