ontap.Driver. GetVserverAggregateNames returns empty list

[frodopwns]

I am attempting to use ontap/azgo to retrieve a list of Aggregate names available on the netapp appliance but am running into issues.

aggs, err := n.driver.GetVserverAggregateNames()
if err != nil {
    return nil, err
}

return aggs, nil

returns an empty list while runing storage aggr show directly on the appliance shows 4 aggregates.

Running the azgo query directly shows a nil aggr-list:

version: 1.31
xmlns: http://www.netapp.com/filer/admin
results: resultStatusAttr: passed
resultReasonAttr: 
resultErrnoAttr: 
attributes-list: [
  aggr-list: nil
  allowed-protocols: [nfs cifs fcp iscsi ndmp]
  antivirus-on-access-policy: default
  comment:   
  disallowed-protocols: nil
  ipspace: Default
  is-config-locked-for-changes: false
  is-repository-vserver: false
  language: c.utf_8
  ldap-domain: nil
  max-volumes: unlimited
  name-mapping-switch: [file]
  name-server-switch: [file]
  nis-domain: nil
  operational-state: running
  operational-state-stopped-reason: nil
  qos-policy-group: nil
  quota-policy: default
  root-volume: vsdata_root
  root-volume-aggregate: data_sas_02
  root-volume-security-style: unix
  snapshot-policy: default
  state: running
  uuid: 930beb16-ea19-11e5-abd2-00a0989a327a
  volume-delete-retention-hours: 12
  vserver-aggr-info-list: nil
  vserver-name: vsdata
  vserver-subtype: default
  vserver-type: data
]
next-tag: nil
num-records: 1

Is there a known issue with this method? Am I missing something? Is there another way to get the list of aggregates?

I understand this API is not supported so no worries if you don't have time to respond!

Thanks!

[clintonk]

Did you delegate any aggregates to your SVM?

[adkerr]

As Clinton mentioned, this call was designed to list aggregates assigned to a specific svm, rather than enumerate all aggrs in a cluster

[frodopwns]

Ah! That must be it. We are not explicitly delegating any aggregates to the vserver.

Thanks for the quick response!

[clintonk]

FWIW, fixing issue #92 will use the same API you mentioned, which means that (like Trident already does) future releases of nDVP will likely require aggregate delegation to SVMs. So you might as well do that now.