[hobbit] Future of Hobbit

[Buchan Milne]

On Wednesday 30 January 2008 23:43:06 Henrik Stoerner wrote:
> On Wed, Jan 30, 2008 at 10:06:09AM -0500, s_aiello at comcast.net wrote:
> > On Wednesday 30 January 2008, Henrik Stoerner wrote:
> > > This assumes you want to keep on using bb-hosts as the source of your
> > > layout - I don't think that is a good idea.
> >
> > The only reason I would assume the need to continue to use the bb-host
> > file as the source of layout, is because the Hobbit alert & threshold
> > 'PAGE=' specifications do.
>
> Correct, but the PAGE setting for alerts and client-thresholds does not
> have to be obtained from bb-hosts ... It is really just a way to
> classify a group of hosts as having "something" in common, and this can
> easily be done in a different configuration file format.
>
> Off the top of my head, it might even make sense to turn this entire
> concept upside-down: Instead of using a layout-definition to group hosts
> together in the alert/client config, we could use a *host*
> classification to define which hosts should be put on a given webpage.

Well, in my opinion, it is more important to be able to group hosts by 
configuration, rather than by layout, but maybe it would be better not to 
enforce a static layout.

For example, which servers you want to worry about changes (e.g. when you're 
on standby you may want to see everything, when you're not you may just want 
to look at specific servers), differs between different people. So, while a 
default layout is fine, I would like an interface that allows the user to 
save some layout profiles.

However, monitoring configuration has to be split from layout, must be 
extensible enough, and bindings created for common languages used for 
extensions, so that configuration for any extension can be done easily and 
consistently.

Grouping and/or inheritance must be consistent between configuration types. At 
present, you can group thresholds easily, and alerts easily (but 
independently of thresholds), but client-side configuration (e.g. log files 
to monitor) you can't.

So, something flexible enough to allow test configuration to inherit from one 
group, client configuration to inherit from another group, thresholds to 
inherit from another group, and can be overridden on a per-host per-test 
bases would be nice ... but hopefully not that flexible that we get to the 
Nagios situation.

> > And again, I am not a huge fan of XML, but it seems that it would be a
> > good option to migrate toward (from bb-hosts). That way if people did
> > want to write a new GUI for Hobbit it would not be difficult. It would
> > also be possible to add new fields, without affecting core Hobbit
> > functionality. i.e. writing a version of BBMap for hobbit.
> >
> > But again, I remember in a previous post your (and other maillist
> > members) reluctance to use XML for any configuration. So it almost seems
> > like a catch22.
>
> Well, I never said it would be easy :-) You are right, there are
> inherent conflicts between the different goals here. I am not a big fan
> for of XML configuration files (Hobbit doesn't have any, because I
> haven't bothered to go find a decent XML parsing library), but is IS a
> de-facto standard and there are lots of tools for handling such files.

Yes, it is a de-facto standard for information transfer between different 
applications, but as a user-interface it is very poor ...

> But I'd still like to weigh the pros and cons of using XML. Right now, I
> am not convinced.
>
> > So as I see it, ideally need a layout config that:
> > 1. Simple to define layout.
> > 2. Open to custom field definiton additions.
> > 3. Open to allow for 3rd party GUI development.
>
> These 3 I agree with.
>
> > 4. Doesn't break core hobbit functionality.
>
> This is something we can control ourselves. So don't let that stop you.

IMHO, some of the things relating to "core functionality" may need to be 
broken to be improved. For example, some Nagios fans complain all the time 
that the TCP checks aren't comprehensive enough (and writing new extensions 
that e.g. check pop3 with a user account and confirm that the mailbox list 
can be retrieved, for multiple virtual ISPs where the pop3 services run on 
different ports on the backend servers is impossible because there's no sane 
way to configure them).

Well, those are my thoughts so far on configuration.

Regards,
Buchan