On Tue, Nov 4, 2014 at 6:00 PM, Sebastien Coavoux <s.coav...@free.fr> wrote:
> Hi everyone! > Hi and thanks for the reporting :) (fore everyone: double post from Seb because of the mailing list internal that make it not enogh responding for Seb :) ). > [..] > > First of all, I would like to mention that this meeting was open to > everyone and so will be the next one. For this first appointment, we've > only tried to define the current state of the project. Feel free to join > us the next one if you've missed the first one. The summary is below. > Yes, we only announce it on IRC, because most of core devs where there. Next one (should be in november I think) will be announce there too :) > Shinken community feedback : > We got feedback from people that allow us to list most highlighted > features to use Shinken : > - Nagios configuration compatibility > - Scalability / Realm > - High customization with modules > - High availability feature > > To conclude this part we state that Shinken was not a "must-have" for > small IT structure but for bigger one. > Just a remark: if you did choose Shinken for another reason we will be hapy to know it. The better we know the framework use case, the better we can improve it in the good way :) > > Configuration management : > Arbiter restarts is always necessary when managing conf (with puppet, > chef etc). This leads to a potential issue : there is a period without > monitoring and where there is no UI feedback (user "It's not working"). > We assume 30-40 restart per day (average) > Possible solutions : > Make the broker load objects while the arbiter restarts. > Make the conf more granular so that we can send diff. But diff are > technically hard to code (hashing issues) > There are also environments with very small time to live that have to be > considerated (AWS instance, openstack etc). As the time to live is > short, arbiter has to restart more often. It can be achieved with a 5 > minutes time to restart. > Possible solution : > Add a host at runtime through a HTTP API without linking it to other > host (linking is very cpu/time consuming). This can be done in the next > release. > Restart time is both a technial and "user visibility" issue. Creating object, linking and serializing them is loooooooong for huge conf, and we also got a huge difference between "monitoring stop" and user perception here (UI stop are far longer than real monitoring one). I worked on a side project since few months that try to tackle a part of this issue and some are testing it. Shinken is very good at few restart => big check throughput, but far less in lot of restarts => new configuration latency. The new daemon I am working on is focus on this low configuration latency, but we will still need a Shinken API to get new hosts without realoading the whole configuration. This is our major technical objective for the next releases :) ps: I'll release the daemon as soon as it's out of its alpha stade and I wrote a first doc about it :p Will be in MIT or Apache2 licence (if someone got advice between the real difference between both licences I take it :) ). > > Documentation: > Drawbacks : > The ReadTheDocs doc is not very accessible to new users, there is too > much information in it. > Tutorials have not been updated since a long time (Shinken > installation, module installation) > Lack of developer doc. We should, at least, add docstring (for > sphinx) in API functions > > Benefits: > Shinken.io courses are a good beginning. We could take the example > of Mongodb courses (MOOC). Ease of learn is a reason to use a software > or not. > I plan to block one day each week for the online courses and tutorials. We got already lot of powerful features, but only few are knowing them. We should change this :) This is our major project non-technical objective. Every help there (write tuto, conferences, etc etc) will be greatly accepted :) > [...] > > Meetups : > Christophe Simon (geektophe) is volunteer to host a meetup (located > in Paris). He said he can buy beers :) > And my company can take care of pizzas :) > [...] > > > Shinken ecosystem: > Doc is a top priority. New users need more help > Third-party UI / software integration is also a priority (chef, > puppet, cfengine) > How to interact with other community and integrate Shinken to their > softwares? It was done easily with GPLI thank to ddurieux (core dev). > Puppet could be a first try as Olivier Hanesse (oliv-) worked on it > Shinken.io: We have to find the balance between well done (test, doc) > / packaged / community supported modules and modules from any other > contributeur (code quality may vary). A good way to do it may be a > naming convention so that new user can make the difference (livestatus > => official, username/liveblabla => not official). Examples : > (https://forge.puppetlabs.com/modules?utf-8=%E2%9C%93&sort=rank&q=apache), > for docker : > http://docs.docker.com/docker-hub/repos/#official-repositories > > I link this to the documentation part. It's really important to make the framework easy to install for a user of classic IT world tools, like puppet or metrology tools. Here it's more about documentation/tutorials and go talk to the other communities than really code. > > [...] > > Doc for dev: > Sebastien Coavoux and Thibault Cohen are ok with that but they > would like to do it with sphinx => Docstrings on functions (which is a > big no no for Nap :P) > > Plan next meeting : > Well, looks like I'm doing this :). We need to find the topic. > There was to much subject on the last one. Roadmap draft and release > date for 2.2 could be a good start :) > > I'm currenlty doing a tour of the github tickets. If there is no blocking bugs, I'll release a first RC that eeryone will be able to test. And remember: no test, no release, so please test it :) Jean
------------------------------------------------------------------------------
_______________________________________________ Shinken-devel mailing list Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel
