13:59:45 <tstclair> #startmeeting 13:59:45 <zodbot> Meeting started Thu Apr 10 13:59:45 2014 UTC. The chair is tstclair. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:09 <willb> howdy all 14:00:15 <tstclair> #meetingname BIG_DATA_SIG 14:00:15 <zodbot> The meeting name has been set to 'big_data_sig' 14:00:19 <rsquared> Hey Oooo 14:00:48 <tstclair> #meetingtopic status_update 14:01:20 <tstclair> Morning folks - Want to give a quick update and list any items to discuss... 14:02:16 <rsquared> Ported oozie and jung from collections-generic to commons-collections4, thus dropping the review request for collections-generic. jung has been reviewed and builtin rawhide. This morning I updated oozie to 4.0.1, still awaiting review 14:02:33 * tstclair continued upstream progress on Mesos. Found issues with cgroups and systemd, JIRA's opened, was able to integrate with spark. I will need to rebuild tachyon in a day or two. 14:03:01 <tstclair> My only issue I guess would be web-ui bundling issue in mesos. 14:03:05 <rsquared> hadoop 2.4.0 was released a few days ago and I am starting efforts to update the hadoop package. I'll resolve outstanding bzs at that time and, obviously, the ftbfs 14:03:12 <mizdebsk> #info Improved Ivy Packaging is accepted feature for F21 14:03:18 <mizdebsk> #link http://fedoraproject.org//wiki/Changes/ImprovedIvyPackaging 14:03:54 * pmackinn working on sqoop/tomcat integration for spec 14:05:59 <rsquared> pmackinn: How is sqoop using tomcat? webapp? 14:06:05 <pmackinn> indeed 14:06:24 <pmackinn> is there any other way? :-) 14:06:59 <rsquared> You might want to take a look at oozie if you haven't already. Using tomcat@ makes webapp deployment not so bad. 14:07:27 <mizdebsk> afaik jenkins also uses tomcat@ if you want another example 14:08:18 <pmackinn> ack all around but httpfs approach seems heavy 14:09:34 <rsquared> pmackinn: we should discuss outside the meeting. if you see a different way to do it I'm all ears. The approach I took was the only route I found to not collide with other tomcat instances and allow proper config 14:09:45 <rsquared> httpfs and oozie both use the same methods 14:10:14 <pmackinn> should be able to deploy multiple apps in same instance 14:11:09 <rsquared> Yep, but at a cost. Different port for the service and loss of some control over the specific webapp (if tomcat runs, so does it) 14:11:30 <rsquared> I messed with the app management webapp and found it lacking 14:12:11 <pmackinn> the alternative is that the fedora package is a template where everybody copies its files out? 14:12:16 * pmackinn looks for a bucket 14:13:38 <rsquared> That was the only solution I found. I didn't find too many people with much expertise in this area, and with tomcat@ running it's own instance it makes sense to allow it to be configured and secured completely separately from the system tomcat instance. 14:14:15 <pmackinn> then what, pray, is the system instance for? 14:14:51 <rsquared> There are some webapps that install and deploy through the system tomcat. I looked at them when I was tackling this for httpfs. 14:15:03 <rsquared> There aren't a lot of webapps in fedora though (that I found) 14:15:19 <pmackinn> yes, lacking good guidelines there 14:16:42 <pmackinn> if there's some conflict with say ceilometer that is a bug on their package imho 14:17:00 <rsquared> IMO, hadoop/oozie made sense to do the way they were because they use specific ports for their tomcat instances. The approach I took allowed for tomcat instances to run on those ports and maintain compatibility and control. Not sure if sqoop fits in those guidelines. The webapps deployed through system tomcat seemed simpler iirc. 14:17:59 <mizdebsk> IMO packaging webapps needs some discussion and standardization as currently it's a mess - each package does it differently 14:18:02 <rsquared> The only conflict I saw was a package inappropriately using the tomcat@ service. The system tomcat and the tomcat@ service would conflict 14:18:12 <rsquared> mizdebsk: +1 14:18:42 <tstclair> mizdebsk, +1 14:20:10 <tstclair> willb, rsquared, pmackinn, mizdebsk are there any other issues or new packages/changes in the works? 14:20:42 <willb> nothing new; if anyone is interested in a fairly straightforward ant-based packaging task, hit me up 14:21:15 <mizdebsk> there are some sisu bugs related to java 8 (currently affecting oozie build), which should be fixed soon 14:21:53 <rsquared> mizdebsk: I was able to get around the bugs by setting the targetjavaversion to 1.6. 14:22:08 <rsquared> The javaversion is set at 1.8, which gets around the oozie version check 14:22:20 <tstclair> willb, has anyone heard from besser re: Mahout & shift to spark? 14:22:54 <willb> tstclair, I haven't; I think he must be busy these days though 14:22:58 <willb> besser82, ? 14:23:01 <tstclair> yup 14:24:06 <tstclair> rsquared, could you send out an update when 2.4 is "all good", I'll plan a spin after that. 14:24:36 <rsquared> tstclair: Sure. I wouldn't expect it in the "soon" timeframe. :) 14:24:50 <tstclair> ack. 14:26:38 <tstclair> willb, pmackinn, rsquared, mizdebsk - anything else? Or shall we adjourn. 14:26:47 <mizdebsk> nothing from me 14:26:52 <rsquared> Nothing from me 14:26:53 <willb> nothing from me 14:26:54 <pmackinn> tstclair, all over mesos bundling? :-) 14:27:05 <pmackinn> needs tracking 14:27:08 <tstclair> BZ's 14:27:14 <tstclair> File away. 14:28:38 <pmackinn> so willb took care of swf, i guess i'll do js and fonts 14:29:11 <willb> swf is definitely the critical issue at this point 14:29:17 <tstclair> please do, if we have a wiki page around web-ui patterns it would be useful to me as I typically avoid that area. 14:29:30 <tstclair> patterns as in "fedora solutions" 14:29:45 <pmackinn> the font in question is packaged and needs to be symlinked 14:29:58 <pmackinn> .woff not permitted 14:32:29 <tstclair> File away, and I'll have to revisit. But again, I claim woeful ignorance on the non-java web-app front. 14:32:42 <tstclair> Any other items? 14:34:16 <tstclair> OK, thanks everyone. 14:34:25 <tstclair> #endmeeting