Re: #Contributors on JIRA
ASF JIRA has been moving to role-based over group-based security -you may be able to give more people a role than a group allows. But, as of last week and a spark-initiated change, by default contributors can't assign issues. someone could talk to infra@apache and see if a move would help On 14 May 2014 04:31, Suresh Srinivas wrote: > Last time we cleaned up names of people who had not contributed in a long > time. That could be an option. > > > On Mon, May 12, 2014 at 12:03 PM, Karthik Kambatla >wrote: > > > Hi devs > > > > Looks like we ran over the max contributors allowed for a project, > again. I > > don't remember what we did last time and can't find it in my email > either. > > > > Can we bump up the number of contributors allowed? Otherwise, we might > have > > to remove some of the currently inactive contributors from the list? > > > > Thanks > > Karthik > > > > > > -- > http://hortonworks.com/download/ > > -- > 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.
[jira] [Created] (HADOOP-10611) KeyVersion name should not be assumed to be the 'key name @ the version number"
Alejandro Abdelnur created HADOOP-10611: --- Summary: KeyVersion name should not be assumed to be the 'key name @ the version number" Key: HADOOP-10611 URL: https://issues.apache.org/jira/browse/HADOOP-10611 Project: Hadoop Common Issue Type: Bug Components: security Affects Versions: 3.0.0 Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur The KeyProvider public API should treat keyversion name as an opaque value. Same for the KMS client/server. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HADOOP-10588) Workaround for jetty6 acceptor startup issue
[ https://issues.apache.org/jira/browse/HADOOP-10588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kihwal Lee resolved HADOOP-10588. - Resolution: Fixed Fix Version/s: 2.5.0 0.23.11 Hadoop Flags: Reviewed Thanks for the reviews, Sangjin and Jon. I've committed this to branch-0.23 and branch-2. > Workaround for jetty6 acceptor startup issue > > > Key: HADOOP-10588 > URL: https://issues.apache.org/jira/browse/HADOOP-10588 > Project: Hadoop Common > Issue Type: Bug >Reporter: Kihwal Lee >Assignee: Kihwal Lee > Fix For: 0.23.11, 2.5.0 > > Attachments: selector.patch, selector23.patch > > > When a cluster is restarted, jetty is not functioning for a small percentage > of datanodes, requiring restart of those datanodes. This is caused by > JETTY-1316. > We've tried overriding isRunning() and retrying on super.isRunning() > returning false, as the reporter of JETTY-1316 mentioned in the description. > It looks like the code was actually exercised (i.e. the issue was caused by > this jetty bug) and the acceptor was working fine after retry. > Since we will probably move to a later version of jetty after branch-3 is > cut, we can put this workaround in branch-2 only. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: #Contributors on JIRA
On behalf of those of us who keep an eye on posts for commercial reasons (but do not contribute) Is there the option of setting up a list that accesses the dev comms, but doesn't impact the contributor list? P On Wed, May 14, 2014 at 4:31 AM, Suresh Srinivas wrote: > Last time we cleaned up names of people who had not contributed in a long > time. That could be an option. > > > On Mon, May 12, 2014 at 12:03 PM, Karthik Kambatla >wrote: > > > Hi devs > > > > Looks like we ran over the max contributors allowed for a project, > again. I > > don't remember what we did last time and can't find it in my email > either. > > > > Can we bump up the number of contributors allowed? Otherwise, we might > have > > to remove some of the currently inactive contributors from the list? > > > > Thanks > > Karthik > > > > > > -- > http://hortonworks.com/download/ > > -- > 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] [Created] (HADOOP-10612) NFS failed to refresh the user group id mapping table
Brandon Li created HADOOP-10612: --- Summary: NFS failed to refresh the user group id mapping table Key: HADOOP-10612 URL: https://issues.apache.org/jira/browse/HADOOP-10612 Project: Hadoop Common Issue Type: Bug Components: nfs Affects Versions: 2.4.0 Reporter: Brandon Li Assignee: Brandon Li Attachments: HADOOP-10612.002.patch, HADOOP-10612.patch Found by Preetham Kukillaya. The user/group id mapping table is not update periodically. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: #Contributors on JIRA
I removed a bunch who have been inactive for years a couple of months ago from hdfs. Having a limit forces us to remove stale entries, so it is not entirely bad. If the actual number of contributors reach the limit and the limit can't be changed easily, we might be able to create another jira group and give it a necessary permission. Kihwal On 5/13/14, 10:31 PM, "Suresh Srinivas" wrote: >Last time we cleaned up names of people who had not contributed in a long >time. That could be an option. > > >On Mon, May 12, 2014 at 12:03 PM, Karthik Kambatla >wrote: > >> Hi devs >> >> Looks like we ran over the max contributors allowed for a project, >>again. I >> don't remember what we did last time and can't find it in my email >>either. >> >> Can we bump up the number of contributors allowed? Otherwise, we might >>have >> to remove some of the currently inactive contributors from the list? >> >> Thanks >> Karthik >> > > > >-- >http://hortonworks.com/download/ > >-- >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: #Contributors on JIRA
Hey Pete, The "contributor list" we're referring to is just the collection of folks in JIRA that JIRAs can be assigned to. It doesn't impact anyone's ability to follow JIRAs, just have new JIRAs assigned to them. It also doesn't do anything to JIRAs that are already assigned. -- Aaron T. Myers Software Engineer, Cloudera On Thu, May 15, 2014 at 6:39 AM, Pete of Pete wrote: > On behalf of those of us who keep an eye on posts for commercial reasons > (but do not contribute) Is there the option of setting up a list that > accesses the dev comms, but doesn't impact the contributor list? > > P > > > On Wed, May 14, 2014 at 4:31 AM, Suresh Srinivas >wrote: > > > Last time we cleaned up names of people who had not contributed in a long > > time. That could be an option. > > > > > > On Mon, May 12, 2014 at 12:03 PM, Karthik Kambatla > >wrote: > > > > > Hi devs > > > > > > Looks like we ran over the max contributors allowed for a project, > > again. I > > > don't remember what we did last time and can't find it in my email > > either. > > > > > > Can we bump up the number of contributors allowed? Otherwise, we might > > have > > > to remove some of the currently inactive contributors from the list? > > > > > > Thanks > > > Karthik > > > > > > > > > > > -- > > http://hortonworks.com/download/ > > > > -- > > 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] [Reopened] (HADOOP-10474) Move o.a.h.record to hadoop-streaming
[ https://issues.apache.org/jira/browse/HADOOP-10474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Lowe reopened HADOOP-10474: - Reopening this as Hive is an important part of the Hadoop stack. Arguably we shouldn't remove something that hasn't been deprecated for at least one full major release. org.apache.hadoop.record.* wasn't deprecated in 1.x so it seems premature to remove it in 2.x, especially in a minor release of 2.x. Recommend we revert this, at least in branch-2. > Move o.a.h.record to hadoop-streaming > - > > Key: HADOOP-10474 > URL: https://issues.apache.org/jira/browse/HADOOP-10474 > Project: Hadoop Common > Issue Type: Improvement >Reporter: Haohui Mai >Assignee: Haohui Mai > Fix For: 2.5.0 > > Attachments: HADOOP-10474.000.patch, HADOOP-10474.001.patch, > HADOOP-10474.002.patch > > > The classes in o.a.h.record have been deprecated for more than a year and a > half. They should be removed. As the first step, the jira moves all these > classes into the hadoop-streaming project, which is the only user of these > classes. -- This message was sent by Atlassian JIRA (v6.2#6252)
Supported operating system versions
Hi all, I saw HDFS-6421 float by, which made me wonder what versions of Linux we support. The FAQ (http://wiki.apache.org/hadoop/FAQ) just says "Linux", but clearly we need a version cut off somewhere. I looked at a few vendor sites for the oldest supported RHEL version for their branch-2 based distros: Hortonworks: RHEL 5.7 Cloudera: RHEL 5.7 MapR: RHEL 6.1 Seems like Hortonworks and Cloudera would prefer if we standardized on ~RHEL 5.7+ for branch-2. Clearly there's Ubuntu, SLES, etc, but we need to start somewhere. Is this something we should agree on and then add to the wiki? A related page I found concerns Java versions ( http://wiki.apache.org/hadoop/HadoopJavaVersions), so we could add something similar. Thanks, Andrew p.s. Not saying we shouldn't fix HDFS-6421, this question about OS versions is obviously much broader than that one JIRA.
[jira] [Created] (HADOOP-10613) Potential Resource Leaks in FileSystem.CACHE
Nemon Lou created HADOOP-10613: -- Summary: Potential Resource Leaks in FileSystem.CACHE Key: HADOOP-10613 URL: https://issues.apache.org/jira/browse/HADOOP-10613 Project: Hadoop Common Issue Type: Bug Components: fs Affects Versions: 2.4.0 Reporter: Nemon Lou There is no size limit of the hashmap in FileSystem.CACHE, which can cause a potential memory leak. If every time i use a new UGI object to invoke FileSystem.get(conf) and never invoke FileSystem's close method,this issue will raise. If there is a size limit of the hashmap or changing fileSystem instances to soft reference,then user's code don't need to consider too much about the cache leak issues. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: #Contributors on JIRA
Cheers Aaron! All the best, ;-pete On 16 May 2014 19:47, "Aaron T. Myers" wrote: > Hey Pete, > > The "contributor list" we're referring to is just the collection of folks > in JIRA that JIRAs can be assigned to. It doesn't impact anyone's ability > to follow JIRAs, just have new JIRAs assigned to them. It also doesn't do > anything to JIRAs that are already assigned. > > -- > Aaron T. Myers > Software Engineer, Cloudera > > > On Thu, May 15, 2014 at 6:39 AM, Pete of Pete >wrote: > > > On behalf of those of us who keep an eye on posts for commercial reasons > > (but do not contribute) Is there the option of setting up a list that > > accesses the dev comms, but doesn't impact the contributor list? > > > > P > > > > > > On Wed, May 14, 2014 at 4:31 AM, Suresh Srinivas > >wrote: > > > > > Last time we cleaned up names of people who had not contributed in a > long > > > time. That could be an option. > > > > > > > > > On Mon, May 12, 2014 at 12:03 PM, Karthik Kambatla > > >wrote: > > > > > > > Hi devs > > > > > > > > Looks like we ran over the max contributors allowed for a project, > > > again. I > > > > don't remember what we did last time and can't find it in my email > > > either. > > > > > > > > Can we bump up the number of contributors allowed? Otherwise, we > might > > > have > > > > to remove some of the currently inactive contributors from the list? > > > > > > > > Thanks > > > > Karthik > > > > > > > > > > > > > > > > -- > > > http://hortonworks.com/download/ > > > > > > -- > > > 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: #Contributors on JIRA
You mean {common,mapreduce,yarn,hdfs}-{dev,commits,issues}@hadoop.apache.org
lists mentioned on https://hadoop.apache.org/mailing_lists.html ?
On Friday, May 16, 2014 4:44 PM, Pete of Pete wrote:
On behalf of those of us who keep an eye on posts for commercial reasons
(but do not contribute) Is there the option of setting up a list that
accesses the dev comms, but doesn't impact the contributor list?
P
On Wed, May 14, 2014 at 4:31 AM, Suresh Srinivas wrote:
> Last time we cleaned up names of people who had not contributed in a long
> time. That could be an option.
>
>
> On Mon, May 12, 2014 at 12:03 PM, Karthik Kambatla >wrote:
>
> > Hi devs
> >
> > Looks like we ran over the max contributors allowed for a project,
> again. I
> > don't remember what we did last time and can't find it in my email
> either.
> >
> > Can we bump up the number of contributors allowed? Otherwise, we might
> have
> > to remove some of the currently inactive contributors from the list?
> >
> > Thanks
> > Karthik
> >
>
>
>
> --
> http://hortonworks.com/download/
>
> --
> 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.
>
