Just wanted to inquire as to the status 0.8 being released to beta.
I have several use cases now that would like to take advantage of the new features in 0.8, and I'm not sure if it makes sense to keep waiting for an actual release, before attempting to use the latest HEAD version in staging/production environments.
How stable is the 0.8 branch at this point? What is the schedule for a formal release? When will there at least be a link to 0.8 documentation, where to download it, on the main apache kafka site?
We are closely monitoring the health of one of our production clusters that has the 0.8 code deployed. This cluster is feeding off of LinkedIn's production traffic. Once this cluster is fairly stable, we'd like to run all of our tools and ensure those are working. Another thing we are trying is to introduce failures on this cluster when it is under load and ensure that there is no data loss.
So far, we've been working on stabilizing this cluster and fixing bugs. Next week, we will be working on tools and setting up audit so we can do some data loss analysis, if any. This will probably take another month. After that, I think we should be ready to release a public BETA and have our users try it. If we release it sooner than that, I'm not sure it will be helpful since tools and simple failure cases might not work as expected.
As far as formal release goes, I believe end of March or April will be a good timeframe. We will try our best to update documentation for the BETA release, 3-4 weeks from now.
Thanks, Neha On Thu, Feb 21, 2013 at 9:44 AM, Jason Rosenberg <[EMAIL PROTECTED]> wrote:
HEAD is good as of today and has been stable for past few days. There are some bugs we are working on but you can certainly run the cluster and do some basic send/receive operations. Also, let us know if you have feedback on the APIs, protocols, tools etc since that takes some time to refactor and change.
Good luck! :-)
Thanks, Neha On Thu, Feb 21, 2013 at 12:51 PM, Jason Rosenberg <[EMAIL PROTECTED]> wrote:
I understand that 0.8 is pre-beta, but to what extent would you say the bugs are mostly with the new redundancy code vs regressions in existing functionality; i.e. if wanting to prototype and deploy something over the next month or so with the view to deploying it within the next two months, is it safe-ish to go with 0.8 with replicated brokers turned off (for now) vs going with 0.7.2?
Also does anyone know the status of any node.js clients for 0.8
On Feb 21, 2013, at 3:32 PM, David Arthur <[EMAIL PROTECTED]> wrote:
0.8 is a significant rewrite since the 0.7 codebase. Hence, there is no easy way to "turn off" replication and expect 0.7.2 like functionality. Having said that, it is somewhat stable so you can use it for prototyping.
Thanks, Neha On Thu, Feb 21, 2013 at 1:42 PM, graham sanderson <[EMAIL PROTECTED]> wrote:
Thanks, so if I understand what you are saying is that 0.8 is alpha-ish; i.e. everything pretty much implemented (is there anything major missing - hard to tell looking at JIRA without much context) - we use at our own risk (which we're fine with), but that given we really want 0.8 features we can and should start testing with it today, with an expectation of a release in the next N months where N is hopefully no more than 2
On Feb 21, 2013, at 11:06 PM, Neha Narkhede <[EMAIL PROTECTED]> wrote:
As per 0.8, just a quick question about grabbing HEAD. What's the difference between the 0.8 branch and the trunk? Also should I take it from Neha's reply that replication is a must in using 0.8 even if you don't wish to use it? is there any design limitation (or operations aspect) that should make me want to use replication, even if data loss in case of a totally lost server - is not a major concern? On Fri, Feb 22, 2013 at 7:37 AM, graham sanderson <[EMAIL PROTECTED]> wrote:
Apache Lucene, Apache Solr and all other Apache Software Foundation project and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext