[hobbit] Shire: update

[Galen Johnson]

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=