[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [hobbit] Shire: update

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).

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). 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.

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.

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.

=G=