You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the client/k8s.go file has nearly 530 LoC, a lot of which is just duplicated functionality or slightly similar functionality, e.g. GetCStorVolumeAttachmentMap(), GetCVA(string), etc.
There's a general trend in this file where-in, a resource has a wrapper to
GET a single resource of a particular KIND
LIST all the resources of a particular KIND
LIST all resource and return a map of them by some criteria, viz resource-name ➝ resource, or resource-label-key ➝ resource
All of this is helpful in different use-cases, but it sort of pollutes the method this package is exposing and it'll likely keep increasing as support for more features are added, for example client package could have methods such as GetPV, GetPVs, GetPVMap, GetAllCStorPV. If a new resource is added(e.g. CV), the problem will get worse as now, there might be 4 more methods per resource(assuming same or similar requirements)
Potential solution(s)
Low Hanging fruit
It might help crunch the LoC by merging some of GET & LIST functionality into one method, e.g. GetPV(pvName string) (*corev1.PersistentVolume, error) & GetPV() (*corev1.PersistentVolumeList, error) & GetPVs(pvNames []string) (*corev1.PersistentVolumeList, error) into ONE ListPV(vols []string) (*corev1.PersistentVolumeList, error)
The newer one can perform a
GET, if the vols list has exactly one element,
A LIST if vols list is nil
A LIST & filter out the vols PVs if a set of one or more volumes are specified
NOTE: Need to double-check if there'd be any possible dead-ends with this refactor, specially during the fetch of namespaced resources.
The text was updated successfully, but these errors were encountered:
Problem statement
Currently the client/k8s.go file has nearly 530 LoC, a lot of which is just duplicated functionality or slightly similar functionality, e.g.
GetCStorVolumeAttachmentMap()
,GetCVA(string)
, etc.There's a general trend in this file where-in, a resource has a wrapper to
All of this is helpful in different use-cases, but it sort of pollutes the method this package is exposing and it'll likely keep increasing as support for more features are added, for example client package could have methods such as
GetPV
,GetPVs
,GetPVMap
,GetAllCStorPV
. If a new resource is added(e.g. CV), the problem will get worse as now, there might be 4 more methods per resource(assuming same or similar requirements)Potential solution(s)
Low Hanging fruit
GetPV(pvName string) (*corev1.PersistentVolume, error)
&GetPV() (*corev1.PersistentVolumeList, error)
&GetPVs(pvNames []string) (*corev1.PersistentVolumeList, error)
into ONEListPV(vols []string) (*corev1.PersistentVolumeList, error)
vols
list has exactly one element,vols
list is nilvols
PVs if a set of one or more volumes are specifiedNOTE: Need to double-check if there'd be any possible dead-ends with this refactor, specially during the fetch of namespaced resources.
The text was updated successfully, but these errors were encountered: