Re: [DISCUSS] Move to gitbox
Hi ASF infrastructure team, Could you answer the following questions? * Is it an atomic move? Or will both repos live at the same time? * Do we need a stop-the-world period and messaging sent out? * When do the git-wip repos get deleted and/or stop getting updates? Regards, Akira 2018年12月14日(金) 1:26 Vinod Kumar Vavilapalli : > > We need to write up the stages of the process and put a concrete timeline > first. > > Is it an atomic move? Or will both repos live at the same time? Do we need a > stop-the-world period and messaging sent out? > > When do the git-wip repos get deleted and/or stop getting updates? > > Things I can think of that need tracking > - Wiki pages? > - Jenkins jobs > - Email notification setup for the commits? > - Policies - like no-mainline-branch-deletion support > > +Vinod > > > On Dec 13, 2018, at 7:57 AM, Elek, Marton wrote: > > > > > > > > On 12/12/18 12:27 PM, Akira Ajisaka wrote: > >> Thank you for your positive feedback! I'll file a jira to INFRA in this > >> weekend. > >> > >>> If I understood well the only bigger task here is to update all the > >>> jenkins jobs. (I am happy to help/contribute what I can do) > > > >> Thank you Elek for the information. Do you have the privilege to > >> update the Jenkins jobs? > >> > > I have, but I am more familiar with the Ozone jenkins jobs. I created a > > jira (HADOOP-16003) to discuss / record the changes / where it can be > > discussed or commented by anybody with more expertise. > > > > Marton > > > > - > > To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org > > For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org > > > - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Created] (HADOOP-16004) ABFS: Convert 404 error response in AbfsInputStream and AbfsOutPutStream to FileNotFoundException
Da Zhou created HADOOP-16004: Summary: ABFS: Convert 404 error response in AbfsInputStream and AbfsOutPutStream to FileNotFoundException Key: HADOOP-16004 URL: https://issues.apache.org/jira/browse/HADOOP-16004 Project: Hadoop Common Issue Type: Sub-task Components: fs/azure Affects Versions: 3.2.0 Reporter: Da Zhou Assignee: Da Zhou In AbfsInputStream and AbfsOutPutStream, client error response is used to create an IOException. We should convert 404 error response to FileNotFoundException -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
Re: [Result] [VOTE] Merge HDFS-12943 branch to trunk - Consistent Reads from Standby
Agree, it isn't productive this way. I can't seem to find it, but was there a DISCUSS thread for this branch-merge? I usually recommend addressing issues on a DISCUSS thread instead of fighting things over a VOTE. +Vinod > On Dec 13, 2018, at 10:09 AM, Konstantin Shvachko > wrote: > > This vote failed due to Daryn Sharp's veto. > The concern is being addressed by HDFS-13873. I will start a new vote once > this is committed. > > Note for Daryn. Your non-responsive handling of the veto makes a bad > precedence and is a bad example of communication on the lists from a > respected member of this community. Please check your availability for > followup discussions if you choose to get involved with important decisions. > > On Fri, Dec 7, 2018 at 4:10 PM Konstantin Shvachko > wrote: > >> Hi Daryn, >> >> Wanted to backup Chen's earlier response to your concerns about rotating >> calls in the call queue. >> Our design >> 1. targets directly the livelock problem by rejecting calls on the >> Observer that are not likely to be responded in timely matter: HDFS-13873. >> 2. The call queue rotation is only done on Observers, and never on the >> active NN, so it stays free of attacks like you suggest. >> >> If this is a satisfactory mitigation for the problem could you please >> reconsider your -1, so that people could continue voting on this thread. >> >> Thanks, >> --Konst >> >> On Thu, Dec 6, 2018 at 10:38 AM Daryn Sharp wrote: >> >>> -1 pending additional info. After a cursory scan, I have serious >>> concerns regarding the design. This seems like a feature that should have >>> been purely implemented in hdfs w/o touching the common IPC layer. >>> >>> The biggest issue in the alignment context. It's purpose appears to be >>> for allowing handlers to reinsert calls back into the call queue. That's >>> completely unacceptable. A buggy or malicious client can easily cause >>> livelock in the IPC layer with handlers only looping on calls that never >>> satisfy the condition. Why is this not implemented via RetriableExceptions? >>> >>> On Thu, Dec 6, 2018 at 1:24 AM Yongjun Zhang >>> wrote: >>> Great work guys. Wonder if we can elaborate what's impact of not having #2 fixed, and why #2 is not needed for the feature to complete? 2. Need to fix automatic failover with ZKFC. Currently it does not doesn't know about ObserverNodes trying to convert them to SBNs. Thanks. --Yongjun On Wed, Dec 5, 2018 at 5:27 PM Konstantin Shvachko wrote: > Hi Hadoop developers, > > I would like to propose to merge to trunk the feature branch HDFS-12943 for > Consistent Reads from Standby Node. The feature is intended to scale read > RPC workloads. On large clusters reads comprise 95% of all RPCs to the > NameNode. We should be able to accommodate higher overall RPC workloads (up > to 4x by some estimates) by adding multiple ObserverNodes. > > The main functionality has been implemented see sub-tasks of HDFS-12943. > We followed up with the test plan. Testing was done on two independent > clusters (see HDFS-14058 and HDFS-14059) with security enabled. > We ran standard HDFS commands, MR jobs, admin commands including manual > failover. > We know of one cluster running this feature in production. > > There are a few outstanding issues: > 1. Need to provide proper documentation - a user guide for the new feature > 2. Need to fix automatic failover with ZKFC. Currently it does not doesn't > know about ObserverNodes trying to convert them to SBNs. > 3. Scale testing and performance fine-tuning > 4. As testing progresses, we continue fixing non-critical bugs like > HDFS-14116. > > I attached a unified patch to the umbrella jira for the review and Jenkins > build. > Please vote on this thread. The vote will run for 7 days until Wed Dec 12. > > Thanks, > --Konstantin > >>> >>> >>> -- >>> >>> Daryn >>> >> - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
Re: [VOTE] Merge HDFS-12943 branch to trunk - Consistent Reads from Standby
Hi Yongjun, Good suggestion. This is essentially what HDFS-13873 is implementing to mitigate the concern. Thanks, --Konstantin On Wed, Dec 12, 2018 at 10:35 PM Yongjun Zhang wrote: > Hi Konstantin, > > Thanks for addressing my other question about failover. > > Some thought to share about the suggestion Daryn made. Seems we could try > this: let ObserverNode throws an RetriableException back to client saying > it has not reached the transaction ID to serve the client yet, maybe even > include the transaction ID gap information in the exception, then when the > client received the RetriableException, it can decide whether the continue > to send the request to the observer node again, or to the active NN when > the gap is too big. > > Though saving another RPC would help the performance with the current > implementation, I expect the above mentioned exception only happens > infrequently, so the performance won't be too bad, plus the client has a > chance to try ANN when knowing that the observer is too behind at extreme > case. > > I wonder how different the performance is between these two approaches in > cluster with real workload. > > Comments? > > --Yongjun > > On Fri, Dec 7, 2018 at 4:10 PM Konstantin Shvachko > wrote: > >> Hi Daryn, >> >> Wanted to backup Chen's earlier response to your concerns about rotating >> calls in the call queue. >> Our design >> 1. targets directly the livelock problem by rejecting calls on the >> Observer >> that are not likely to be responded in timely matter: HDFS-13873. >> 2. The call queue rotation is only done on Observers, and never on the >> active NN, so it stays free of attacks like you suggest. >> >> If this is a satisfactory mitigation for the problem could you please >> reconsider your -1, so that people could continue voting on this thread. >> >> Thanks, >> --Konst >> >> On Thu, Dec 6, 2018 at 10:38 AM Daryn Sharp wrote: >> >> > -1 pending additional info. After a cursory scan, I have serious >> concerns >> > regarding the design. This seems like a feature that should have been >> > purely implemented in hdfs w/o touching the common IPC layer. >> > >> > The biggest issue in the alignment context. It's purpose appears to be >> > for allowing handlers to reinsert calls back into the call queue. >> That's >> > completely unacceptable. A buggy or malicious client can easily cause >> > livelock in the IPC layer with handlers only looping on calls that never >> > satisfy the condition. Why is this not implemented via >> RetriableExceptions? >> > >> > On Thu, Dec 6, 2018 at 1:24 AM Yongjun Zhang >> >> > wrote: >> > >> >> Great work guys. >> >> >> >> Wonder if we can elaborate what's impact of not having #2 fixed, and >> why >> >> #2 >> >> is not needed for the feature to complete? >> >> 2. Need to fix automatic failover with ZKFC. Currently it does not >> doesn't >> >> know about ObserverNodes trying to convert them to SBNs. >> >> >> >> Thanks. >> >> --Yongjun >> >> >> >> >> >> On Wed, Dec 5, 2018 at 5:27 PM Konstantin Shvachko < >> shv.had...@gmail.com> >> >> wrote: >> >> >> >> > Hi Hadoop developers, >> >> > >> >> > I would like to propose to merge to trunk the feature branch >> HDFS-12943 >> >> for >> >> > Consistent Reads from Standby Node. The feature is intended to scale >> >> read >> >> > RPC workloads. On large clusters reads comprise 95% of all RPCs to >> the >> >> > NameNode. We should be able to accommodate higher overall RPC >> workloads >> >> (up >> >> > to 4x by some estimates) by adding multiple ObserverNodes. >> >> > >> >> > The main functionality has been implemented see sub-tasks of >> HDFS-12943. >> >> > We followed up with the test plan. Testing was done on two >> independent >> >> > clusters (see HDFS-14058 and HDFS-14059) with security enabled. >> >> > We ran standard HDFS commands, MR jobs, admin commands including >> manual >> >> > failover. >> >> > We know of one cluster running this feature in production. >> >> > >> >> > There are a few outstanding issues: >> >> > 1. Need to provide proper documentation - a user guide for the new >> >> feature >> >> > 2. Need to fix automatic failover with ZKFC. Currently it does not >> >> doesn't >> >> > know about ObserverNodes trying to convert them to SBNs. >> >> > 3. Scale testing and performance fine-tuning >> >> > 4. As testing progresses, we continue fixing non-critical bugs like >> >> > HDFS-14116. >> >> > >> >> > I attached a unified patch to the umbrella jira for the review and >> >> Jenkins >> >> > build. >> >> > Please vote on this thread. The vote will run for 7 days until Wed >> Dec >> >> 12. >> >> > >> >> > Thanks, >> >> > --Konstantin >> >> > >> >> >> > >> > >> > -- >> > >> > Daryn >> > >> >
[Result] [VOTE] Merge HDFS-12943 branch to trunk - Consistent Reads from Standby
This vote failed due to Daryn Sharp's veto. The concern is being addressed by HDFS-13873. I will start a new vote once this is committed. Note for Daryn. Your non-responsive handling of the veto makes a bad precedence and is a bad example of communication on the lists from a respected member of this community. Please check your availability for followup discussions if you choose to get involved with important decisions. On Fri, Dec 7, 2018 at 4:10 PM Konstantin Shvachko wrote: > Hi Daryn, > > Wanted to backup Chen's earlier response to your concerns about rotating > calls in the call queue. > Our design > 1. targets directly the livelock problem by rejecting calls on the > Observer that are not likely to be responded in timely matter: HDFS-13873. > 2. The call queue rotation is only done on Observers, and never on the > active NN, so it stays free of attacks like you suggest. > > If this is a satisfactory mitigation for the problem could you please > reconsider your -1, so that people could continue voting on this thread. > > Thanks, > --Konst > > On Thu, Dec 6, 2018 at 10:38 AM Daryn Sharp wrote: > >> -1 pending additional info. After a cursory scan, I have serious >> concerns regarding the design. This seems like a feature that should have >> been purely implemented in hdfs w/o touching the common IPC layer. >> >> The biggest issue in the alignment context. It's purpose appears to be >> for allowing handlers to reinsert calls back into the call queue. That's >> completely unacceptable. A buggy or malicious client can easily cause >> livelock in the IPC layer with handlers only looping on calls that never >> satisfy the condition. Why is this not implemented via RetriableExceptions? >> >> On Thu, Dec 6, 2018 at 1:24 AM Yongjun Zhang >> wrote: >> >>> Great work guys. >>> >>> Wonder if we can elaborate what's impact of not having #2 fixed, and why >>> #2 >>> is not needed for the feature to complete? >>> 2. Need to fix automatic failover with ZKFC. Currently it does not >>> doesn't >>> know about ObserverNodes trying to convert them to SBNs. >>> >>> Thanks. >>> --Yongjun >>> >>> >>> On Wed, Dec 5, 2018 at 5:27 PM Konstantin Shvachko >> > >>> wrote: >>> >>> > Hi Hadoop developers, >>> > >>> > I would like to propose to merge to trunk the feature branch >>> HDFS-12943 for >>> > Consistent Reads from Standby Node. The feature is intended to scale >>> read >>> > RPC workloads. On large clusters reads comprise 95% of all RPCs to the >>> > NameNode. We should be able to accommodate higher overall RPC >>> workloads (up >>> > to 4x by some estimates) by adding multiple ObserverNodes. >>> > >>> > The main functionality has been implemented see sub-tasks of >>> HDFS-12943. >>> > We followed up with the test plan. Testing was done on two independent >>> > clusters (see HDFS-14058 and HDFS-14059) with security enabled. >>> > We ran standard HDFS commands, MR jobs, admin commands including manual >>> > failover. >>> > We know of one cluster running this feature in production. >>> > >>> > There are a few outstanding issues: >>> > 1. Need to provide proper documentation - a user guide for the new >>> feature >>> > 2. Need to fix automatic failover with ZKFC. Currently it does not >>> doesn't >>> > know about ObserverNodes trying to convert them to SBNs. >>> > 3. Scale testing and performance fine-tuning >>> > 4. As testing progresses, we continue fixing non-critical bugs like >>> > HDFS-14116. >>> > >>> > I attached a unified patch to the umbrella jira for the review and >>> Jenkins >>> > build. >>> > Please vote on this thread. The vote will run for 7 days until Wed Dec >>> 12. >>> > >>> > Thanks, >>> > --Konstantin >>> > >>> >> >> >> -- >> >> Daryn >> >
Re: [DISCUSS] Move to gitbox
We need to write up the stages of the process and put a concrete timeline first. Is it an atomic move? Or will both repos live at the same time? Do we need a stop-the-world period and messaging sent out? When do the git-wip repos get deleted and/or stop getting updates? Things I can think of that need tracking - Wiki pages? - Jenkins jobs - Email notification setup for the commits? - Policies - like no-mainline-branch-deletion support +Vinod > On Dec 13, 2018, at 7:57 AM, Elek, Marton wrote: > > > > On 12/12/18 12:27 PM, Akira Ajisaka wrote: >> Thank you for your positive feedback! I'll file a jira to INFRA in this >> weekend. >> >>> If I understood well the only bigger task here is to update all the jenkins >>> jobs. (I am happy to help/contribute what I can do) > >> Thank you Elek for the information. Do you have the privilege to >> update the Jenkins jobs? >> > I have, but I am more familiar with the Ozone jenkins jobs. I created a > jira (HADOOP-16003) to discuss / record the changes / where it can be > discussed or commented by anybody with more expertise. > > Marton > > - > To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org > - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
Re: Can someone add me to the JIRA admin list
Well said. Thanks, Sean! On Thu, Dec 13, 2018 at 8:00 AM Sean Busbey wrote: > AFAIK we don't have like a policy or something. If folks want to help > on one of the JIRA instances I say give them the access. I don't just > mean that for committers, but especially for committers if we can't > trust someone to not try to mess things up in one of the trackers we > have bigger problems. > On Thu, Dec 13, 2018 at 9:49 AM Wei-Chiu Chuang > wrote: > > > > Quick questions here, > > Do committers get added to admin role on all Hadoop projects (i.e. > HADOOP, HDFS, YARN, MAPREDUCE and HDDS) or just a subset of them? > > I am admin on HADOOP/HDFS and for the most part that works fine for me, > because I primarily only work on HDFS and Hadoop Common space. > > And that's probably a good idea to respect my peer YARN/MAPREDUCE/HDDS > committers, but I am just curious. > > > > On Thu, Dec 13, 2018 at 5:37 AM Sean Busbey wrote: > >> > >> It looks like I'm only listed as a JIRA admin on the YARN tracker. > Could someone add me on the rest of the project trackers? I'm trying to get > a new contributor on-boarded so I can assign them an issue they're working. > >> > >> - > >> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > >> For additional commands, e-mail: common-dev-h...@hadoop.apache.org > >> >
Re: Can someone add me to the JIRA admin list
That's right, there's no policy. It's done on an adhoc/need basis. There is no automated way to put all committers in that ACL. +Vinod > On Dec 13, 2018, at 7:59 AM, Sean Busbey wrote: > > AFAIK we don't have like a policy or something. If folks want to help > on one of the JIRA instances I say give them the access. I don't just > mean that for committers, but especially for committers if we can't > trust someone to not try to mess things up in one of the trackers we > have bigger problems. > On Thu, Dec 13, 2018 at 9:49 AM Wei-Chiu Chuang wrote: >> >> Quick questions here, >> Do committers get added to admin role on all Hadoop projects (i.e. HADOOP, >> HDFS, YARN, MAPREDUCE and HDDS) or just a subset of them? >> I am admin on HADOOP/HDFS and for the most part that works fine for me, >> because I primarily only work on HDFS and Hadoop Common space. >> And that's probably a good idea to respect my peer YARN/MAPREDUCE/HDDS >> committers, but I am just curious. >> >> On Thu, Dec 13, 2018 at 5:37 AM Sean Busbey wrote: >>> >>> It looks like I'm only listed as a JIRA admin on the YARN tracker. Could >>> someone add me on the rest of the project trackers? I'm trying to get a new >>> contributor on-boarded so I can assign them an issue they're working. >>> >>> - >>> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org >>> For additional commands, e-mail: common-dev-h...@hadoop.apache.org >>> > > - > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
Re: Can someone add me to the JIRA admin list
AFAIK we don't have like a policy or something. If folks want to help on one of the JIRA instances I say give them the access. I don't just mean that for committers, but especially for committers if we can't trust someone to not try to mess things up in one of the trackers we have bigger problems. On Thu, Dec 13, 2018 at 9:49 AM Wei-Chiu Chuang wrote: > > Quick questions here, > Do committers get added to admin role on all Hadoop projects (i.e. HADOOP, > HDFS, YARN, MAPREDUCE and HDDS) or just a subset of them? > I am admin on HADOOP/HDFS and for the most part that works fine for me, > because I primarily only work on HDFS and Hadoop Common space. > And that's probably a good idea to respect my peer YARN/MAPREDUCE/HDDS > committers, but I am just curious. > > On Thu, Dec 13, 2018 at 5:37 AM Sean Busbey wrote: >> >> It looks like I'm only listed as a JIRA admin on the YARN tracker. Could >> someone add me on the rest of the project trackers? I'm trying to get a new >> contributor on-boarded so I can assign them an issue they're working. >> >> - >> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org >> For additional commands, e-mail: common-dev-h...@hadoop.apache.org >> - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
Re: Can someone add me to the JIRA admin list
Quick questions here, Do committers get added to admin role on all Hadoop projects (i.e. HADOOP, HDFS, YARN, MAPREDUCE and HDDS) or just a subset of them? I am admin on HADOOP/HDFS and for the most part that works fine for me, because I primarily only work on HDFS and Hadoop Common space. And that's probably a good idea to respect my peer YARN/MAPREDUCE/HDDS committers, but I am just curious. On Thu, Dec 13, 2018 at 5:37 AM Sean Busbey wrote: > It looks like I'm only listed as a JIRA admin on the YARN tracker. Could > someone add me on the rest of the project trackers? I'm trying to get a new > contributor on-boarded so I can assign them an issue they're working. > > - > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > >
Re: [DISCUSS] Move to gitbox
On 12/12/18 12:27 PM, Akira Ajisaka wrote: > Thank you for your positive feedback! I'll file a jira to INFRA in this > weekend. > >> If I understood well the only bigger task here is to update all the jenkins >> jobs. (I am happy to help/contribute what I can do) > Thank you Elek for the information. Do you have the privilege to > update the Jenkins jobs? > I have, but I am more familiar with the Ozone jenkins jobs. I created a jira (HADOOP-16003) to discuss / record the changes / where it can be discussed or commented by anybody with more expertise. Marton - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
[jira] [Created] (HADOOP-16003) Migrate the Hadoop jenkins jobs to use new gitbox urls
Elek, Marton created HADOOP-16003: - Summary: Migrate the Hadoop jenkins jobs to use new gitbox urls Key: HADOOP-16003 URL: https://issues.apache.org/jira/browse/HADOOP-16003 Project: Hadoop Common Issue Type: Task Reporter: Elek, Marton As it's announced the INFRA team all the apache git repositories will be migrated to use gitbox. I created this jira to sync on the required steps to update the jenkins job, and record the changes. By default it could be as simple as changing the git url for all the jenkins jobs under the Hadoop view: https://builds.apache.org/view/H-L/view/Hadoop/ -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
Re: Can someone add me to the JIRA admin list
Done. -Akira 2018年12月13日(木) 22:37 Sean Busbey : > > It looks like I'm only listed as a JIRA admin on the YARN tracker. Could > someone add me on the rest of the project trackers? I'm trying to get a new > contributor on-boarded so I can assign them an issue they're working. > > - > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86
For more details, see https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/ [Dec 12, 2018 8:49:49 AM] (sunilg) YARN-9114. [UI2] log service redirect url need to support user name. [Dec 12, 2018 1:16:21 PM] (elek) HDDS-889. MultipartUpload: Support uploading a part file in ozone. [Dec 12, 2018 4:30:13 PM] (mackrorysd) HADOOP-15988. DynamoDBMetadataStore#innerGet should support empty [Dec 12, 2018 7:10:24 PM] (gifuma) HADOOP-15995. Add ldap.bind.password.alias in LdapGroupsMapping to [Dec 12, 2018 7:16:16 PM] (gifuma) HDFS-14144. TestPred fails in Trunk. Contributed by Ayush Saxena. [Dec 12, 2018 7:42:44 PM] (wangda) YARN-9078. [Submarine] Clean up the code of [Dec 12, 2018 7:43:23 PM] (wangda) YARN-8714. [Submarine] Support files/tarballs to be localized for a [Dec 12, 2018 7:44:22 PM] (wangda) YARN-9015. [DevicePlugin] Add an interface for device plugin to provide [Dec 12, 2018 7:44:58 PM] (wangda) YARN-9112. [Submarine] Support polling applicationId when it's not ready [Dec 12, 2018 7:45:47 PM] (wangda) YARN-8885. [DevicePlugin] Support NM APIs to query device resource -1 overall The following subsystems voted -1: asflicense findbugs hadolint pathlen unit The following subsystems voted -1 but were configured to be filtered/ignored: cc checkstyle javac javadoc pylint shellcheck shelldocs whitespace The following subsystems are considered long running: (runtime bigger than 1h 0m 0s) unit Specific tests: Failed junit tests : hadoop.security.ssl.TestSSLFactory hadoop.util.TestReadWriteDiskValidator hadoop.util.TestBasicDiskValidator hadoop.util.TestDiskCheckerWithDiskIo hadoop.registry.secure.TestSecureLogins hadoop.yarn.server.nodemanager.amrmproxy.TestFederationInterceptor hadoop.yarn.server.resourcemanager.rmapp.TestRMAppTransitions cc: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/diff-compile-cc-root.txt [4.0K] javac: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/diff-compile-javac-root.txt [336K] checkstyle: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/diff-checkstyle-root.txt [17M] hadolint: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/diff-patch-hadolint.txt [4.0K] pathlen: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/pathlen.txt [12K] pylint: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/diff-patch-pylint.txt [40K] shellcheck: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/diff-patch-shellcheck.txt [20K] shelldocs: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/diff-patch-shelldocs.txt [12K] whitespace: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/whitespace-eol.txt [9.3M] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/whitespace-tabs.txt [1.1M] findbugs: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-hdds_client.txt [8.0K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-hdds_container-service.txt [4.0K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-hdds_framework.txt [4.0K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-hdds_server-scm.txt [8.0K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-hdds_tools.txt [4.0K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-ozone_client.txt [8.0K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-ozone_common.txt [4.0K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-ozone_objectstore-service.txt [8.0K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-ozone_ozone-manager.txt [4.0K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-ozone_ozonefs.txt [12K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-ozone_s3gateway.txt [4.0K] https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/branch-findbugs-hadoop-ozone_tools.txt [8.0K] javadoc: https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/986/artifact/out/
Can someone add me to the JIRA admin list
It looks like I'm only listed as a JIRA admin on the YARN tracker. Could someone add me on the rest of the project trackers? I'm trying to get a new contributor on-boarded so I can assign them an issue they're working. - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
