[ClusterLabs] iSCSILogicalUnit - scsi_id and multiple clusters

Strahil Nikolov hunter86_bg at yahoo.com
Fri Mar 6 06:22:21 EST 2020


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.


Best Regards,
Strahil Nikolov


More information about the Users mailing list