Konstantin Boudnik 2013-10-25, 20:54
Anatoli Fomenko 2013-10-25, 20:56
Andrew Purtell 2013-10-26, 00:59
Peter Linnell 2013-10-26, 02:42
Roman Shaposhnik 2013-10-26, 03:15
Andrew Purtell 2013-10-28, 14:48
Andrew Purtell 2013-10-28, 16:28
Andrew Purtell 2013-10-28, 21:21
Peter Linnell 2013-10-30, 19:43
Roman Shaposhnik 2013-10-31, 22:02
Roman Shaposhnik 2013-10-29, 01:31
Bruno Mahé 2013-10-29, 06:14
Roman Shaposhnik 2013-10-29, 22:49
-Re: [VOTE] Bigtop 0.7.0 RC0
Bruno Mahé 2013-10-30, 07:52
Since we are going to spin a new Apache Bigtop 0.7.0 RC1, here is my
formal -1 for Apache Bigtop 0.7.0 RC0.
On 10/29/2013 03:49 PM, Roman Shaposhnik wrote:
> On Mon, Oct 28, 2013 at 11:14 PM, Bruno Mahï¿½ <[EMAIL PROTECTED]> wrote:
>>> I would agree with that. The only trouble is I can't repro it :-(
>>> Could you please provide additional details on the JIRA?
>>> But if it is easy to repro (and I'm just missing something)
>>> I'd agree with you.
>> I updated the ticket with some more information.
>> If you still cannot reproduce it, feel free to ping me and I will give you
>> access to the instance.
>> At some point I was wondering if it is because I am mixing the amazon ami
>> with centos6 repos, but given every other service I try do work...
> Thanks for the details instructions on how to repro. It is indeed
> easily reproducible and it is also extremely easy to fix.
> Now, at this point, I'm absolutely in favor of spinning up RC1
> with the following fixes in: BIGTOP-1132 and BIGTOP-1129
> Both of those are really isolated fixes and here's what I'd like
> to propose: I respin on Wed and send out a new VOTE thread.
> This time, however, the voting will only go till noon on Sun 11/3.
> If anybody objects to that -- please let me know ASAP.
Sounds like a great plan.
I came home too late to verify the patch of BIGTOP-1129, but hopefully I
will be able to do so either tomorrow or Thursday.
> The rest of my comments inline:
>>> I can help with that. ;-) At least with the default use case. Let me know
>>> if you're still interested.
>> Sure. Any recommendations?
> Basically, you can simply follow this setup docs:
> and especially this part:
> It also covers Hue Search app. It would very nice if somebody
> can help come up with Bigtop-specific wiki docs, but for now
> Cloudera Search is close enough.
>>> At this point Puppet code is the most reliable way to deploy Hue. Part of
>>> it has to do that Hue now depends on way more external services than
>>> it uses to -- which means that you have to get configs 'just right'. Our
>>> puppet works great for that -- but that's for a fully distributed cluster.
>> I was not using puppet (on purpose).
>> I will give it another shot by looking at what our puppet recipes are doing
>> and see if any of these changes can be baked directly into our packages.
> Thanks! That would be appreciated.
>> Actually, it was the elasticsearch sink for flume which had me update Apache
>> Lucene jars.
>> I will probably open a ticket against Apache Flume directly sometimes this
>> week to ask for some clarification.
> Please do. I believe I fixed some of those issues in upcoming Flume 1.5.0
>>> WAT? Really. I'm pretty curious at this point
>> I had the same reaction.
>> But this was reported as blocked by noscript.
>> Also it seems to be a configuration activated by default:
> Do you think we can convince Hue upstream to not spy
> on its users by default? ;-)
> I guess worst case scenario -- we can always disable it downstream in Bigtop.
I will start with opening a ticket with Hue and Bigtop.
And as you said, worst case scenario, that flag can be disabled over here.
I opened https://issues.apache.org/jira/browse/BIGTOP-1135 to track that
>>> Great! Would you be willing to help with a blog post on the release? ;-)
>> Do you have anything particular in mind?
> Just a bit more verbose version of the feedback you've provided on this
> thread, I guess. Makes sense?
>>> Well, there's Hue Search app. Have you had a chance to try it?
Will take a look.