Software Development Kit (SDK) and API Discussions
Software Development Kit (SDK) and API Discussions
Folks,
We've now merged the Manage ONTAP SDK and the initial version of NetApp Manageability SDK into one single SDK. Also, added new features like Web Services. Would like to hear your feedback...
That's great! Could you please post the link to the new SDK? Thanks, -Wei
How about an application form that people who don't have Office 2007 can open?
I second this.
I have no idea what you've done with the file but I can't get any converter to work with my Word 2003, and OpenOffice calls the doc corrupt...go figure.
Perhaps a PDF form, or why not just a simple text file...???
ken1
+1. There's absolutely no reason to reason you couldn't implement that form as a web form, PDF or even plain text file.
I'd be interested in what you mean by merged. Do you mean that there is a common set of libraries is NaElement and NaServer? Because in my mind these are just XML constructors and represent a small benifit to using either api. The API functionality is still very different between ontapi and dfm,
In general I think there is far too much work left to the user of the API with regard to buiding NaElements and unpacking returned data structures. It makes for very messy code. Imbedding this level of complexity in any code which does something even remotely complex leads to unreadable and hard to maintain code. There is also a lack of consistency between the methods.
e.g. a lot of methods use invoke ("method-name",
"object-name-or-id",
$name);
so why break this convention sometimes? as in
invoke( "dp-policy-list-iter-start",
"dp-policy-name-or-id",
$name );
The same comments apply to the return output and it's child elements. This leads to a ot o debugging, or Data::Dumper printing to work out what changed. I expect that there is a lot of client code out there which beraks you intended methods by using direct data structure access on the returned XML. I could understand why people would give up on endless get_child type operations.
These are all hurdles to wide adoption of your API. It is for these reasons that I am writtng an object oriented wrapper for the dfm api, so that I go throught he pain once and then consume this oo api many times in our functional code.
I'd be interested to know other oppinions on this. I'd also be interested in understanding if there is a demand for the perl OO version. I there is then I may post it on CPAN at some point.
Chris
Hi Chris,
Thanks for your feedback.
Are you expecting to see class-based approach for handling the APIs?
In other words, do you want to have each API to be represented by a class and the invoke method be a class method?
Just to make sure we understood your requirements properly, we are trying to represent it in the form of sample code/script:
use NaServer;
use DfmServerApi::Dataset::DatasetCreate; # the DatasetCreate.pm would contain API class and methods for invocation and parameter handling
my $s = NaServer->new($filer, 1, 1);
$s->set_admin_user($user, $password);
my $input = new DatasetCreate(); # create the object for the API which is represented as a class
$input->DatasetName = $dataset_name;
my $output = $input->invoke($s);
print "Dataset created with id: $output->DatasetId \n";
Please let us know if our undertsanding of your expectations/requirements is correct.
We will surely keep this in consideration for future releases of NM SDK.
Regards,
Sen.
I have one module NetApp.pm which consumes NaElement and NaServer as well as my own modules for DfmServer, Policy, DataSet etc... All the complexity of itter-start and itter-next as well as the datastructure access with get_child_string and get_child (which depends on a lot of implied knowledge of the returned data structure) is abstracted in these modules.
Using these modules I think the code looks cleaner. More importantly the resultant code does not require any knowledge of the returned data structure, protects against future changes by an abstration interface; it always passes back an inside out object with defined accessor methods. The end user can not abuse the datastructure with direct hash element access.
An example of use is shown below for comment.
use NetApp; # consumes NaElement, NaServer and NetApp::DFM
use warnings;
use strict;
use vars qw (
$DFMSERVER
$DFMUSER
$DFMPASSWORD
$POLICY
$DATASET
$VOLUME
);
# not real values obviously
$DFMSERVER = 'host1';
$DFMUSER = 'username';
$DFMPASSWOR = 'password';
$POLCY = 'Backup';
$DATASET = 'MyDataSet';
$VOLUME = 'filer1:/vol0';
my $dfm = NetApp::DFM::DfmServer->new(
{
hostname => $DFMSERVER,
username => $DFMUSER,
password => $DFMPASSWORD,
}
);
# fetch a volume
my $volume = $dfm->get_volume($VOLUME);
# fetch a policy
my $policy = $dfm->get_polict($POLICY)
# create a dataset
my $dataset = $dfm->create_dataset($DATASET);
# assign the policy to the dataset (returns the updated dataset)
my $dataset = $dataset->add_policy($policy->get_name);
# add a volume to the source node of the dataset as defined by the policy (returns the new list of members)
my @members = $dataset->add_member(
{ name => $volume->get_name,
node => $policy->get_from_name, }
);
The code just expresses the actions. I don't have to clutter it up with itter-start,next,end and there are no nested get_child('magic-name').
Does that make sense?
Chris
Hi Chris,
Thanks for the detailed explanation.
We will surely take this feedback into consideration for our upcoming releases.
Regards,
Sen.
I'm looking for the remote fpolicy interface. It seems (from some posts in the communities) that what I need is the fprequest.idl and/or fpcompletion.idl.
However, I can't find these files. Neither in the NM SDK 4.0 nor in the Manage OnTap SDK 3.5.1
Where can I get these APIs? Also, are there any samples available?
Regards
-Michael
Hi Mike
What you see in NM SDK are the only FPolicy related APIs available for Netapp outside customers. Other APIs are not available for generic consumption because of legal issues.
Sharyathi
Hi,
I'm working for a NetApp partner and we would like to implement a solution for a customer that could probably be solved very nicely with the full FPolicy API.
Is there any way for partners to obtain the full FPolicy API?
thanks
-Michael
Hi!
Can you pls let me know if the NetApp NM SDK can be used for simulating NetApp System Manager of File Manager functionalities through a third party solution?
You should be able to simulate most of the things in system manager.
You could see the sample codes as a starting point for basic functionalities
In the perl module NaElement.pm there is a child_add but no child_remove, can this be added.
I am working to update nfs exports. The implemention for an add is easy:
invoke nfs-exportfs-list-rules
retrieve exports-rule-info
child_add to root, read-only and/or read-write
Wrap it in a nfs-exportfs-modify-rule
But to remove a host is more complex,
invoke nfs-exportfs-list-rules
retrieve exports-rule-info
loop over exports-hostname-info, if it is not to be delete then it gets added to a new set for root, read-only and/or read-write
Wrap the new set in a nfs-exportfs-modify-rule
A child_remove would push the logic down to a lower level of code where I think it should belong...perhaps this could be utilized in other methods of manipulation.
Thanks for the feedback (child_remove).
We will surely take this input into consideration.
Regards,
Sen.
What is the proper way to report a bug ?
According to this post: http://communities.netapp.com/message/3284 a bug was identified with nfs-exportfs-delete-rules on Aug 26, 2008 9:55 AM with 3.0R1 API.
I am still seeing this issue as not resolved with netapp-manageability-sdk-4.0P1.
This is burt 323518. I just made it public, so it should appear in NOW is a day or so.
This is not an SDK issue, but an ONTAP documentation problem that the SDK imports ONTAP documentation. Please use <name>
instead of <pathname>, because the documentation will change, but not the implementation.
Hi,
We've just started to use the net-* features of the SDK and have some feedback on it.
1. It would be great if one were able to add comments into the persistent config. In the RC we've put in comments that help a Human make sense and link certain lines (logically) to the other filer head. Typically we would add comments for the ifconfig lines.
2. It's a shame all the sets/gets/create/add commands are all named inconsistently - if they matched it would look much better.
3. Some of our company experts thing the "savecore" command should be towards the top of the RC file.
4. Backups....it would be good if the "set-persistent" command could have a flag that would back up, say, the last 10 RC files.
5. vlan/ifconfig/ipspace - add/removes....it would be great if these commands had a boolean flag to persist their config into the RC file too.
Hopefully this is all helpful stuff.
Thanks,
Kevin Peirce