If you want to avoid locking anyone into anything, then do something
common -- like just produce exit codes and let your caller worry about
what to do with the data, or if you want to provide more information,
put it in a simple common format like JSON or CSV.
Once you start worrying about context and transport, you will likely
find yourself getting more and more aligned with some particular
project's way of thinking - and the more value you will likely wind up
providing. The more integration your customers have to do, the fewer
people will do it.
Did I miss the project name in my sloppy skim of the emails?
On 7/10/2014 3:39 AM, Leam Hall wrote:
Hey guys, I appreciate the responses.
Let me clarify a couple of points. In this case I'm both consumer and
producer of the open source project. The scripts are small and tend to
be run monthly, or so, and ensure security settings are in place.
One of the things I'm really interested in is not locking anyone in to
a post processing method. Some might use logger, some might use
Assimilation, some might just prefer syslog. While I personally like
the idea of directly feeding a CMDB other consumers might want
something totally different.
So the output should be verbose enough to be used over large systems,
slurped into some other system, and yet concise enough to to require
lots of programming to clean it up. I can easily see a post processing
script to take the output and "do stuff" with it.
Make sense? The short form is that I'm an open source developer trying
to not lock everyone into doing things the way I do.
Leam
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
