On Sat, Jun 1, 2013 at 3:32 AM, Francois Mikus <fmikus@acktomic.com> wrote:

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 daemons are actually not doing what they are supposed to. Identify key metrics for each daemon, implement a function to expose them and rewrite check_shinken to use it.
No pyro because we will remove it, but real and direct check yes. I don't plan to work on this before the new protocol backend is ready of course.
  1. Splitting packs, modules and core is a good idea, I have no opinion on how to go about doing this, but things seem to be looking up. Go team.
  2. Implement RPN + logic functions for bug-less triggers. We will be working on this.
I got nothing against it on modules (I'll provide hooks so will be possible), but not for core.
  1. Optimize Mongodb logstore functions for Livestatus so that it is actually usable in large installations. So that we can finally drop sqlite.
Sqlite is already not a good thing for very large setups. There is already a new index on the devel branch that can help mongodb setups.
  1. -1 for Implementing more database back ends. We should focus on making what we have work well.
For LS logs? It's just a matter of modules, but currently the 1.6 is focus on modules management from the core, not on modules directly yes.
  1. Focus on a solid 1.6 release with bug fixes and good plumbing.
  2. Commit new stuff to the development branch..
Nop. It's easier to manage on master for small things, and branch for large ones that will take times before being ok. I openend a branch-1.4 for the 1.4.1 if need, we will be able to cherrypick bug fix there is need (so bug fixes SHOULD be on master, then we will backeport them on this branch). I give a try to this way to see if it's not too much work. If it is not, we can keep it.