[hobbit] Shire: update

[Galen Johnson]

Buchan Milne wrote:

>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 agree...just making sure that we have a way to surface the info for users.

>>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.
>
>  
>
D'oh...there's a duh moment...how many rpms have I built that do just 
that...

>>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).
>
>  
>
Absolutely, the intention was never to exclude the community as a whole...

>>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 ...
>  
>
Thanks...I have exactly the same problem :-).

=G=