On Wed, Oct 29, 2014 at 07:40:28AM +0300, Vladislav Bogdanov wrote: > 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.
Even though nodes may have ids different from their names, people are prone to reference them by name and not by some number such as 167906357. Well, we can't really blame them, can we. So, the node uname is effectively its name, for all intents and purposes. The fact that some programs need an unwieldy number to reference nodes do not change our perspective. > This also breaks syntax of some existing commands, as Dejan > says, f.e. It doesn't break the syntax, it just makes it impossible to reference CIB elements. If you have a node named xyz and then also a resource named xyz, how should a stupid program such as crmsh know what do you mean when you say "xyz"... > crm configure show rnode001 > > or > > crm configure edit rnode001 (?) ... just as you quoted here. > 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. It makes the current usage partly obsolete. We could introduce a new element naming scheme, such as <element-type>:<element-name>, but I wonder if that's absolutely necessary. > 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. It's not pacemaker, it's just a resource agent. Which makes it much easier to fix, just by introducing one parameter which would hold the remote node name. Thanks, Dejan > 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 > >>>>>> [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 > >>> _______________________________________________ > >>> 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
