On Sat, Jun 1, 2013 at 3:32 AM, Francois Mikus wrote:
> Hello,
>
Hi,
>
> For Shinken 1.6:
>
>
>1. Re-implement check_shinken to actually use PYRO to talk to each
>daemon and get pertinent statistics to actually determine that a daemon is
>really running. The same logic would apply
Hi,
lot of questions indeed :D
On Fri, May 31, 2013 at 2:43 PM, Imrane DESSAI wrote:
> [...]
> Have you some time to explain how concretely you will manage packs and
> modules ?
>
For each feature, I always got a phase where I describe it on paper, with
numerous corners cases. I didn't finish th
Hi everybody,
Last month I sourced out the shinken plugin (check_shinken) to a separate
repository [1].
I think splitting packs, modules and Shinken specific plugins from the core is
the first step on the way to 1.6.
[1] https://github.com/shinken-monitoring/check_shinken
Andreas
Am 01.06.201
Hello,
For Shinken 1.6:
1. Re-implement check_shinken to actually use PYRO to talk to each
daemon and get pertinent statistics to actually determine that a
daemon is really running. The same logic would apply to the arbiter,
the current "ping" is inadequate and leads to cases where daem
I saw your first commit about this.
Have you some time to explain how concretely you will manage packs and
modules ?
Where plugins (scripts) would be stored ?
Many time, a pack comes with its own plugin
Should we work with the plugin separately from the pack it belongs to ?
Can we include the plu
On Fri, May 31, 2013 at 2:03 PM, Jean-Michel Collongette <
jean.mic...@gmail.com> wrote:
> Hi,
>
> I agree to separe the packs from the shinken core.
>
> This way could be easy to manage enhancement and upgrade of single packs
> instead of wall of them currently.
>
> nero
>
> Thanks,
That's also
Hi,
I agree to separe the packs from the shinken core.
This way could be easy to manage enhancement and upgrade of single packs
instead of wall of them currently.
nero
2013/5/15 Imrane DESSAI
> Hi,
>
> It would be easier to manage each packs/modules separately. Each in its
> own repo.
> They
Hi,
It would be easier to manage each packs/modules separately. Each in its own
repo.
They could evolve at different speed from core with ease.
I think it would decrease load on core dev team so that they can focus on
core dev :p
PS : There's a typo in your link : https://npmjs.org/
2013/5/1
Hi all,
now the 1.4 is on RC, it's time to talk about the next one, the 1.6.
If we take a look back since the 1.0 version, there are more and more
contributors, that's great, thanks to all of you :D
If we take a closer look, we can see that the major part of the
contributions are about bug fix a