If anyone is interested in a Python SDK please register your interest here:
I have seen this requested/mentioned a few times but to allow PM to assign resources to this idea it needs votes
Would you consider a groovy extension to the JAVA SDK?
I sure would like to see a python SDK.
It has a large base of extensions including SNMP that can be very usefull.
At multiple places I "glue" different systems together using Python.
I feel it is good for quick fix solutions, and it is excelent for writing readable and reusable code.
Sure, SDK for Python and Ruby would be nice, but the be honest, before I see more SDKs for other interpreted languages, I would like to see the current perl SDK usable with OS versions of perl. Example on Redhat.
And if they do add Python/Ruby SDK, lets hope they make it work with OS versions of Python/Ruby, and not provide their own Python/Ruby version like they do with Perl (or at least make it optional).
Working with OS versions of Perl sounds nice, but I remember when the SDK was intended to be used that way. It was a bit messy. The binaries from Nimsoft are a little of a hassle to deploy (only because of their size) and deal with CPAN, but they work well with the SDK.
The problem with the OS versions of Perl was the version mismatches. And not just the version numbers, which would probably be a challenge across the various versions of Linux distirbutions. It seems like the build and architecture options also need to match exactly between Perl binaries and the modules. There may be ways to build and package Perl modules so that they are more generous in what they match for binaries, which would be preferable over separate binaries if feasible.
Thinking about this some more, here is a question for Carl (or anyone else at Nimsoft who is paying attention)...
When will we ever get feedback on this topic? That idea was posted almost 2 years ago, and we have no idea whether Python support is being developed, still under consideration, or completely rejected by product management.
Feedback on the ideas seems rare in general, although I do not look often. (I am not trying to turn this thread into a list of complaints about the ideas site. We could do a new thread for that if there is a need!)
I second Keith's request. Has been a while since it was requested for SDK and nothing to this date.
What was the outcome of this "election" for python SDK? I hope CA can see the importance of this issue for most companies using an advanced product like Nimsoft.
I can see the need for development of a python SDK.
I also find that continuous development is required to keep existing SDK's 'up to date'.
However since the NAS is native on LUA, I find the stop on developing this SDK probably even worse than not having up to date. other SDK's.
Perhaps the Nimsoft people are still waiting for the great ideas from the CA people? If that is the case they can wait for a long time. And unfortunately so can we.
Just a thaught or two:
For the Perl SDK issues mentioned earlier'; what about a "Pure Perl" solution? or at least one that replies only on common packages. It would be a little slower but could run on almost any installation.
What about a CLI 'SDK' option? That way a probe developer can choose to suffer the (slight) overhead of forking in exchange for being able to code in any language or revision they choose.
Hmmm... I could roll my own, at that. Spend some time fighting with C, then code at ease in any Perl I need.., Or bash.Anyone interested?
There is the probe utility that lets you do a lot of stuff through command line, but it'll fall short on some things.
In addition to the probe utility (pu command), the following commands give you much of the functionality you would need for a probe:
They would be perfectly suited to running in bash or any scripting language.
Long time luker, first time poster.
What were the results for a Python probe survey? As was mentioned before, Python 2.7 is natively installed on RHEL out of the box and is fairly easy to implement in Windows. It logically makes since for us as sys admins to try to limit our toolsets to what the vendor is supporting.
The same holds true for Powershell SDK. Nimsoft is some good stuff, I would like to see it continually evolve with the systems it gets deployed on Windows 2008 + 2012 are supporting PS out of the box and Windows has declared its allegiance to that scripting language.
I do like Keith's suggesting of just understanding how to run the system call from bash, then any language could in theory drop into the shell and put data on a PDS, create an alarm, etc.
I think the unofficial results for Python are...
Lots of people want it.
Silence from CA.
There is a .NET SDK, which works with PowerShell. All of the examples are in C#, which can make it tricky to figure things out if you are new to PowerShell. We got a short script working to create alarms from PowerShell--thanks to some help on this forum. Exploring that further is still on the to-do list.
Sorry for the silence. These threads help gauge the interest for features like this, but there's no implicit commitment in the question. Given the number of different scripting languages that people would like to see supported, my personal conclusion is that it may be more convenient to produce a language-agnostic interface.
Retrieving data ...