Tony Asleson
2014-11-18 15:25:04 UTC
Previously targetd supported just initiator operations with
export_list, export_create, export_destroy
Why do we need to introduce these new API calls in targetd?
Thanks,
Tony
Hi Tony,export_list, export_create, export_destroy
Why do we need to introduce these new API calls in targetd?
Thanks,
Tony
Mask certain volume to a new initiator.
1. Reintroduce initiator based volume mask. Nothing need to be
changed on targetd side.
2. Access group create, then volume mask against access group.
Nothing need to be changed on targetd side, but LSM will have two
set of volume mask API: access group masking, initiator masking.
It's easy for design and code from LSM side, but for LSM user,
they will have to code much more lines.
Targetd need to allow create or list a initiator with no volume
masked.
We use these new methods(initiators(), initiator_create(),
initiator_delete()) to handle.
int LSM_DLL_EXPORT lsm_initiator_grant(lsm_connect *conn,
const char *initiator_id,
lsm_initiator_type initiator_type,
lsm_volume *volume,
lsm_access_type access,
lsm_flag flags);
So the user didn't need to create or get initiator list object
separately and then do the mask.
So why couldn't we do something like (need better name):
lsm_volume_mask_initiator_as_ag(connection,
"iqn.1994-05.com.domain:01.89bd01",
LSM_ACCESS_GROUP_INIT_TYPE_ISCSI_IQN, vol, LSM_CLIENT_FLAG_RSVD);
instead of this:
lsm_string_list *initiators = lsm_string_list_alloc(1);
lsm_string_list_append(initiators, "iqn.1994-05.com.domain:01.89bd01");
lsm_access_group *ag =
lsm_access_group_record_alloc(LSM_ACCESS_GROUP_FAKE_ID, "Unused name",
initiators, LSM_ACCESS_GROUP_INIT_TYPE_ISCSI_IQN, LSM_CLIENT_FLAG_RSVD);
lsm_volume_mask(connection, ag, vol, LSM_CLIENT_FLAG_RSVD);
If we did this then I believe targetd would not need new functionality
as this is what we were supporting before.
Regards,
Tony