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.
See inline.
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.
Awesome!
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:
http://www.cloudera.com/content/cloudera-content/cloudera-docs/Search/latest/Cloudera-Search-Installation-Guide/csig_install_search.html
and especially this part:
http://www.cloudera.com/content/cloudera-content/cloudera-docs/Search/latest/Cloudera-Search-Installation-Guide/csig_deploy_search_solrcloud.html
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:
https://github.com/cloudera/hue/blob/master/desktop/conf.dist/hue.ini#L63
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
effort.
Great! Would you be willing to help with a blog post on the release? ;-)
Sure.
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?
Makes sense.
Well, there's Hue Search app. Have you had a chance to try it?
Not yet. But will do.
Give it a try -- its like Google, but on your data ;-)
And the docs I quoted above cover it as well.
Thanks,
Roman.
Thanks!
Will take a look.
Thanks,
Bruno
