> On Fri, Aug 14, 2009 at 5:05 PM, Hiren Patel wrote:
>> I could see this being useful for us, we also use nagios internally
>> extensively and a few teams share one distributed setup we have. we
>> don't currently make extensive use of servicegroups, but I can clearly
>> see how it would be useful to us, and if we ever do, we'd run into the
>> situation you have, but worse because we haven't gone with clear naming
>> schemes among the teams.
>
> I definitely understand this issue, most of our teams are good about
> using our conventions, but some do not and it leads to a bit of chaos
> when troubleshooting configs at times.
>
>>> 2) If so, what would be a preferred syntax to implement this?
>>> * Override the current functionality so that if a LHS or RHS of a
>>> members tuple doesn't match a host or service, host groups are
>>> assumed?
>> I'd prefer the above option. nagios already does this kind of assumption
>> making in macro processing and such (from what I make), so it wouldn't
>> be too much of a deviation in how things are done, in my opinion.
>
> Thanks for the feedback, I like this idea better as well as it doesn't
> change the struct representing the servicegroup.
>
> Will most likely start working on this internally next week.
>
cool, let us know how it goes, or if we can help with anything.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]