Software Development Kit (SDK) and API Discussions

Highlighted

NetApp Manageability SDK Feedback

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...

39 REPLIES 39
Highlighted

Re: NetApp Manageability SDK Feedback

That's great! Could you please post the link to the new SDK? Thanks,   -Wei

Highlighted

Re: NetApp Manageability SDK Feedback

Highlighted

Re: NetApp Manageability SDK Feedback

How about an application form that people who don't have Office 2007 can open?

Highlighted

Re: NetApp Manageability SDK Feedback

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

Highlighted

Re: NetApp Manageability SDK Feedback

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.

Highlighted

Re: NetApp Manageability SDK Feedback

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

Highlighted

Re: NetApp Manageability SDK Feedback

Hi Chris,

Thanks for the detailed explanation.

We will surely take this feedback into consideration for our upcoming releases.

Regards,

Sen.

Highlighted

Re: NetApp Manageability SDK Feedback

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

Highlighted

Re: NetApp Manageability SDK Feedback

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

Highlighted

Re: NetApp Manageability SDK Feedback

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

Highlighted

Re: NetApp Manageability SDK Feedback

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

Highlighted

Re: NetApp Manageability SDK Feedback

+1. There's absolutely no reason to reason you couldn't implement that form as a web form, PDF or even plain text file.

Highlighted

Re: NetApp Manageability SDK Feedback

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?

Highlighted

Re: NetApp Manageability SDK Feedback

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

Highlighted

Re: NetApp Manageability SDK Feedback

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.

Check out the KB!
Knowledge Base
All Community Forums