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:Interesting idea...funny you should bring this up as I was actually
Galen Johnson wrote:
OK...we're getting to the point to where we need to consider theJust 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
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
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.
D'oh...there's a duh moment...how many rpms have I built that do just that...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).
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 :-).