[Libstoragemgmt-devel] Suggest to remove access_group_add_initiator() and access_group_remove_initiatro() from SMI-S plugin.

[Gris Ge]

Hi,

After review the whole SNIA SMI-S "Masking and Mapping" profile,
I found two concerns for our codes in SMI-S plugin for
access_group_initiator_add() and access_group_initiator_delete():

1. Only EMC VNX tested as supported. But EMC VNX require WWNN to
be set simultaneously, with current code, we don't have a good way
to define that. If undefined, EMC VNX will copy WWPN as WWNN which
cause host HBA be rejected for connection. It will be hard for
administrator to debug out.
Frankly, no array is supported by access_group_initiator_add() in
SMI-S provider.
To fix that, we need to make sure defined init_id is already
registered properly in EMC VNX.
For other vendor, they are having different understanding about SPC,
I am working with IBM now.

2. The access_group_initiator_delete() is too risky to cause data lose or
data unavailable. I would like to disable it before we get it fully
tested on at least EMC/IBM/HDS[1] arrays.

Any ideas?

Thank you in advance.
Best regards.

[1] This is also the 'must-pass-at-least-not-broke' vendor list.

[Tony Asleson]

Post by Gris Ge
Hi,
After review the whole SNIA SMI-S "Masking and Mapping" profile,
I found two concerns for our codes in SMI-S plugin for
1. Only EMC VNX tested as supported. But EMC VNX require WWNN to
be set simultaneously, with current code, we don't have a good way
to define that. If undefined, EMC VNX will copy WWPN as WWNN which
cause host HBA be rejected for connection. It will be hard for
administrator to debug out.

What if we take out the functionality in access_group_initiator_add so
that we don't create the initiator unless it's iSCSI? Thus could we
avoid this issue?

Post by Gris Ge
Frankly, no array is supported by access_group_initiator_add() in
SMI-S provider.
To fix that, we need to make sure defined init_id is already
registered properly in EMC VNX.

I guess we could mark this functionality as unsupported for smi-s and
leave it enabled for the other plug-ins. Users would be restricted to
just masking/unmasking existing access groups and whatever initiators
they contain?

Post by Gris Ge
For other vendor, they are having different understanding about SPC,
I am working with IBM now.
2. The access_group_initiator_delete() is too risky to cause data lose or
data unavailable. I would like to disable it before we get it fully
tested on at least EMC/IBM/HDS[1] arrays.

Can you explain this some more? Why is HidePaths risky? Sure anytime
you remove access to a volume you better make sure that's what you want,
but it shouldn't be more risky than say ReturnToStoragePool?

Post by Gris Ge
Any ideas?

I think you should pose your question to the smis lab mailing list and
see what people have to say about it. I thought the
ExposePaths/HidePaths was well supported.

Thanks

Regards,
Tony