[ClusterLabs] Antw: Re: Rename option group resource id with pcs

[Kristoffer Grönlund]

Ulrich Windl <Ulrich.Windl at rz.uni-regensburg.de> writes:

>>>> Dejan Muhamedagic <dejanmm at fastmail.fm> schrieb am 11.04.2017 um 11:43 in
> Nachricht <20170411094352.GD8414 at tuttle.homenet>:
>> Hi,
>> 
>> On Tue, Apr 11, 2017 at 10:50:56AM +0200, Tomas Jelinek wrote:
>>> Dne 11.4.2017 v 08:53 SAYED, MAJID ALI SYED AMJAD ALI napsal(a):
>>> >Hello,
>>> >
>>> >Is there any option in pcs to rename group resource id?
>>> >
>>> 
>>> Hi,
>>> 
>>> No, there is not.
>>> 
>>> Pacemaker doesn't really cover the concept of renaming a resource.
>> 
>> Perhaps you can check how crmsh does resource rename. It's not
>> impossible, but can be rather involved if there are other objects
>> (e.g. constraints) referencing the resource. Also, crmsh will
>> refuse to rename the resource if it's running.
>
> The real problem in pacemaker (as resources are created now) is that the "IDs" have too much semantic, i.e. most are derived from the resource name (while lacking a name attribute or element), and some required elements are IDs are accessed by ID, and not by name.
>
> Examples:
>     <cluster_property_set id="cib-bootstrap-options">
>       <nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="1.1
> .12-f47ea56"/>
>
> A <clone>s and <primitive>s have no name, but only an ID (it seems).
>
>           <op id="prm_DLM-start-0" interval="0" name="start" timeout="90"/>
>
> This is redundant: As the <op> is part of a resource (by XML structure) it's unneccessary to put the name of the resource into the ID of the operation.
>
> It all looks like a kind of abuse of XML IMHO.I think the next CIB format should be able to handle IDs that are free of semantics other than to denote (relatively unique) identity. That is: It should be OK to assign IDs like "i1", "i2", "i3", ... and besides from an IDREF the elements should be accessed by structure and/or name.
>
> (If the ID should be the primary identification feature, flatten all structure and drop all (redundant) names.)

The abuse of ids in the pacemaker schema is a pet peeve of mine; it
would be better to only have ids for nodes where it makes sense: Naming
resources, for example (though I would prefer human-friendly names
rather than ids with loosely defined restrictions). References to
individual XML nodes can be done via XPATH rather than having to assign
ids to every single node in the tree.

Of course, changing it at this point is probably not worth the trouble.

Cheers,
Kristoffer

>
> Regards,
> Ulrich
>
>> 
>> Thanks,
>> 
>> Dejan
>> 
>>> From
>>> pacemaker's point of view one resource gets removed and another one gets
>>> created.
>>> 
>>> This has been discussed recently:
>>> http://lists.clusterlabs.org/pipermail/users/2017-April/005387.html 
>>> 
>>> Regards,
>>> Tomas
>>> 
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >*/MAJID SAYED/*
>>> >
>>> >/HPC System Administrator./
>>> >
>>> >/King Abdullah International Medical Research Centre/
>>> >
>>> >/Phone:+96618011111(Ext:40631)/
>>> >
>>> >/Email:sayedma2 at ngha.med.sa/
>>> >
>>> >
>>> >
>>> >
>>> >------------------------------------------------------------------------
>>> >This Email and any files transmitted may contain confidential and/or
>>> >privileged information and is intended solely for the addressee(s)
>>> >named. If you have received this information in error, or are being
>>> >posted by accident, please notify the sender by return Email, do not
>>> >redistribute this email message, delete it immediately and keep no
>>> >copies of it. All opinions and/or views expressed in this email are
>>> >solely those of the author and do not necessarily represent those of
>>> >NGHA. Any purchase order, purchase advice or legal commitment is only
>>> >valid once backed by the signed hardcopy by the authorized person from NGHA.
>>> >
>>> >
>>> >_______________________________________________
>>> >Users mailing list: Users at clusterlabs.org 
>>> >http://lists.clusterlabs.org/mailman/listinfo/users 
>>> >
>>> >Project Home: http://www.clusterlabs.org 
>>> >Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf 
>>> >Bugs: http://bugs.clusterlabs.org 
>>> >
>>> 
>>> _______________________________________________
>>> Users mailing list: Users at clusterlabs.org 
>>> http://lists.clusterlabs.org/mailman/listinfo/users 
>>> 
>>> Project Home: http://www.clusterlabs.org 
>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf 
>>> Bugs: http://bugs.clusterlabs.org 
>> 
>> _______________________________________________
>> Users mailing list: Users at clusterlabs.org 
>> http://lists.clusterlabs.org/mailman/listinfo/users 
>> 
>> Project Home: http://www.clusterlabs.org 
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf 
>> Bugs: http://bugs.clusterlabs.org 
>
>
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://lists.clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

-- 
// Kristoffer Grönlund
// kgronlund at suse.com