Hi Bob,
@ :: Of course anything can be done in code, but should it be needed to? Example - I write a script against OC-API to get a certain performance metric set for all volumes and do something with that.
-----
In my opinion having not needed to call APIs from multiple servers by my code is an insignificant advantage. I may not worry about it. A piece of code dosn't worry about calling 1 or 10 serves. Also it reduces my risk of single point of failure. If my OCUMs are fine but my API Server isn't, then this is blocking situation for me.
Also is it true that I really won't need to go to OCUM at all and my single point API server can do everything for me? My requirement also include to set alerts, watch and acknowledge events, modify thresholds, manage users etc. API Server can't do these, I would need to call the OCUM APIs.
So why would I have half API Server and half OCUM? Why not use the whole OCUM APIs. Thats why I asked in the beginning is there anything I can using API Server which I can't using OCUM APIs.
@ :: Configuration/capacity data comes from OCUM. Performance metrics come from perhaps multiple OPM's under one OCUM (as in my environment they do). So if the REST API were at OCUM/OPM, I'd still have to program against multiple data sources and coordinate which one held which data. Given a volume from OCUM for instance there isn't an easy way to determine which OPM holds the performance data unless one goes under the views that Netapp exposes in the database. Again - simpler to provide a one stop shop.
-----
Assume if REST APIs were available with OCUM itself. Then the above case you mentioned about single OCUM and multiple OPMs would certainly have been resolved.
My point is why does the REST API interface have to be at a new server. I see the importance of REST APis. But why at a new Sever outside of OCUM as new Product? What would I have missed if it were present at my OCUM?
sinhaa
If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.