Prior to the kerberos-config-get-iter call there is a net-interface-get-iter call. The purpose of the
net-interface-get-iter call is to fetch LIFs from the SVM.
What I've observed is:
- The net-interface-get-iter call fetches all LIFs from the SVM (including management LIFs)
- Manila than grabs the first LIF from the net-interface-get-iter response?
If this LIF happens to be a management LIf (instead of a data LIF) the workflow breaks. The reason for this can be seen in the API response. For a data LIF, kerberos-config-get-iter returns a valid response
even if there is no kerberos configuration. For a management LIF, kerberos-config-get-iter simply returns a null response (because there can be no kerberos configuration associated with a management LIF):
I might be misreading the fix, but it seems to just add logic to handle the API exception. Perhaps
a more elegant solution would be for Manila not to randomly select a SVM management LIF in the first place. And to ensure that kerberos-config-get-iter is only ever run against a data LIF (perhaps by adding a ‘default-data-files’ service policy parameter to the net-interface-get-iter call).
My fear is that you'll continue to have issues in that:
- Manila runs kerberos-config-get-iter against a SVM management LIF
- Manila thinks that there is no kerberos configuration...hence it doesn't need to worry about Kerberos
auth
- There actually is a Kerberos configuration present (albeit on the data LIFs)
Just a observation on this issue.
Prior to the kerberos- config- get-iter call there is a net-interface- get-iter call. The purpose of the get-iter call is to fetch LIFs from the SVM.
net-interface-
What I've observed is:
- The net-interface- get-iter call fetches all LIFs from the SVM (including management LIFs)
- Manila than grabs the first LIF from the net-interface- get-iter response?
If this LIF happens to be a management LIf (instead of a data LIF) the workflow breaks. The reason for this can be seen in the API response. For a data LIF, kerberos- config- get-iter returns a valid response config- get-iter simply returns a null response (because there can be no kerberos configuration associated with a management LIF):
even if there is no kerberos configuration. For a management LIF, kerberos-
data lif:
<?xml version='1.0' encoding='UTF-8' ?> www.netapp. com/filer/ admin'>
<netapp version='1.221' xmlns='http://
<!-- Output of kerberos- config- get-iter [Execution Time: 56 ms] -->
<attributes- list>
<kerberos- config- info>
< interface- name>manila- nfs-data- 01</interface- name>
< is-kerberos- enabled> false</ is-kerberos- enabled>
< vserver> demo-manila- svm</vserver>
</kerberos- config- info>
</attributes -list>
<num- records> 1</num- records>
<results status='passed'>
</results>
</netapp>
mgmt lif:
<?xml version='1.0' encoding='UTF-8' ?> www.netapp. com/filer/ admin'>
<netapp version='1.221' xmlns='http://
<!-- Output of kerberos- config- get-iter [Execution Time: 48 ms] -->
<num- records> 0</num- records>
<results status='passed'>
</results>
</netapp>
I might be misreading the fix, but it seems to just add logic to handle the API exception. Perhaps config- get-iter is only ever run against a data LIF (perhaps by adding a ‘default- data-files’ service policy parameter to the net-interface- get-iter call).
a more elegant solution would be for Manila not to randomly select a SVM management LIF in the first place. And to ensure that kerberos-
My fear is that you'll continue to have issues in that:
- Manila runs kerberos- config- get-iter against a SVM management LIF ..hence it doesn't need to worry about Kerberos
- Manila thinks that there is no kerberos configuration.
auth
- There actually is a Kerberos configuration present (albeit on the data LIFs)