Tony Asleson
2014-05-20 21:40:53 UTC
In preparation for release 1 I'm soliciting feedback on the public API.
These are the proposed changes that I found by looking over the mailing
list and the wiki. To keep this from getting dragged out, I'm limiting
the discussion to 5/30 as we need to pick something and go with it.
Note: Renaming existing methods/calls to conform to noun->verb is not
needed in this discussion, just send patch or email if you find
something that violates that.
1. Add filtering to listing methods in the form (search_key=None,
search_value=None). This would apply to methods such as: volumes,
disks, access_groups, initiators (if not removed), pools, systems.
My thought: Yes, but prioritize in order listed above, eg. filtering
volumes is more important than filtering systems.
2. Remove individual initiator support, only support access group
abstraction. This includes: initiators, initiator_grant,
initiator_revoke, volumes_accessible_by_initiator,
initiators_granted_to_volume.
My thought: Yes if we can make it work with arrays that don't support
access groups. If not it stays and plug-ins implement one or the other
as initially planned. Proof of concept has not been demonstrated.
3. access_group_grant, access_group_revoke,
volumes_accessible_by_access_group, access_groups_granted_to_volume.
Re-factor to utilize proposed class mask_info and change names from:
access_group_grant -> volume_mask
access_group_revoke -> volume_unmask
My thought: I believe the main reason would be to allow a client the
ability to list all mappings in one call via mask_infos(None, None)
Yes, if we have at least *one* array that supports this query without it
doing something similar to this in the plug-in implementation:
def mask_info(self, search_key=None, search_value=None, flags=0):
if search_key is None and search_value is None:
mask_info = []
for v in self.volumes():
for ag in self.access_groups_granted_to_volume(v)
mask_info.append(MaskInfo(ag.id, v.id))
return mask_info
Otherwise no.
4. volume_child_dependency, volume_child_dependency_rm,
fs_child_dependency, fs_child_dependency_rm. Replace with new code that
allows the user to list the relationships between them and modify those
relationships.
My thought: Yes, I believe we should remove these calls immediately and
introduce the ability to list relationships between volumes and fs and
modify them *after* release 1 is finalized.
5. Remove files parameter from:
def fs_snapshot_create(self, fs, snapshot_name, files, flags=0):
My thought: Yes, remove the 'files' parameter as we don't have a good
way to handle snapshots with individual files and querying for such things.
6. Add a private data value for every class that is preserved by the
client but not visible to it for the plug-in to leverage
My thought: Yes
What am I missing? Please discuss.
Regards,
Tony
These are the proposed changes that I found by looking over the mailing
list and the wiki. To keep this from getting dragged out, I'm limiting
the discussion to 5/30 as we need to pick something and go with it.
Note: Renaming existing methods/calls to conform to noun->verb is not
needed in this discussion, just send patch or email if you find
something that violates that.
1. Add filtering to listing methods in the form (search_key=None,
search_value=None). This would apply to methods such as: volumes,
disks, access_groups, initiators (if not removed), pools, systems.
My thought: Yes, but prioritize in order listed above, eg. filtering
volumes is more important than filtering systems.
2. Remove individual initiator support, only support access group
abstraction. This includes: initiators, initiator_grant,
initiator_revoke, volumes_accessible_by_initiator,
initiators_granted_to_volume.
My thought: Yes if we can make it work with arrays that don't support
access groups. If not it stays and plug-ins implement one or the other
as initially planned. Proof of concept has not been demonstrated.
3. access_group_grant, access_group_revoke,
volumes_accessible_by_access_group, access_groups_granted_to_volume.
Re-factor to utilize proposed class mask_info and change names from:
access_group_grant -> volume_mask
access_group_revoke -> volume_unmask
My thought: I believe the main reason would be to allow a client the
ability to list all mappings in one call via mask_infos(None, None)
Yes, if we have at least *one* array that supports this query without it
doing something similar to this in the plug-in implementation:
def mask_info(self, search_key=None, search_value=None, flags=0):
if search_key is None and search_value is None:
mask_info = []
for v in self.volumes():
for ag in self.access_groups_granted_to_volume(v)
mask_info.append(MaskInfo(ag.id, v.id))
return mask_info
Otherwise no.
4. volume_child_dependency, volume_child_dependency_rm,
fs_child_dependency, fs_child_dependency_rm. Replace with new code that
allows the user to list the relationships between them and modify those
relationships.
My thought: Yes, I believe we should remove these calls immediately and
introduce the ability to list relationships between volumes and fs and
modify them *after* release 1 is finalized.
5. Remove files parameter from:
def fs_snapshot_create(self, fs, snapshot_name, files, flags=0):
My thought: Yes, remove the 'files' parameter as we don't have a good
way to handle snapshots with individual files and querying for such things.
6. Add a private data value for every class that is preserved by the
client but not visible to it for the plug-in to leverage
My thought: Yes
What am I missing? Please discuss.
Regards,
Tony