To sum up briefly, I've only crossed over from the syseng discipline to the (perl) developer arena in the last few months. I knew it would be a major transition, but I still find myself getting the wind knocked out of me on occasion.

The specific instance I'm pondering is from my current project. I'm writing what is basically an asset tracker and Nagios configuration engine, with a user friendly interface all in one. We were discussing the topic of inheriting from nagios "template" service definitions1.

My thought was that, with the exception of creating circular inheritance, when a user creates a new template they should be allowed to inherit from basically any available template (keeping in mind that certain template types are only usable by certain device types). Nagios behaves this way, so I thought this application should probably behave this way also. After lengthy discussion both ways, I was finally met with "Because it's bad design." As the department newbie, I didn't even need to use the force to sense that it was time to stfu.

The other folks in my dept are of the opinion that it should be very specific, a top level master template, a command based template (i.e. "template_snmp_check"), a device based template (i.e. "template_snmp_check_Router"), and then, optionally, a custom template from which the actual registered service check definition will inherit configuration options.

I was wondering about the opinions of the other developers here. Is it good design to limit an application like this, which will control another application, to a rather enforced methodology? Or is it better to go with "Since Nagios can do it, this app should do it...?"

And also, has anyone else switched disciplines and experienced their own difficulties with the change?

1 (Quick Nagios explanation. Every item on every device you want to monitor in Nagios, disk space, cpu, router interfaces, running processes, etc, requires a service definition in the configuration. You don't have to create an entirely new service definition with every single configuration option every time, though. You can tell it a service name to use to inherit options, a parent template. Services can inherit from each other and have all sorts of parents, grandparents, gggggrandparents, etc.)

--
"This alcoholism thing, I think it's just clever propaganda produced by people who want you to buy more bottled water." -- pedestrianwolf

In reply to Design opinion, configuration inheritance by naChoZ

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.