NetApp perl SDK API useradmin-role-modify with multiple capability entrie create only the first

[JD]

Hi,

i trying to make some automatisation scripts for some, let say stupid tasks.

as example I have created a script which one should modify the role capabilities, and it works fine, but only the first entry is aplyed everything else ist ignored, and i dont know why, could be some one can help my by this... here is my sourcecode:

			my $add_role = NaElement->new("useradmin-role-modify");
			my $add_role_sub = NaElement->new("useradmin-role");
			my $add_role_sub_info = NaElement->new("useradmin-role-info");
			my $add_role_sub_capa = NaElement->new("allowed-capabilities");
			my $add_role_sub_capa_info = NaElement->new("useradmin-capability-info");
			$add_role_sub_capa_info->child_add_string("name", 'api-disk-*');
			$add_role_sub_capa_info->child_add_string("name", 'api-clock-get-clock');
			$add_role_sub_capa_info->child_add_string("name", 'api-snapshot-list-info');
			$add_role_sub_capa_info->child_add_string("name", 'api-snapmirror-get-status');
...
			$add_role_sub_capa->child_add($add_role_sub_capa_info);
			$add_role_sub_info->child_add($add_role_sub_capa);
			$add_role_sub_info->child_add_string("name","test_role");
			$add_role_sub->child_add($add_role_sub_info);
			$add_role->child_add($add_role_sub);
			print $add_role->sprintf();     # to check the request struktur a preoutput of the request string
			
			my $role_results = $s->invoke_elem($add_role);
			print $role_results->sprintf(); # 

so far ok, but on the end it will only apply the green line

->child_add_string("name", 'api-disk-*');

all other redlines 

->child_add_string("name",...

are simply ignored.

strange but the structure of this is rigth and looks ok when i do a sprintf()

so my question:

howe i can make this change with the perl API? it looks like a multiple substring with same name are simpy ignored, or what i'm doing wrong? 

Thank you in advance!

[bobshouseofcards]

JD -

Suggestion, just so you can isolate whether it's an API issue or a setup/calling issue, is to manually use the ZEDI tool to build the equivalent XML and run it directly against your target controller/cluster.  If it doesn't work in the ZEDI tool with multple capabliities, then it just doesn't work and you can stop fighting the Perl to try and get it to work the way you've written it and approach it from a different angle.  

The ZEDI tool is part of the NMSDK and I find it extremely helpful to ensure I have all the right calling parameters as well as verifying the expected output.

Given the roles you have listed this appears to be in 7-mode.  Don't have a 7-mode system handy to check against, but the equivalent function - to add a capability to a role - in cluster mode appears to take a singleton role per call of the APi.  Hence multiple calls would be needed to setup all the roles you want.  If you verify that through ZEDI, then that's just how you have to write your code.

It makes sense that it would be a singleton due to the nature of the change.  For example - if one of the elements fails, how should any previous successful elements be processed?  Undo them (even if someone has already started using the capability), skip the failed one and process the rest, stop processing and leave what worked in place?  And then how to indicate what failed, especially if there were multiple failures?  Easier from a development and logic standpoint to simply allow only one update per call and make the requester call multuple times and thus let the requester determine the proper failure response.

Hope this helps -

Bob Greenwald

Lead Storage Engineer | Huron Legal

Huron Consulting Group

[JD]

I did use already ZEDI, no way there is the same result, look in the atached Screenshots first is the XML-Request:

and the Second are the results of it:

the main reason why i'm tryin to use it is that i want change some roles on our systems we have ~30 Filers and to do this manually everytime is not the perfect solution....

[bobshouseofcards]

JD - 

Actually, your ZEDI output shows exactly what I was talking about.  It appears that the first <useradmin-role-modify> call which had two capabilities in it only set one - "api-cifs-*" per the "list" API.  

That is either a bug in intended behavior or it is intended because of the two capabilities you listed - if you combine the two capabilities in the first call "api-*" and "api-cifs-*" the logical "least" capability intersection of those two is just "api-cifs-*".  More experimentation would be needed, or documentation, to ensure that's what it really does.  Of course given the code in the original post, I'm leaning toward "bug".

For the second call, remember that in the CLI you have to fully specify all permissions because modify acts as a replace.  So the second call, with just a single capability listed, modifies the role to have only those capabilities.  If you want to add a capability, you also need to specify all the existing capabilities, as I recall from the CLI.  If I remember correctly, and since the CLI just calls the underlying API, the 2nd output is what I would expect.

Bob