So for all the Acme users out there, is the huge cost for the EMS worth it to you? How many people use CLI vs EMS for their day to day actions? Some things lend more towards CLI (linux, cisco, asterisk) and some things just lend more towards GUI (Metaswitch, Broadsoft, Sonus Insight). -Scott
We only use CLI. The only thing I can see that may be useful is the Fault and Performance management. And that is if you don't already have something in place that reads SNMP traps, syslog, or something like MRTG. What I've found is that we have to do very little tweaking of the default settings for the various configuration elements. Once you create it and get it working, you generally leave it be and just add new and nearly identical items every so often. For instance: new SIP trunking customers. The "core" side pretty much never changes unless we're demoing equipment adding new equipment. I've never felt like I'm missing out and all our other equipment runs largely off GUI. ---- Brandon Buckner Switching Technician / VoIP Admin Iowa Network Services brandonb at netins.com<mailto:brandonb at netins.com> ________________________________ From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Scott Berkman Sent: Friday, September 11, 2009 5:12 PM To: voiceops at voiceops.org Subject: [LIKELY JUNK][VoiceOps] Acme: EMS or CLI? So for all the Acme users out there, is the huge cost for the EMS worth it to you? How many people use CLI vs EMS for their day to day actions? Some things lend more towards CLI (linux, cisco, asterisk) and some things just lend more towards GUI (Metaswitch, Broadsoft, Sonus Insight). -Scott
Acme is a victim of their own success on this one. It's so easy to manage the SDs over the CLI for a handful of boxes, and it plugs into our overall monitoring strategy so well that I've never thought of what I'm missing with the EMS. Size matters, so if we had a oodles of them it might be a different story. Along these lines, has anyone ever cooked up a decent perl module to work with the selecting and such needed to modify the config? It'd be pretty sweet to can some module that can work with their CLI paradigm as well as expect or net::telnet. David On Fri, Sep 11, 2009 at 3:44 PM, Brandon Buckner <BrandonB at netins.com> wrote:
We only use CLI. The only thing I can see that may be useful is the Fault and Performance management. And that is if you don?t already have something in place that reads SNMP traps, syslog, or something like MRTG. What I?ve found is that we have to do very little tweaking of the default settings for the various configuration elements. Once you create it and get it working, you generally leave it be and just add new and nearly identical items every so often. For instance: new SIP trunking customers. The ?core? side pretty much never changes unless we?re demoing equipment adding new equipment. I?ve never felt like I?m missing out and all our other equipment runs largely off GUI.
---- Brandon Buckner Switching Technician / VoIP Admin Iowa Network Services brandonb at netins.com
________________________________
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Scott Berkman Sent: Friday, September 11, 2009 5:12 PM To: voiceops at voiceops.org Subject: [LIKELY JUNK][VoiceOps] Acme: EMS or CLI?
So for all the Acme users out there, is the huge cost for the EMS worth it to you?
How many people use CLI vs EMS for their day to day actions?? Some things lend more towards CLI (linux, cisco, asterisk) and some things just lend more towards GUI (Metaswitch, Broadsoft, Sonus Insight).
??????????????? -Scott
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
David Hiers wrote:
Acme is a victim of their own success on this one. It's so easy to manage the SDs over the CLI for a handful of boxes, and it plugs into our overall monitoring strategy so well that I've never thought of what I'm missing with the EMS. Size matters, so if we had a oodles of them it might be a different story.
Aside from that, there is a generally pointless and misguided preoccupation throughout all departments of IT and communications with GUI administration tools and abstraction layers for everything. GUI tools are appropriate if - and only if - (1) they simplify a task so that lower-skilled people can be hired to do it as part of business processes replicated at decreasing marginal cost, or (2) if they make a task more efficient to perform. The latter is usually predicated on there being some level of unnecessarily granular detail that can be encapsulated in most common use cases. Anything truly complicated and granular at once will require a GUI that is equally complicated and granular, which is a waste of time and resources for both the vendor in producing it (and keeping it synchronised with the core product) and for the user in having to attain proficiency in learning the roundabout ways of the GUI. At that point, it's simpler to just use the CLI or other some-such allegedly "crude" interface. This obsessive fixation with GUIs, GUIs, GUIs for everything reminds me of many a misguided, disastrous "business process language" undertaking in the enterprise world, where an obsessive methodological preoccupation with divesting "programming" from "business logic" and/or the "business layer" leads to complicated domain-specific input with fat specifications, all in the name of supposedly protecting "business people" from having to write any actual code, per se. The end-result ends up being more obfuscated, conceptually elaborate, and intellectually demanding than just sitting down and writing code, and, in fact, the skills required turn out to be suspiciously similar to programming. The sort of thing that is BPEL and business-XML-such-and-such are good examples, and by far not the worst. Only now, it operates through an obese, lumbering interpreted mediation layer, requires expensive and time-consuming care and feeding (maintenance), and creates a hard bound on flexibility limited by that subset of the original programmatic options that are exposed by the new "interface."
Along these lines, has anyone ever cooked up a decent perl module to work with the selecting and such needed to modify the config? It'd be pretty sweet to can some module that can work with their CLI paradigm as well as expect or net::telnet.
I've written a number of such Perl scripts in the past to accomplish specific goals, but nothing in the way of a generic interface or general-purpose interaction layer. -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Have you looked at all into the ACP-XML api? I have an old doc from 4.1 on it but haven't seen much since. Seems like it would be a great way to integrate larger scale Acme provisioning and management with a home grown system. On Sat, 2009-09-12 at 19:10 -0700, David Hiers wrote:
Acme is a victim of their own success on this one. It's so easy to manage the SDs over the CLI for a handful of boxes, and it plugs into our overall monitoring strategy so well that I've never thought of what I'm missing with the EMS. Size matters, so if we had a oodles of them it might be a different story.
Along these lines, has anyone ever cooked up a decent perl module to work with the selecting and such needed to modify the config? It'd be pretty sweet to can some module that can work with their CLI paradigm as well as expect or net::telnet.
David
On Fri, Sep 11, 2009 at 3:44 PM, Brandon Buckner <BrandonB at netins.com> wrote:
We only use CLI. The only thing I can see that may be useful is the Fault and Performance management. And that is if you don?t already have something in place that reads SNMP traps, syslog, or something like MRTG. What I?ve found is that we have to do very little tweaking of the default settings for the various configuration elements. Once you create it and get it working, you generally leave it be and just add new and nearly identical items every so often. For instance: new SIP trunking customers. The ?core? side pretty much never changes unless we?re demoing equipment adding new equipment. I?ve never felt like I?m missing out and all our other equipment runs largely off GUI.
---- Brandon Buckner Switching Technician / VoIP Admin Iowa Network Services brandonb at netins.com
________________________________
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Scott Berkman Sent: Friday, September 11, 2009 5:12 PM To: voiceops at voiceops.org Subject: [LIKELY JUNK][VoiceOps] Acme: EMS or CLI?
So for all the Acme users out there, is the huge cost for the EMS worth it to you?
How many people use CLI vs EMS for their day to day actions? Some things lend more towards CLI (linux, cisco, asterisk) and some things just lend more towards GUI (Metaswitch, Broadsoft, Sonus Insight).
-Scott
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
anorexicpoodle wrote:
Have you looked at all into the ACP-XML api? I have an old doc from 4.1 on it but haven't seen much since. Seems like it would be a great way to integrate larger scale Acme provisioning and management with a home grown system.
Unless the API is so complicated[1] that it's easier to write an automated CLI-based provisioning wrapper for a narrow class of tasks. :-) I have encountered this a lot. Say I need a little tool to add a few routes to some piece of infrastructure. It is unlikely that the scope of the tool will substantially expand, and at any rate, it is certain that evolution toward a fuller OSS/BSS framework can be categorically ruled out. I can either spend half a day building a little wrapper with Net::Telnet + Expect, or I can sit there for a week trying to decipher some vastly overcomplicated enterprise-strength B2B/B2C 24/7 five-9s N+1 high-ROI clicks-and-mortar turn-key-convergent mission-critical service-impacting world-historic culture-transformative spiritually-transfigurative SOAP and/or WSDL monstrosity that requires maddeningly various client-side libraries, executes like an 800 lb. donkey stuck in a tar pit. There is real value to doing things the "right" way and diving into the latter. But the Byzantine thought patterns underlying the design philosophies of these things often weigh against it economically. -- Alex [1] I haven't seen this API, so, to be perfectly fair, I don't know. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
On Mon, 2009-09-14 at 01:12 -0400, Alex Balashov wrote:
anorexicpoodle wrote:
Have you looked at all into the ACP-XML api? I have an old doc from 4.1 on it but haven't seen much since. Seems like it would be a great way to integrate larger scale Acme provisioning and management with a home grown system.
Unless the API is so complicated[1] that it's easier to write an automated CLI-based provisioning wrapper for a narrow class of tasks. :-)
I have encountered this a lot. Say I need a little tool to add a few routes to some piece of infrastructure. It is unlikely that the scope of the tool will substantially expand, and at any rate, it is certain that evolution toward a fuller OSS/BSS framework can be categorically ruled out. I can either spend half a day building a little wrapper with Net::Telnet + Expect, or I can sit there for a week trying to decipher some vastly overcomplicated enterprise-strength B2B/B2C 24/7 five-9s N+1 high-ROI clicks-and-mortar turn-key-convergent mission-critical service-impacting world-historic culture-transformative spiritually-transfigurative SOAP and/or WSDL monstrosity that requires maddeningly various client-side libraries, executes like an 800 lb. donkey stuck in a tar pit.
There is real value to doing things the "right" way and diving into the latter. But the Byzantine thought patterns underlying the design philosophies of these things often weigh against it economically.
-- Alex
[1] I haven't seen this API, so, to be perfectly fair, I don't know.
Fortunately the ACP api seems like little more than a XML wrapper for the CLI, though there might be an advantage in that I am unsure if ACP locks the config session on an SD, where a scripted terminal session most surely would. Seems like a happy middle ground between the full blown EMS or managing them by hand. FWIW the EMS communicates with the SD via ACP
participants (5)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
BrandonB＠netins.com -
hiersd＠gmail.com -
scott＠sberkman.net