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
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
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