Build failed in Jenkins: Hadoop-Common-trunk #1097
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 via cmccabe)
[vinodkv] YARN-1833. Relocating CHANGES.txt entry in trunk and branch-2 to the
right location.
[vinodkv] YARN-1907. Merged into branch-2.4 also.
svn merge --ignore-ancestry -c 1585992 ../../trunk/ onto branch-2.4.
Fixed CHANGES.txt entries too.
[vinodkv] YARN-1883. Merged into branch-2.4 also.
svn merge --ignore-ancestry -c 1582862 ../../trunk/ onto branch-2.4.
Fixed CHANGES.txt entries too.
[tucu] HADOOP-10431. Change visibility of KeyStore.Options getter methods to
public. (tucu)
[tucu] HADOOP-10430. KeyProvider Metadata should have an optional description,
there should be a method to retrieve the metadata from all keys. (tucu)
[jing9] HDFS-6229. Race condition in failover can cause RetryCache fail to
work. Contributed by Jing Zhao.
[cnauroth] HDFS-6235. TestFileJournalManager can fail on Windows due to file
locking if tests run out of order. Contributed by Chris Nauroth.
[jeagles] HADOOP-8826. Docs still refer to 0.20.205 as stable line (Mit Desai
via jeagles)
[cnauroth] HDFS-6234. TestDatanodeConfig#testMemlockLimit fails on Windows due
to invalid file path. Contributed by Chris Nauroth.
--
[...truncated 60575 lines...]
Adding reference: maven.local.repository
[DEBUG] Initialize Maven Ant Tasks
parsing buildfile
jar:file:/home/jenkins/.m2/repository/org/apache/maven/plugins/maven-antrun-plugin/1.7/maven-antrun-plugin-1.7.jar!/org/apache/maven/ant/tasks/antlib.xml
with URI =
jar:file:/home/jenkins/.m2/repository/org/apache/maven/plugins/maven-antrun-plugin/1.7/maven-antrun-plugin-1.7.jar!/org/apache/maven/ant/tasks/antlib.xml
from a zip file
parsing buildfile
jar:file:/home/jenkins/.m2/repository/org/apache/ant/ant/1.8.2/ant-1.8.2.jar!/org/apache/tools/ant/antlib.xml
with URI =
jar:file:/home/jenkins/.m2/repository/org/apache/ant/ant/1.8.2/ant-1.8.2.jar!/org/apache/tools/ant/antlib.xml
from a zip file
Class org.apache.maven.ant.tasks.AttachArtifactTask loaded from parent loader
(parentFirst)
+Datatype attachartifact org.apache.maven.ant.tasks.AttachArtifactTask
Class org.apache.maven.ant.tasks.DependencyFilesetsTask loaded from parent
loader (parentFirst)
+Datatype dependencyfilesets org.apache.maven.ant.tasks.DependencyFilesetsTask
Setting project property: test.build.dir -
https://builds.apache.org/job/Hadoop-Common-trunk/ws/trunk/hadoop-common-project/target/test-dir
Setting project property: test.exclude.pattern - _
Setting project property: hadoop.assemblies.version - 3.0.0-SNAPSHOT
Setting project property: test.exclude - _
Setting project property: distMgmtSnapshotsId - apache.snapshots.https
Setting project property: project.build.sourceEncoding - UTF-8
Setting project property: java.security.egd - file:///dev/urandom
Setting project property: distMgmtSnapshotsUrl -
https://repository.apache.org/content/repositories/snapshots
Setting project property: distMgmtStagingUrl -
https://repository.apache.org/service/local/staging/deploy/maven2
Setting project property: avro.version - 1.7.4
Setting project property: test.build.data -
https://builds.apache.org/job/Hadoop-Common-trunk/ws/trunk/hadoop-common-project/target/test-dir
Setting project property: commons-daemon.version - 1.0.13
Setting project property: hadoop.common.build.dir -
https://builds.apache.org/job/Hadoop-Common-trunk/ws/trunk/hadoop-common-project/../../hadoop-common-project/hadoop-common/target
Setting project property: testsThreadCount - 4
Setting project property: maven.test.redirectTestOutputToFile - true
Setting project property: jdiff.version - 1.0.9
Setting project property: build.platform - Linux-i386-32
Setting project property: project.reporting.outputEncoding - UTF-8
Setting project property: distMgmtStagingName - Apache Release Distribution
Repository
Setting project property: protobuf.version - 2.5.0
Setting project property: failIfNoTests - false
Setting project property: protoc.path - ${env.HADOOP_PROTOC_PATH}
Setting project property: jersey.version - 1.9
Setting project property: distMgmtStagingId - apache.staging.https
Setting project property: distMgmtSnapshotsName - Apache Development Snapshot
Repository
Setting project property: ant.file -
https://builds.apache.org/job/Hadoop-Common-trunk/ws/trunk/hadoop-common-project/pom.xml
[DEBUG] Setting properties with prefix:
Setting project property: project.groupId - org.apache.hadoop
Setting project property: project.artifactId - hadoop-common-project
Setting project property: project.name - Apache Hadoop Common Project
Setting project property: project.description - Apache Hadoop Common Project
Setting project property: project.version - 3.0.0-SNAPSHOT
Setting project property:
Re: Plans of moving towards JDK7 in trunk
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 classpath compatibility to avoid fixing significant problems On 11 April 2014 23:05, Alejandro Abdelnur t...@cloudera.com wrote: newer jetties have non backwards compat APIs, we would break any user app using jetty (consumed via hadoop classpath) On Fri, Apr 11, 2014 at 2:16 PM, Steve Loughran ste...@hortonworks.com wrote: that doesn't actually stop is from switching in our own code to alternate web servers, only that jetty can remain a published artifact in the hadoop/lib dir On 11 April 2014 21:16, Alejandro Abdelnur t...@cloudera.com wrote: because it is exposed as classpath dependency, changing it breaks backward compatibility. On Fri, Apr 11, 2014 at 1:02 PM, Steve Loughran ste...@hortonworks.com wrote: Jetty's a big change, it's fairly intimately involved in bits of the code but: it's a source of grief, currently webhdfs is an example https://issues.apache.org/jira/browse/HDFS-6221 all YARN apps seem to get hosted by it too On 11 April 2014 20:56, Robert Rati rr...@redhat.com wrote: I don't mean to be dense, but can you expand on why jetty 8 can't go into branch2? What is the concern? Rob On 04/11/2014 10:55 AM, Alejandro Abdelnur wrote: if you mean updating jetty on branch2, we cannot do that. it has to be done in trunk. thx Alejandro (phone typing) On Apr 11, 2014, at 4:46, Robert Rati rr...@redhat.com wrote: Just an FYI, but I'm working on updating that jetty patch for the current 2.4.0 release. The one that is there won't cleanly apply because so much has changed since it was posted. I'll post a new patch when it's done. Rob On 04/11/2014 04:24 AM, Steve Loughran wrote: On 10 April 2014 18:12, Eli Collins e...@cloudera.com wrote: Let's speak less abstractly, are there particular features or new dependencies that you would like to contribute (or see contributed) that require using the Java 1.7 APIs? Breaking compat in v2 or rolling a v3 release are both non-trivial, not something I suspect we'd want to do just because it would be, for example, nicer to have a newer version of Jetty. Oddly enough, rolling the web framework is something I'd like to see in a v3. the shuffle may be off jetty, but webhdfs isn't. Moving up also lets is reliably switch to servlet API v3 But.. I think we may be able to increment Jetty more without going to java7, see https://issues.apache.org/jira/browse/HADOOP-9650 . -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Alejandro -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Alejandro -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Thinking ahead
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 has uncovered; so it will be nice to pull them them in. I'm thinking of an RC by end of the coming week - committers, please be *very* conservative when getting stuff into 2.4.1 (i.e. merging to branch-2.4). Next up, hadoop-2.5. I've updated https://wiki.apache.org/hadoop/Roadmap with some candidates for consideration - please chime in and say 'aye'/'nay' or add new content. IAC, I suspect that list is too large. Rather than wait for everything it would be better to plan on releasing it on a time-bound manner; particularly around the Hadoop Summit. If that makes sense; I think we should target branching for 2.5 by mid-May to get it stable and released by early June. Thoughts? thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Plans of moving towards JDK7 in trunk
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 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 classpath compatibility to avoid fixing significant problems On 11 April 2014 23:05, Alejandro Abdelnur t...@cloudera.com wrote: newer jetties have non backwards compat APIs, we would break any user app using jetty (consumed via hadoop classpath) On Fri, Apr 11, 2014 at 2:16 PM, Steve Loughran ste...@hortonworks.com wrote: that doesn't actually stop is from switching in our own code to alternate web servers, only that jetty can remain a published artifact in the hadoop/lib dir On 11 April 2014 21:16, Alejandro Abdelnur t...@cloudera.com wrote: because it is exposed as classpath dependency, changing it breaks backward compatibility. On Fri, Apr 11, 2014 at 1:02 PM, Steve Loughran ste...@hortonworks.com wrote: Jetty's a big change, it's fairly intimately involved in bits of the code but: it's a source of grief, currently webhdfs is an example https://issues.apache.org/jira/browse/HDFS-6221 all YARN apps seem to get hosted by it too On 11 April 2014 20:56, Robert Rati rr...@redhat.com wrote: I don't mean to be dense, but can you expand on why jetty 8 can't go into branch2? What is the concern? Rob On 04/11/2014 10:55 AM, Alejandro Abdelnur wrote: if you mean updating jetty on branch2, we cannot do that. it has to be done in trunk. thx Alejandro (phone typing) On Apr 11, 2014, at 4:46, Robert Rati rr...@redhat.com wrote: Just an FYI, but I'm working on updating that jetty patch for the current 2.4.0 release. The one that is there won't cleanly apply because so much has changed since it was posted. I'll post a new patch when it's done. Rob On 04/11/2014 04:24 AM, Steve Loughran wrote: On 10 April 2014 18:12, Eli Collins e...@cloudera.com wrote: Let's speak less abstractly, are there particular features or new dependencies that you would like to contribute (or see contributed) that require using the Java 1.7 APIs? Breaking compat in v2 or rolling a v3 release are both non-trivial, not something I suspect we'd want to do just because it would be, for example, nicer to have a newer version of Jetty. Oddly enough, rolling the web framework is something I'd like to see in a v3. the shuffle may be off jetty, but webhdfs isn't. Moving up also lets is reliably switch to servlet API v3 But.. I think we may be able to increment Jetty more without going to java7, see https://issues.apache.org/jira/browse/HADOOP-9650 . -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Alejandro -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Alejandro -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Plans of moving towards JDK7 in trunkqu r
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 (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 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 classpath compatibility to avoid fixing significant problems On 11 April 2014 23:05, Alejandro Abdelnur t...@cloudera.com wrote: newer jetties have non backwards compat APIs, we would break any user app using jetty (consumed via hadoop classpath) On Fri, Apr 11, 2014 at 2:16 PM, Steve Loughran ste...@hortonworks.com wrote: that doesn't actually stop is from switching in our own code to alternate web servers, only that jetty can remain a published artifact in the hadoop/lib dir On 11 April 2014 21:16, Alejandro Abdelnur t...@cloudera.com wrote: because it is exposed as classpath dependency, changing it breaks backward compatibility. On Fri, Apr 11, 2014 at 1:02 PM, Steve Loughran ste...@hortonworks.com wrote: Jetty's a big change, it's fairly intimately involved in bits of the code but: it's a source of grief, currently webhdfs is an example https://issues.apache.org/jira/browse/HDFS-6221 all YARN apps seem to get hosted by it too On 11 April 2014 20:56, Robert Rati rr...@redhat.com wrote: I don't mean to be dense, but can you expand on why jetty 8 can't go into branch2? What is the concern? Rob On 04/11/2014 10:55 AM, Alejandro Abdelnur wrote: if you mean updating jetty on branch2, we cannot do that. it has to be done in trunk. thx Alejandro (phone typing) On Apr 11, 2014, at 4:46, Robert Rati rr...@redhat.com wrote: Just an FYI, but I'm working on updating that jetty patch for the current 2.4.0 release. The one that is there won't cleanly apply because so much has changed since it was posted. I'll post a new patch when it's done. Rob On 04/11/2014 04:24 AM, Steve Loughran wrote: On 10 April 2014 18:12, Eli Collins e...@cloudera.com wrote: Let's speak less abstractly, are there particular features or new dependencies that you would like to contribute (or see contributed) that require using the Java 1.7 APIs? Breaking compat in v2 or rolling a v3 release are both non-trivial, not something I suspect we'd want to do just because it would be, for example, nicer to have a newer version of Jetty. Oddly enough, rolling the web framework is something I'd like to see in a v3. the shuffle may be off jetty, but webhdfs isn't. Moving up also lets is reliably switch to servlet API v3 But.. I think we may be able to increment Jetty more without going to java7, see https://issues.apache.org/jira/browse/HADOOP-9650 . -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Alejandro -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Alejandro -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system.
[jira] [Reopened] (HADOOP-10430) KeyProvider Metadata should have an optional description, there should be a method to retrieve the metadata from all keys
[ 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 two together. KeyProvider Metadata should have an optional description, there should be a method to retrieve the metadata from all keys - Key: HADOOP-10430 URL: https://issues.apache.org/jira/browse/HADOOP-10430 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Fix For: 3.0.0 Attachments: HADOOP-10430.patch, HADOOP-10430.patch, HADOOP-10430.patch, HADOOP-10430.patch Being able to attach an optional description (and show it when displaying metadata) will enable giving some context on the keys. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (HADOOP-10431) Change visibility of KeyStore.Options getter methods to public
[
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 of KeyStore.Options getter methods to public
--
Key: HADOOP-10431
URL: https://issues.apache.org/jira/browse/HADOOP-10431
Project: Hadoop Common
Issue Type: Improvement
Components: security
Affects Versions: 3.0.0
Reporter: Alejandro Abdelnur
Assignee: Alejandro Abdelnur
Fix For: 3.0.0
Attachments: HADOOP-10431.patch, HADOOP-10431.patch,
HADOOP-10431.patch
Making Options getter methods public will enable {{KeyProvider}}
implementations to use those classes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Thinking ahead
+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 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 has uncovered; so it will be nice to pull them them in. I'm thinking of an RC by end of the coming week - committers, please be *very* conservative when getting stuff into 2.4.1 (i.e. merging to branch-2.4). Next up, hadoop-2.5. I've updated https://wiki.apache.org/hadoop/Roadmap with some candidates for consideration - please chime in and say 'aye'/'nay' or add new content. IAC, I suspect that list is too large. Rather than wait for everything it would be better to plan on releasing it on a time-bound manner; particularly around the Hadoop Summit. If that makes sense; I think we should target branching for 2.5 by mid-May to get it stable and released by early June. Thoughts? thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Thinking ahead
+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. I think we should probably take YARN-1404 off the list - even with 3 months it's unlikely to be complete. On Sat, Apr 12, 2014 at 9:50 AM, Chris Nauroth cnaur...@hortonworks.comwrote: +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 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 has uncovered; so it will be nice to pull them them in. I'm thinking of an RC by end of the coming week - committers, please be *very* conservative when getting stuff into 2.4.1 (i.e. merging to branch-2.4). Next up, hadoop-2.5. I've updated https://wiki.apache.org/hadoop/Roadmap with some candidates for consideration - please chime in and say 'aye'/'nay' or add new content. IAC, I suspect that list is too large. Rather than wait for everything it would be better to plan on releasing it on a time-bound manner; particularly around the Hadoop Summit. If that makes sense; I think we should target branching for 2.5 by mid-May to get it stable and released by early June. Thoughts? thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Thinking ahead
+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 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. I think we should probably take YARN-1404 off the list - even with 3 months it's unlikely to be complete. On Sat, Apr 12, 2014 at 9:50 AM, Chris Nauroth cnaur...@hortonworks.com wrote: +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 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 has uncovered; so it will be nice to pull them them in. I'm thinking of an RC by end of the coming week - committers, please be *very* conservative when getting stuff into 2.4.1 (i.e. merging to branch-2.4). Next up, hadoop-2.5. I've updated https://wiki.apache.org/hadoop/Roadmap with some candidates for consideration - please chime in and say 'aye'/'nay' or add new content. IAC, I suspect that list is too large. Rather than wait for everything it would be better to plan on releasing it on a time-bound manner; particularly around the Hadoop Summit. If that makes sense; I think we should target branching for 2.5 by mid-May to get it stable and released by early June. Thoughts? thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- Zhijie Shen Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
[jira] [Resolved] (HADOOP-10431) Change visibility of KeyStore.Options getter methods to public
[
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 of KeyStore.Options getter methods to public
--
Key: HADOOP-10431
URL: https://issues.apache.org/jira/browse/HADOOP-10431
Project: Hadoop Common
Issue Type: Improvement
Components: security
Affects Versions: 3.0.0
Reporter: Alejandro Abdelnur
Assignee: Alejandro Abdelnur
Fix For: 3.0.0
Attachments: HADOOP-10431.patch, HADOOP-10431.patch,
HADOOP-10431.patch
Making Options getter methods public will enable {{KeyProvider}}
implementations to use those classes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
