Existing export rule's indices get changed, if new rules are added with existing indices

ZhengCai · ‎2017-01-25

Hi All,

Currently I am experimenting with export rules inside an export policy. The behavior I saw was that, if I add a new rule with an index that has already existed in the rule list, then the existing rules' indices could get changed. For example:

Rule list before addition:

Index Client-Match Protocol ...

1 10.10.10.10 NFS...

2 20.20.20.20 CIFS...

3 30.30.30.30 NFS3...

If I add a new rule, "1 40.40.40.40 NFS...", then the rule list will look like this:

1 40.40.40.40 NFS...

2 10.10.10.10 NFS...

3 20.20.20.20 CIFS...

4 30.30.30.30 NFS3...

Is this behavior expected? Is there any way to disable such behavior, and just fail the addition in the first place?

This is because it makes it really hard to track and maintain all the existing rules, especially the API "export-rule-destroy" only takes an index in order to remove a rule.

In addition, is there any mechanism to globally lock an export policy? Basically we want the behavior to be that after a policy is locked, all modification to that policy will fail, until it is released.

Thanks a lot in advance

Zheng

wh_slayer · ‎2017-01-26

You didn't say what version of ONTAP you're using but for as long as I can remember, yes, this is the expected behavior.

From the Clustered Data ONTAP® 8.3 Commands: Manual Page Reference, page 2353:

[-ruleindex ] - Rule Index This optional parameter specifies the index number of the export rule that you want to create. If you specify an index number that already matches a rule, the index number of the existing rule is incremented, as are the index numbers of all subsequent rules, either to the end of the list or to an open space in the list. If you do not specify an index number, the new rule is placed at the end of the policy's list.

----

Any particular reason you're specifying the index number? Are you wanting it to replace the rule at the specified index?

ZhengCai · ‎2017-01-26

Thanks a lot for the info, and currently I am using the ONTAP 9.0 API.

The reason I need the index number is that, for a backup task I need to temporarily add a rule to the policy. And after the task is done, I want to remove the rule so that the policy will stay clean.

Now that because the index could be changed by someone else concurrently and there is no locking mechanism, I could end up removing a wrong rule at the end.

A concrete example:

At beginning of the task, I added rule foo with index 10.

At the end of the task, to be safe, I query again and find out that the rule foo is still at index 10, then I send out the API call to remove index 10.

However, at the same time before the API call arrives, another admin accidently add another rule bar with the same index 10, and rule foo will get a new index 11.

Finally, my API call will actually remove rule bar, which is wrong.

Actually, you can also reproduce this by concurrently having two admin UI connections.

It seems this cannot be solved given the current export rule behavior. Is my understanding right?

Thanks again,

billyd · ‎2017-01-26

Hello ZhengCai,

Have you taken a look at the powershell APIs? I was able to delete a specific rule based on the clientmatch name as opposed to deleting it based on the rule index number. Here's an example:

PS C:\Users\billyd> Get-NcExportRule -Policy expol_v_script_test

PolicyName               RuleIndex    ClientMatch      Protocol     RoRule       RwRule       Vserver
----------               ---------    -----------      --------     ------       ------       -------
expol_v_script_test      1            test             {nfs}        {sys}        {sys}        vserver1
expol_v_script_test      2            linux_mgmt    {any}        {sys}        {sys}        vserver1
expol_v_script_test      3            192.168.50.44     {nfs}        {sys}        {sys}        vserver1

PS C:\Users\billyd> get-ncexportrule -Policy expol_v_script_test | ? {$_.ClientMatch -like 'test'} | Remove-NcExportRule -Confirm:$false

PS C:\Users\billyd> Get-NcExportRule -Policy expol_v_script_test

PolicyName               RuleIndex    ClientMatch      Protocol     RoRule       RwRule       Vserver
----------               ---------    -----------      --------     ------       ------       -------
expol_v_script_test      2            linux_mgmt    {any}        {sys}        {sys}        vserver1
expol_v_script_test      3            192.168.50.44     {nfs}        {sys}        {sys}        vserver1

asulliva · ‎2017-01-27

The API does have a query parameter which you can use to filter the result from any language. This is slightly different than what's happening in the PowerShell you showed...

# this will return all rules to the client, and the client will do Where-Object matching based
# on the sepcified attribute
Get-NcExportRule -Policy expol_v_script_test | ?{ $_.ClientMatch -like 'test' }

# this will perform filtering on the ONTAP side, returning only records which match
Get-NcExportRule -Query @{ PolicyName = 'expol_v_script_test'; ClientMatch = '*test*' }

The former works fine, but can be slower, particularly if there are a large number of records returned. I talked about this a bit here.

Hope that helps.

Andrew

If this post resolved your issue, please help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

billyd · ‎2017-01-27

Thanks, Andrew. I haven't used templates in any serious capacity. I'll check out your blog for details.

aborzenkov · ‎2017-01-26

Either there is API to do it, in which case it can be done from every language, or PowerShell cmdlet internally resolves rule number and has the same race condition.

ZhengCai · ‎2017-01-27

Thanks a lot for all of the replies!

It looks to me that the ONTAP API only support removal by index:

export-rule-destroy

Delete an Export rule configuration.

Input Name Range Type Description

policy-name export-policy-name Export policy name.

rule-index [0..2^32-1] integer Export rule index.

If my guess is correct, the Powershell cmdlet might be first quering the rule with the filtering attributes, and get the most-up-to-date index of that rule. And then using that index to dispatch the removal. But the race condition still exists, because before the rule is actually deleted, the index might have already changed.

If there is any way to remove the rule with out the need to query it first and then remove by index, that will be the best in my humble opinion (query and remove at the same time).

Thanks again for all the help.