Hello My coworkers would like to integrate volume-related tasks (creation, sizing, mounting, offlining, destroying) into their Salt-based automation/devops stack. They want to use a well documented REST interface if at all possible. I was asked to do some research into the best way for them to go about doing this and I think I'm more confused now vs when I started. NetApp has a handful of ways to skin this cat. I found:
- NMSDK is really raw, and support for Python seems pretty weak compared to PowerShell or Perl. We'd basically have to roll our own "thing". Too much time and effort reinventing the wheel.
- Some stuff on Github that kinda sorta might work, but was last updated years ago.
- Workflow Automation, but that seems overkill and pricy for what the (current) requirements are.
- ONTAP API Services which seems closest to what they want, but then gets tangled up in OCUM/OCPM? I guess this actually isn't a huge deal, as we do have OCUM 6.4P1 and OCPM 2.1.0P1 integrated together and looking at all of our clusters.
What are other people doing for automation of various storage related tasks?
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
Hi,
pay attention that API server is no longer present and/or suggested to use. The new SLM 1.0 integrates in it "also" the old API functionalities but at the same time offer a lot of tools to generate actions such as provisioning, tiering and monitoring with a "device agnostic" point of view. This is one of the step that NetApp moved toward its DataFabric vision, and cloud.
More on FieldPortal.
-----Messaggio originale----- Da: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] Per conto di Ehrenwald, Ian Inviato: venerdì 24 febbraio 2017 04:16 A: toasters@teaparty.net Cc: Larsen, Roy roy.larsen@hbgusa.com Oggetto: WFA vs OnCommand API Services vs NMSDK vs ..
Hello My coworkers would like to integrate volume-related tasks (creation, sizing, mounting, offlining, destroying) into their Salt-based automation/devops stack. They want to use a well documented REST interface if at all possible. I was asked to do some research into the best way for them to go about doing this and I think I'm more confused now vs when I started. NetApp has a handful of ways to skin this cat. I found:
- NMSDK is really raw, and support for Python seems pretty weak compared to PowerShell or Perl. We'd basically have to roll our own "thing". Too much time and effort reinventing the wheel.
- Some stuff on Github that kinda sorta might work, but was last updated years ago.
- Workflow Automation, but that seems overkill and pricy for what the (current) requirements are.
- ONTAP API Services which seems closest to what they want, but then gets tangled up in OCUM/OCPM? I guess this actually isn't a huge deal, as we do have OCUM 6.4P1 and OCPM 2.1.0P1 integrated together and looking at all of our clusters.
What are other people doing for automation of various storage related tasks?
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Hm, API Services no longer present or suggested? I don't think so. It is, I can see it in the SW download page:
OnCommand API Services 1.2 (GA)
New in this release
OnCommand API Services 1.2 includes the following new features:
Adding storage systems directly to the API server Provisioning capabilities using APIs Protection capabilities using APIs Jobs Configuration checker in the installer bundle Support for OnCommand Performance Manager headroom and cluster metrics Bug fixes
NetApp SLM 1.0 is currently a) only available for Linux and b) RC2 status. It doesn't express clearly anywhere that I have been able to find that API Service will be replaced completely by the new SLM (that may be the case?). It just says:
* Platform-specific device APIs for storage management * SLO-based APIs for service level management of storage resources * Access to pre-defined Storage Service Lvls by using the web UI and APIs * Automatic mapping of SSLs to storage resources * Automatic provisioning as per the storage service level by using APIs * Monitoring and regulating based on used or allocated capacity
So the point #1 may be what is in actual fact a replacement, or inclusion of the current API Services. I don't know, there's nothing anywhere that says this explicitly.
Anyone knows any more details around the plans fort his? Will API Services be decommissioned in the future (far or near)?
I'm a customer so the Field Portal doesn't really tell me anything
/M
On 2017-02-24 16:28, Milazzo Giacomo wrote:
Hi,
pay attention that API server is no longer present and/or suggested to use. The new SLM 1.0 integrates in it "also" the old API functionalities but at the same time offer a lot of tools to generate actions such as provisioning, tiering and monitoring with a "device agnostic" point of view. This is one of the step that NetApp moved toward its DataFabric vision, and cloud.
More on FieldPortal.
-----Messaggio originale----- Da: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] Per conto di Ehrenwald, Ian Inviato: venerdì 24 febbraio 2017 04:16 A: toasters@teaparty.net Cc: Larsen, Royroy.larsen@hbgusa.com Oggetto: WFA vs OnCommand API Services vs NMSDK vs ..
Hello My coworkers would like to integrate volume-related tasks (creation, sizing, mounting, offlining, destroying) into their Salt-based automation/devops stack. They want to use a well documented REST interface if at all possible. I was asked to do some research into the best way for them to go about doing this and I think I'm more confused now vs when I started. NetApp has a handful of ways to skin this cat. I found:
NMSDK is really raw, and support for Python seems pretty weak compared to PowerShell or Perl. We'd basically have to roll our own "thing". Too much time and effort reinventing the wheel.
Some stuff on Github that kinda sorta might work, but was last updated years ago.
Workflow Automation, but that seems overkill and pricy for what the (current) requirements are.
ONTAP API Services which seems closest to what they want, but then gets tangled up in OCUM/OCPM? I guess this actually isn't a huge deal, as we do have OCUM 6.4P1 and OCPM 2.1.0P1 integrated together and looking at all of our clusters.
What are other people doing for automation of various storage related tasks?
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc.
I just downloaded the Programmer's Guide for both SLM 1.0RC2 and API Services 1.2 and compared them.
Indeed these two PG's appear to be pretty much identical, the ToC is (quite clearly). Same no of pages, same page numbers etc -- it looks like the string "API Services" was replaced with "Service Level Manager" everywhere. Plus other significant changes and adjustments as well here and there, e.g. pp 7-8.
Interesting.
/M
On 2017-02-24 19:03,I wrote:
It doesn't express clearly anywhere that I have been able to find that API Service will be replaced completely by the new SLM (that may be the case?). It just says:
- Platform-specific device APIs for storage management
- SLO-based APIs for service level management of storage resources
- Access to pre-defined Storage Service Lvls by using the web UI and APIs
- Automatic mapping of SSLs to storage resources
- Automatic provisioning as per the storage service level by using APIs
- Monitoring and regulating based on used or allocated capacity
So the point #1 may be what is in actual fact a replacement, or inclusion of the current API Services. I don't know, there's nothing anywhere that says this explicitly.
Anyone knows any more details around the plans fort his? Will API Services be decommissioned in the future (far or near)?
I'm a customer so the Field Portal doesn't really tell me anything
/M
All
I have been a subscriber to this list for over 10 years. I appreciate the open dialog that we share. In that spirit I wanted to respond to the discussion on this particular thread. I reached out to our product team to get a clarification message on what the plans and intent are. This is what they said:
Thank you for taking interest in our automation and integration tool.
API Services designed to provide RESTful APIs for NetApp platforms. Latest version of API Services provides RESTful APIs for ONTAP. It exposes platform options for applications needing granular controls.
NetApp Service Level Manager (NSLM) is introduced to further simplify building solutions around NetApp platforms through SLO APIs which allows applications to focus on storage services and relieving them of platform specific nuances. The simplicity is built through service standardization, rapid service activation, and monitoring and regulation. From user experience point of view – 1) user downloads the product, 2) points to clusters to manage, and 3) initiates provisioning activity. SLM is shipped with pre-defined service levels. It has in built logic to provision volume/LUN on the right set of resources based on space and IOPS availability, regulate IOPS on ONTAP platform through QoS Policies, and monitor workload for service level compliance. All without human intervention. In order to offer complete set of RESTful APIs, Service Level Manager (SLM) produce is shipped with both SLO and platform RESTful APIs. This provides the flexibility for developers to choose level control required for their solutions.
API Service product with focus on bring RESTful APIs for NetApp platforms in a faster cadence will continue to be offered along with NetApp Service Level Manager. Customers will have the option of picking either of the two based on needs of their solution.
WFA is NetApp’s storage automation tool that enable customers to build workflows that stiches several atomic actions. Currently, WFA uses ZAPIs as command sets. Internally, there are discussions to enable WFA to leverage RESTful APIs, both platform and SLO variant to drive simplicity across the stack.
If you want more details, please reach out to your NetApp SE and they can (under NDA) get you the detail you need.
Cheers
Dave Dye Senior Systems Engineer
NetApp 604-421-3301 Direct 778-996-1884 Mobile Dave.Dye@netapp.commailto:Dave.Dye@netapp.com www.netapp.comhttp://www.netapp.com
Support: 1 888 4NETAPP (1 888 463 8277)
________________________________ From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net on behalf of Michael Bergman michael.bergman@ericsson.com Sent: Friday, February 24, 2017 10:42:35 AM To: Toasters Subject: Re: WFA vs OnCommand API Services vs NMSDK vs ..
I just downloaded the Programmer's Guide for both SLM 1.0RC2 and API Services 1.2 and compared them.
Indeed these two PG's appear to be pretty much identical, the ToC is (quite clearly). Same no of pages, same page numbers etc -- it looks like the string "API Services" was replaced with "Service Level Manager" everywhere. Plus other significant changes and adjustments as well here and there, e.g. pp 7-8.
Interesting.
/M
On 2017-02-24 19:03,I wrote:
It doesn't express clearly anywhere that I have been able to find that API Service will be replaced completely by the new SLM (that may be the case?). It just says:
- Platform-specific device APIs for storage management
- SLO-based APIs for service level management of storage resources
- Access to pre-defined Storage Service Lvls by using the web UI and APIs
- Automatic mapping of SSLs to storage resources
- Automatic provisioning as per the storage service level by using APIs
- Monitoring and regulating based on used or allocated capacity
So the point #1 may be what is in actual fact a replacement, or inclusion of the current API Services. I don't know, there's nothing anywhere that says this explicitly.
Anyone knows any more details around the plans fort his? Will API Services be decommissioned in the future (far or near)?
I'm a customer so the Field Portal doesn't really tell me anything
/M
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-
Dye, Dave -
Ehrenwald, Ian -
Michael Bergman -
Milazzo Giacomo