[hobbit] Shire: update

[Buchan Milne]

On Thursday 03 August 2006 19:09, Galen Johnson wrote:
> Buchan Milne wrote:
> >On Tuesday 01 August 2006 05:44, Galen Johnson wrote:
> >>Galen Johnson wrote:
> >>>Just wanted to give everyone a heads up on the new monitor site that
> >>>is being set up (theshire.sf.net)...Sourceforge accepted it late last
> >>>night ( around midnight EDT).   I want to work with Henrik a bit to
> >>>make sure that our visions converge on this.  I also need to set up
> >>>the categories (at a minimum) before turning everyone loose...I would
> >>>prefer there to be some structure in place beforehand.  Please be
> >>>patient...I really appreciate everyone's enthusiasm for this project
> >>>and I hope to have everything going in the next few days.  It's also
> >>>been a LONG time since I've done anything on SF and need to refresh my
> >>>memory about things (and become familiar with some of the new tools).
> >>>
> >>>=G=
> >>>
> >>>To unsubscribe from the hobbit list, send an e-mail to
> >>>hobbit-unsubscribe at hswn.dk
> >>
> >>OK...we're getting to the point to where we need to consider the
> >>categories...personally, I think deadcat has too many.
> >
> >My initial reaction to this is that I don't think a site with a collection
> > of categories and random scripts uploaded to the categories is the best
> > solution. I don't think the deadcat site should be the model. (If it
> > isn't, and you've meant something else by "categories", ignore the rest).
> >
> >Speaking from a software packaging point-of-view (I maintain ~ 60 packages
> > in Mandriva, most in contrib - including hobbit - but a few in the main
> > distribution, and also maintain roughly 50 packages that we use
> > internally, some of them being the ones I maintain for Mandriva), it's
> > not convenient to have to download, test, understand, debug each
> > extension script (or plugin for a web application).
> >
> >I would much prefer to work toward a realease strategy, where there may be
> > a release of all the "supported" extensions (maybe one release for client
> > extensions, and one for server extensions).
> >
> >This would also hopefully lead to having a more consistent set of
> > extensions, and instead of duplicating extensions when an author has not
> > been contributing to their extension anymore, it would be moved to
> > maintenance.
> >
> >Then, it would also be practical to package the extensions, and hopefully
> > all that would be required to use the extension would be to enable it
> > (eg, each extension should be shipped with a .cfg file suitable for
> > placement in a directory configured as an "include" directory in
> > hobbitlaunch.cfg) and add the necessary tags to the bb-hosts file.
> >
> >BTW, this is more or less what I have done with the 2 extension scripts I
> > have written for hobbit (one server extensions for
> > performance/replication monitoring of OpenLDAP, one client extension for
> > checking updates from RHN for RH boxen).
> >
> >Regards,
> >Buchan
>
> Interesting idea...funny you should bring this up as I was actually
> toying with the possibility of creating something that would allow you
> to select multiple monitors and bundle them together into a single
> download.   Regardless of the method used, there still needs to be
> something that tells people what they do, how they are to be set up, a
> way to upload them and a search function for people to find a monitor
> they are looking for (even if it's bundled with all the others, it may
> not be named what is expected).


Indeed. I agree there needs to be an easy way to discover extensions. However, 
that should not dictate the primary distribution means.

> I, personally, like the way you're doing it.  It makes a lot of sense
> and I can see how it could be used with a package manager to only
> install the monitors you want to deploy (maybe even a spec file that can
> be modified by those admins who don't want to clutter their install with
> a bunch of unused monitors).

Multiple subpackages could be created from one spec file, so distributing 
the "source" and installing the extensions don't necessarily need to be 
inter-dependant.

> As a sys admin, I tend to only want to 
> install what I need (I don't select the "Install Everything" option,
> it's anathema to my nature.

We have the same mentality here, which is why we have some tools to specify 
exactly which packages get deployed on which machines, depending on their 
role, their hardware type, etc etc.

> Of course, working towards a release strategy means only a select few
> would be allowed to upload or commit a monitoring script.  This would
> have the benefit of ensuring that monitors meet a certain standard and
> that duplicate monitors aren't commited but there's the administrative
> overhead of ensuring that every new release is tested with the monitors
> that are available to ensure compatibility (again, less of a community
> effort and more of an individual/committee effort).  I'd like to ensure
> that the monitors released meet a certain criteria...maybe have an
> "officially supported" area and a "I feel lucky" area.

Makes sense.

Note also that in some projects, that while only certain users may be able to 
commit, other contributors are often welcomed, and their contributions 
handled by contributors who have commit access, until they are trusted 
enough. Community shouldn't be lost in the effort to provide a consistent set 
of extensions, it should be leveraged but adhere to standards/guidelines (so 
as to not surprise the admin by doing something differently to other 
extensions for no reason).

> I'm still hoping someone will pony up a full tutorial...if this method
> ends up being the accepted method, we'll definitely need the
> tutorial/guideline available.

I would be happy to contribute (at least in draft form) based on what I have 
implemented myself so far, subject to the constraints of real work ...

Regards,
Buchan

-- 
Buchan Milne
ISP Systems Specialist
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20060803/010408e6/attachment.sig>