On 06/03/20 13:22 +0200, Strahil Nikolov wrote:
On March 6, 2020 11:06:13 AM GMT+02:00, Oyvind Albrigtsen <oalbr...@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


_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users

ClusterLabs home: https://www.clusterlabs.org/

Reply via email to