Build failed in Jenkins: Hadoop-Common-trunk #1097

2014-04-12 Thread Apache Jenkins Server
See https://builds.apache.org/job/Hadoop-Common-trunk/1097/changes Changes: [sandy] YARN-1923. Make Fair Scheduler resource ratio calculations terminate faster (Anubhav Dhoot via Sandy Ryza) [cmccabe] HDFS-6232. OfflineEditsViewer throws a NPE on edits containing ACL modifications (ajisakaa

Re: Plans of moving towards JDK7 in trunk

2014-04-12 Thread Steve Loughran
1. I wasn't thinking of sticking of jetty in in the web ui or webhdfs at all. 2. the later jetties change their packaing, so should be able to co-exist anyway. Jetty is a fundamental cause of problems, especially on things like webhdfs. We can't use the excuse of mustn't break downstream app

Thinking ahead

2014-04-12 Thread Arun C Murthy
Gang, With hadoop-2.4 out, it's time to think ahead. In the short-term hadoop-2.4.1 is in order; particularly with https://issues.apache.org/jira/browse/MAPREDUCE-5830 (it's a break to @Private API, unfortunately something Hive is using - sigh!). There are some other fixes which testing

Re: Plans of moving towards JDK7 in trunk

2014-04-12 Thread Alejandro Abdelnur
i disagree, mustn't break downstrea Alejandro (phone typing) On Apr 12, 2014, at 3:15, Steve Loughran ste...@hortonworks.com wrote: 1. I wasn't thinking of sticking of jetty in in the web ui or webhdfs at all. 2. the later jetties change their packaing, so should be able to co-exist

Re: Plans of moving towards JDK7 in trunkqu r

2014-04-12 Thread Alejandro Abdelnur
i disagree, mustn't break downstream app classpath is not an excuse, but a requirement. if you can make 2 versions of jetty to coexist because they are different packages (all their public apis) and they dont bump up transitive dependencies that break other things then is ok thx Alejandro

[jira] [Reopened] (HADOOP-10430) KeyProvider Metadata should have an optional description, there should be a method to retrieve the metadata from all keys

2014-04-12 Thread Owen O'Malley (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-10430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen O'Malley reopened HADOOP-10430: This is the *user* API. It doesn't control the remote interface. You should *NOT* tie the

[jira] [Reopened] (HADOOP-10431) Change visibility of KeyStore.Options getter methods to public

2014-04-12 Thread Owen O'Malley (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen O'Malley reopened HADOOP-10431: NO, this is not ok. The user API doesn't need the additional visibility. Change visibility

Re: Thinking ahead

2014-04-12 Thread Chris Nauroth
+1 The proposed content for 2.5 in the roadmap wiki looks good to me. On Apr 12, 2014 7:26 AM, Arun C Murthy a...@hortonworks.com wrote: Gang, With hadoop-2.4 out, it's time to think ahead. In the short-term hadoop-2.4.1 is in order; particularly with

Re: Thinking ahead

2014-04-12 Thread Sandy Ryza
+1 for starting to think about 2.5. Early June seems a little early to me - we had talked about a quarterly release cadence and this would be about half that. I'm having trouble editing the wiki, but I think Timeline Server stability (e.g. security and locking down APIs) should go on that list.

Re: Thinking ahead

2014-04-12 Thread Zhijie Shen
+1 for Timeline Server stability. In addition to the security, we may also want to deal with scalability, generic and per-framework services integration and MR integration. Any plan about YARN long running services? On Sat, Apr 12, 2014 at 10:09 AM, Sandy Ryza sandy.r...@cloudera.comwrote: +1

[jira] [Resolved] (HADOOP-10431) Change visibility of KeyStore.Options getter methods to public

2014-04-12 Thread Owen O'Malley (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen O'Malley resolved HADOOP-10431. Resolution: Fixed Sorry, looked at the wrong version of the patch. Change visibility