[ClusterLabs] iSCSILogicalUnit - scsi_id and multiple clusters

[Oyvind Albrigtsen]

On 06/03/20 13:22 +0200, Strahil Nikolov wrote:
>On March 6, 2020 11:06:13 AM GMT+02:00, Oyvind Albrigtsen <oalbrigt at redhat.com> wrote:
>>Hi Strahil,
>>
>>It seems like it tries to set one based on the resource name, and from
>>a quick check it seems like it also did on RHEL 7.5.
>>
>>https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/iSCSILogicalUnit.in#L57
>>
>>
>>Oyvind
>>
>>On 05/03/20 23:15 +0200, Strahil Nikolov wrote:
>>>Hey Community,
>>>
>>>I finaly got some time to report  an issue with iSCSILogicalUnit and
>>scsi_id  ( https://github.com/ClusterLabs/resource-agents/issues/1463
>>).
>>>
>>>The  issue was observed a while ago on RHEL 7.5 and SLES 12 SP4.
>>>
>>>Do you know if any change was made to:
>>>A)  Either make 'scsi_id'  a mandatory option
>>>B)  When 'scsi_id' is   not provided by the admin,  a random one is
>>picked (permanently)
>>>
>>>If not, then the github issue is relevant.
>>>
>>>Sadly, my exam (EX436) is on monday and I can't test it before that.
>>>
>>>Best Rregards,
>>>Strahil Nikolov
>>>_______________________________________________
>>>Manage your subscription:
>>>https://lists.clusterlabs.org/mailman/listinfo/users
>>>
>>>ClusterLabs home: https://www.clusterlabs.org/
>>>
>>
>>_______________________________________________
>>Manage your subscription:
>>https://lists.clusterlabs.org/mailman/listinfo/users
>>
>>ClusterLabs home: https://www.clusterlabs.org/
>
>Thanks for the reply, Oyvind
>
>In an environment with naming convention that allows globally non-unique  resource names - this could cause the behaviour I have described in github (2 clusters,  2 separate luns,  client's multipath aggregates them in 1 lun with 4 paths).
>
>Do you think that a better approach will be to  mark 'scsi_id' as mandatory option (of course  we can bypass with  'pcs  --force') or  we should randomly set one on resource creation if the value is not defined ?
>Of course  ,  the algorithm can get a little modification  - a random seed  for example.
>
>The second & third  options will be harder  to implement as we got both pcs  & crmsh actively used among distributions,  but will add some 'dummy proofness'. For me the first option is easiest to implement.
Adding info about it in metadata might be the best way to go.

Making it mandatory might annoy users who use Ansible or other
solutions to setup having to change their Playbooks to set it.
>
>
>Best Regards,
>Strahil Nikolov
>