YARN-11382 ClientRMService forget to record some audit logs after accessCheck

YARN-11382 ClientRMService forget to record some audit logs after accessCheck and just throw an YarnException("User does not have privilege to do something……").
Here is an example in method "getContainers":
@Override public GetContainersResponse getContainers(GetContainersRequest request)
    throws YarnException, IOException {
    ......
    boolean allowAccess = checkAccess(callerUGI, application.getUser(),  ApplicationAccessType.VIEW_APP, application);
    GetContainersResponse response = null;
    if (allowAccess) {
        ......
        // a logSuccess should be called here.
    } else {
        // a logFailure should be called here.
        throw new YarnException("User " + callerUGI.getShortUserName() + " does not have privilege to see this application " + appId);
    }
    return response;
}

And other methods(e.g. signalToContainer) in this class logSuccess or logFailure after accessCheck.
I think the requests from users are very critical for auditing and audit logs should  be recorded here.
Also, I found some AuditConstants in RMAuditLogger for these request (except getApplicationReport), so I guess write audit log for them is in the developer's planning but maybe forgotten.
public class RMAuditLogger {
  ......
    public static class AuditConstants {
    ......
    public static final String GET_APP_ATTEMPTS = "Get Application Attempts";
    public static final String GET_APP_ATTEMPT_REPORT
        = "Get Application Attempt Report";
    public static final String GET_CONTAINERS = "Get Containers";
    public static final String GET_CONTAINER_REPORT = "Get Container Report";
    ......

Description of PR
How was this patch tested?
For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

@curie71 Thanks for your contribution, LGTM.
Can you help to check again whether there is still auditlog missing in the method of ClientRMService?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 51s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 31s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
28m 58s

trunk passed

+1 :green_heart:
compile
10m 49s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
9m 14s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
2m  3s

trunk passed

+1 :green_heart:
mvnsite
2m 31s

trunk passed

+1 :green_heart:
javadoc
1m 59s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m 49s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
3m 50s

trunk passed

+1 :green_heart:
shadedclient
24m 34s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 25s

Maven dependency ordering for patch

-1 :x:
mvninstall
0m 33s
/patch-mvninstall-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt
hadoop-yarn-server-resourcemanager in the patch failed.

-1 :x:
compile
3m 40s
/patch-compile-hadoop-yarn-project_hadoop-yarn-jdkUbuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04.txt
hadoop-yarn in the patch failed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04.

-1 :x:
javac
3m 40s
/patch-compile-hadoop-yarn-project_hadoop-yarn-jdkUbuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04.txt
hadoop-yarn in the patch failed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04.

-1 :x:
compile
3m  3s
/patch-compile-hadoop-yarn-project_hadoop-yarn-jdkPrivateBuild-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07.txt
hadoop-yarn in the patch failed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07.

-1 :x:
javac
3m  3s
/patch-compile-hadoop-yarn-project_hadoop-yarn-jdkPrivateBuild-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07.txt
hadoop-yarn in the patch failed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07.

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 11 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

-0 :warning:
checkstyle
1m 36s
/results-checkstyle-hadoop-yarn-project_hadoop-yarn.txt
hadoop-yarn-project/hadoop-yarn: The patch generated 1 new + 28 unchanged - 0 fixed = 29 total (was 28)

-1 :x:
mvnsite
0m 39s
/patch-mvnsite-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt
hadoop-yarn-server-resourcemanager in the patch failed.

+1 :green_heart:
javadoc
1m  7s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
1m  4s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

-1 :x:
spotbugs
0m 37s
/patch-spotbugs-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt
hadoop-yarn-server-resourcemanager in the patch failed.

-1 :x:
shadedclient
9m 26s

patch has errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 39s
/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt
hadoop-yarn-server-resourcemanager in the patch failed.

+1 :green_heart:
unit
1m  3s

hadoop-yarn-applications-catalog-webapp in the patch passed.

-1 :x:
asflicense
0m 39s
/results-asflicense.txt
The patch generated 1 ASF License warnings.

131m 18s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5158

Optional Tests
dupname asflicense codespell detsecrets compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle

uname
Linux ddf9b9cc53a3 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / a9f24d2db634f8fdfbbf86a40668cc1f9929aadc

Default Java
Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/2/testReport/

Max. process+thread count
588 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-catalog/hadoop-yarn-applications-catalog-webapp U: hadoop-yarn-project/hadoop-yarn

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 55s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
jsonlint
0m  0s

jsonlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 26s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
29m 30s

trunk passed

+1 :green_heart:
compile
26m 20s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
23m  1s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
4m 26s

trunk passed

+1 :green_heart:
mvnsite
20m 31s

trunk passed

+1 :green_heart:
javadoc
8m 33s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
7m 33s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

-1 :x:
spotbugs
36m  8s
/branch-spotbugs-root-warnings.html
root in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
59m 21s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 24s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
26m 37s

the patch passed

+1 :green_heart:
compile
25m 13s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
25m 13s

the patch passed

+1 :green_heart:
compile
22m 20s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
22m 20s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 11 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

-0 :warning:
checkstyle
4m 18s
/results-checkstyle-root.txt
root: The patch generated 1 new + 28 unchanged - 0 fixed = 29 total (was 28)

+1 :green_heart:
mvnsite
20m  7s

the patch passed

+1 :green_heart:
javadoc
8m 34s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
7m 43s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
44m 43s

the patch passed

+1 :green_heart:
shadedclient
65m  3s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
1096m 28s
/patch-unit-root.txt
root in the patch passed.

-1 :x:
asflicense
2m  0s
/results-asflicense.txt
The patch generated 2 ASF License warnings.

1487m  4s

Reason
Tests

Failed junit tests
hadoop.mapreduce.v2.hs.webapp.TestHsWebServices

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesTasks

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesAttempts

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesLogs

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesJobs

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesJobsQuery

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesJobConf

hadoop.mapreduce.v2.app.webapp.TestAMWebServicesJobs

hadoop.mapreduce.v2.app.webapp.TestAMWebServicesJobConf

hadoop.mapreduce.v2.app.webapp.TestAMWebServicesAttempts

hadoop.mapreduce.v2.app.webapp.TestAMWebServices

hadoop.mapreduce.v2.app.TestRuntimeEstimators

hadoop.mapreduce.v2.app.webapp.TestAMWebServicesTasks

hadoop.yarn.server.resourcemanager.reservation.TestCapacityOverTimePolicy

hadoop.hdfs.TestLeaseRecovery2

hadoop.hdfs.TestLeaseRecovery

hadoop.hdfs.server.balancer.TestBalancerService

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5158

Optional Tests
dupname asflicense codespell detsecrets compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle jsonlint

uname
Linux 66275f8a42f4 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk /<PHONE_NUMBER>7ec5f848b85810af0516086dec6988

Default Java
Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/3/testReport/

Max. process+thread count
2563 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-catalog/hadoop-yarn-applications-catalog-webapp . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

Thanks for your reply, I found some other auditlog missing problems in the method of ClientRMService, you can view it through YARN-11392 .

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  2s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
jsonlint
0m  0s

jsonlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
14m 41s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
28m 57s

trunk passed

+1 :green_heart:
compile
25m  1s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
compile
21m 50s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
checkstyle
3m 58s

trunk passed

+1 :green_heart:
mvnsite
20m  0s

trunk passed

-1 :x:
javadoc
1m 21s
/branch-javadoc-root-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
root in trunk failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
7m 23s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

-1 :x:
spotbugs
35m 46s
/branch-spotbugs-root-warnings.html
root in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
57m 51s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 22s

Maven dependency ordering for patch

-1 :x:
mvninstall
0m 30s
/patch-mvninstall-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt
hadoop-yarn-server-resourcemanager in the patch failed.

-1 :x:
mvninstall
7m  5s
/patch-mvninstall-root.txt
root in the patch failed.

-1 :x:
compile
10m 21s
/patch-compile-root-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
root in the patch failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

-1 :x:
javac
10m 21s
/patch-compile-root-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
root in the patch failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

-1 :x:
compile
9m 17s
/patch-compile-root-jdkPrivateBuild-1.8.0_352-8u352-ga-1~20.04-b08.txt
root in the patch failed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08.

-1 :x:
javac
9m 18s
/patch-compile-root-jdkPrivateBuild-1.8.0_352-8u352-ga-1~20.04-b08.txt
root in the patch failed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08.

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 12 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

-0 :warning:
checkstyle
3m 41s
/results-checkstyle-root.txt
root: The patch generated 1 new + 28 unchanged - 0 fixed = 29 total (was 28)

-1 :x:
mvnsite
3m 24s
/patch-mvnsite-root.txt
root in the patch failed.

-1 :x:
javadoc
1m  5s
/patch-javadoc-root-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
root in the patch failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
7m 16s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

-1 :x:
spotbugs
0m 32s
/patch-spotbugs-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager.txt
hadoop-yarn-server-resourcemanager in the patch failed.

-1 :x:
spotbugs
15m 11s
/patch-spotbugs-root.txt
root in the patch failed.

-1 :x:
shadedclient
8m 55s

patch has errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
570m 18s
/patch-unit-root.txt
root in the patch failed.

-1 :x:
asflicense
1m 21s
/results-asflicense.txt
The patch generated 2 ASF License warnings.

829m 16s

Reason
Tests

Failed junit tests
hadoop.hdfs.TestLeaseRecovery2

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5158

Optional Tests
dupname asflicense codespell detsecrets compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle jsonlint

uname
Linux 04ecd34e4450 4.15.0-200-generic #211-Ubuntu SMP Thu Nov 24 18:16:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 1876c6ca0e32952a3dfd15017297d809487afe04

Default Java
Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/4/testReport/

Max. process+thread count
1992 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-catalog/hadoop-yarn-applications-catalog-webapp . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/4/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 49s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m 33s

trunk passed

+1 :green_heart:
compile
1m 11s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
compile
0m 57s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
checkstyle
0m 53s

trunk passed

+1 :green_heart:
mvnsite
1m 10s

trunk passed

-1 :x:
javadoc
0m 54s
/branch-javadoc-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
hadoop-yarn-server-resourcemanager in trunk failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
0m 44s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
2m 10s

trunk passed

+1 :green_heart:
shadedclient
22m 18s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
22m 37s

Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 52s

the patch passed

+1 :green_heart:
compile
0m 59s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javac
0m 59s

the patch passed

+1 :green_heart:
compile
0m 49s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
javac
0m 49s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 2 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
checkstyle
0m 38s

the patch passed

+1 :green_heart:
mvnsite
0m 53s

the patch passed

-1 :x:
javadoc
0m 38s
/patch-javadoc-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
hadoop-yarn-server-resourcemanager in the patch failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
0m 40s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
1m 58s

the patch passed

+1 :green_heart:
shadedclient
22m  3s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
98m 51s

hadoop-yarn-server-resourcemanager in the patch passed.

+1 :green_heart:
asflicense
0m 37s

The patch does not generate ASF License warnings.

199m 11s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5158

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 20d169d8543d 4.15.0-200-generic #211-Ubuntu SMP Thu Nov 24 18:16:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / e6a3b12ef1f52c338b82760dea82669595b614ff

Default Java
Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/6/testReport/

Max. process+thread count
956 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/6/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 47s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m 50s

trunk passed

+1 :green_heart:
compile
1m  6s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
compile
0m 57s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
checkstyle
0m 58s

trunk passed

+1 :green_heart:
mvnsite
0m 57s

trunk passed

-1 :x:
javadoc
1m 15s
/branch-javadoc-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
hadoop-yarn-server-resourcemanager in trunk failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
0m 48s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
2m 11s

trunk passed

+1 :green_heart:
shadedclient
22m 38s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
22m 57s

Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 55s

the patch passed

+1 :green_heart:
compile
1m  0s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javac
1m  0s

the patch passed

+1 :green_heart:
compile
0m 52s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
javac
0m 52s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 2 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
checkstyle
0m 40s

the patch passed

+1 :green_heart:
mvnsite
0m 56s

the patch passed

-1 :x:
javadoc
0m 41s
/patch-javadoc-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-resourcemanager-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
hadoop-yarn-server-resourcemanager in the patch failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
0m 39s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
2m  4s

the patch passed

+1 :green_heart:
shadedclient
22m 39s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
98m 31s

hadoop-yarn-server-resourcemanager in the patch passed.

+1 :green_heart:
asflicense
0m 38s

The patch does not generate ASF License warnings.

200m 25s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5158

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux c4a658bdbf69 4.15.0-200-generic #211-Ubuntu SMP Thu Nov 24 18:16:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / e6a3b12ef1f52c338b82760dea82669595b614ff

Default Java
Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/7/testReport/

Max. process+thread count
964 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/7/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 58s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
jsonlint
0m  1s

jsonlint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+0 :ok:
mvndep
15m 49s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
27m 34s

trunk passed

+1 :green_heart:
compile
25m  8s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
compile
20m 32s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
checkstyle
3m 48s

trunk passed

+1 :green_heart:
mvnsite
19m  3s

trunk passed

-1 :x:
javadoc
1m 22s
/branch-javadoc-root-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
root in trunk failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
7m 26s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

-1 :x:
spotbugs
34m 28s
/branch-spotbugs-root-warnings.html
root in trunk has 1 extant spotbugs warnings.

+1 :green_heart:
shadedclient
53m 45s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 30s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
23m 17s

the patch passed

+1 :green_heart:
compile
22m 33s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javac
22m 33s

the patch passed

+1 :green_heart:
compile
20m 27s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
javac
20m 27s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 11 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

+1 :green_heart:
checkstyle
3m 40s

the patch passed

+1 :green_heart:
mvnsite
18m 36s

the patch passed

-1 :x:
javadoc
1m 13s
/patch-javadoc-root-jdkUbuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.txt
root in the patch failed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04.

+1 :green_heart:
javadoc
7m 19s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
36m 32s

the patch passed

+1 :green_heart:
shadedclient
52m 41s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
834m 31s
/patch-unit-root.txt
root in the patch passed.

-1 :x:
asflicense
1m 31s
/results-asflicense.txt
The patch generated 2 ASF License warnings.

1173m 16s

Reason
Tests

Failed junit tests
hadoop.hdfs.TestLeaseRecovery2

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesJobConf

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesTasks

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesJobs

hadoop.mapreduce.v2.hs.webapp.TestHsWebServices

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesAttempts

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesLogs

hadoop.mapreduce.v2.hs.webapp.TestHsWebServicesJobsQuery

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5158

Optional Tests
dupname asflicense codespell detsecrets compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle jsonlint

uname
Linux d2b1d2a6c92b 4.15.0-200-generic #211-Ubuntu SMP Thu Nov 24 18:16:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / c5eebdae9e96d968cab8dd74155b969e780ebae1

Default Java
Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/5/testReport/

Max. process+thread count
3732 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-catalog/hadoop-yarn-applications-catalog-webapp . U: .

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5158/5/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


[LD-1967]: Update tasks/search with correct HTTP method and per_page

[x] This pull request is submitted to the master branch.
[ ] If it makes frontend changes, this pull request has been tested in the latest version of Firefox, Chrome, IE, and Safari.
[x] If it is an API related fix, the shell and python code have been tested

@echocli Good point about the method. The endpoint supports both GET and POST. But we always use POST in the docs. I guess because the JSON body looks cleaner and easier to modify than query params.


pathlib module not found

Hy there,
Everything seems working but the python script faills loading pathlib module.
I did install this module sudo pip3 install pathlib
Requirement already satisfied: pathlib in /usr/local/lib/python3.5/dist-packages
I can load it manualy from a ipython3 or python3 command line.
So my question is, what python environment is automaticaly used ?
Regards,
Florent

ok. so i made it working replacing "python" with "python3" in spawning function in both run.js and train.js
my bad :p


Update locations.txt

My mom's side of the family is from St. John's, Newfoundland, so I added it to the list.

Very interesting

kinda trash


Add JReleaser Pipeline

We should add a JReleaser pipeline to publish this artifact to Maven Central

I added the necessary secrets to this repository.


Any plan for maven artifact distribution ?

This would be really useful - do you have any plans to distribute to Maven central any time soon?

Hey there, could one of you contact me on<EMAIL_ADDRESS>please?

Have any plans to distribute to Maven central or another maven repo?

If anyone has the time and also experience of Maven to help us with this, it would be hugely appreciated :-)

Actually, implementing #3 would make it easier, thebintray plugin could then be used to publish the JAR on JCenter
It would simplify dependency management too, no need to copy a bunch of JARs and no need to maintain the README for instance (that is outdated since SLF4J is needed as well).
I'll be happy to help but it would be better to publish it under your name (Mangopay) on Bintray

That would be great @youribonnaffe, thank you. Using Gradle to build the SDK wouldn't of course present any breaking changes would it?
As for submission, I'm happy to take care of this - it would indeed be best as you say.

Hi,
I am not sure if it is useful for you but we are using this pom.xml to deploy in our local maven repository.
https://gist.github.com/ArnaudT/9b03f72e8929894fecce16f88bad6be1
and the command:
mvn deploy:deploy-file -DpomFile=pom.xml -Dfile=mangopay2-java-sdk-1.0.7.jar -DrepositoryId=depop.s3.releases -Durl=s3://depop-maven-repository/releases
cheers.

Hey @ArnaudT, that's really useful, thank you - the missing POM file is exactly what's currently blocking us being able to add this to jCenter etc. Do you think you could do a PR with it please?

Since the maven plugin is used, you can also
run generatePomFileForMavenPublication or install to generate a pom.xml
file (gradle install, then in build/poms/pom-default.xml).
On 20 May 2016 at 10:18, Hugo Bailey<EMAIL_ADDRESS>wrote:

Hey @ArnaudT https://github.com/ArnaudT, that's really useful, thank
you - the missing POM file is exactly what's currently blocking us being
able to add this to jCenter etc. Do you think you could do a PR with it
please?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/Mangopay/mangopay2-java-sdk/issues/1#issuecomment-220544228

Hey everyone, just to say that we've now resolved these issues (and released v1.1.0). Everything is now correctly in sync with Bintray and the POM files are correctly named/included. We've requested that it be made available Maven central and are just waiting for it to be accepted :-)

Hey again - just to let you know that the package has been accepted on jCentral, so it's now available there :-)


Updating requirements/compat

Hey @jpadilla!
I need to use DRF-JWT in a project, so I have a bit of time.
How would you feel about:

Raising requirements to Django 1.8+
Dropping DRF 2 support
Dropping Python 2.6 and 3.2
Adding Python 3.4 and 3.5

?
(Wanted to check first.)

@carltongibson oh yea, that'd be awesome!

@jpadilla Fine. Next couple of loops. 👍

@jpadilla What would need to be done to get DRF-JWT up to supporting Django 1.9 and DRF 3.2+? Is there enough test coverage that if those things were added to the Travis matrix and any errors were fixed then it would be reasonable to say that those newer version are supported? Are there big known blockers that prevent support on those versions?
I'd like to help if I can, but I'm not sure where to get started.

@mblayman — I'd guess not much. First step is just to update the matrix and see what happens. Start there if you're happy.

Looking at the test matrix on master, it seems that the only thing missing is Django 1.9 testing on Python 3.3. I'll try to put up a PR to get that fixed up.
I think there might be a couple other issues that the tests don't cover because I tried to run JWT on some newer versions (Python 2.7, Django 1.9, DRF 3.3) that did not seem to work. If I track them down, I can add them to a separate issue.

Django 1.9 doesn't support Python 3.3 https://docs.djangoproject.com/en/1.9/releases/1.9/

Closed by #224


Allow offset metadata to be written as part of OffsetCommit requests

Following #389, where we can retrieve the nullable string metadata with an offset, it would make a lot of sense if it could be written, too.

The unit tests still pass, but it would probably be a good idea to cover the case where metadata is actually specified. Not sure how that's to be expressed / structured with how the fixtures are defined, though.

I'm not too sure why those consumer tests would fail as a result of the changes made. Flaky tests, or actually related?

Flakiness 😢


Remove unused env variable

Description
Refer comments in issue #1796 by @JonathanLevi @jeffgarratt , remove unused variable in bddtests
Motivation and Context
Discussion with @JonathanLevi , remove this env variable
How Has This Been Tested?
All test passed.
Checklist:

[x] I have added a Signed-off-by
[] Either no new documentation is required by this change, OR I added new documentation
[x] Either no new tests are required by this change, OR I added new tests
[] I have run goimports, go vet, and golint. I have cleaned up all valid errors and warnings in code I have added or modified. These tools may generate false positives.  The goal is clean, consistent, and readable code.

Signed-off-by:Kai Chen<EMAIL_ADDRESS>

This variable isn't referenced in the code, but it is mentioned numerous times in docs. Probably should remove it wherever it occurs and test.

@christo4ferris Sorry I cannot catch you which doc mentioned this variable.

fabric$ grep -r "CORE_VM_ENDPOINT" .
./bddtests/compose-defaults.yml:    - CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375
./bddtests/compose-defaults.yml:    - CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375
./docs/dev-setup/devnet-setup.md:Your output might contain something like inet <IP_ADDRESS>/16 scope global docker0. That means docker0 interface is on IP address <IP_ADDRESS>. Use that IP address for the CORE_VM_ENDPOINT option. For more information on the environment variables, see core.yaml configuration file in the fabric repository.
./docs/dev-setup/devnet-setup.md:docker run --rm -it -e CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375 -e CORE_PEER_ID=vp0 -e CORE_PEER_ADDRESSAUTODETECT=true hyperledger/fabric-peer peer node start
./docs/dev-setup/devnet-setup.md:docker run --rm -it -e CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375 -e CORE_PEER_ID=vp0 -e CORE_PEER_ADDRESSAUTODETECT=true -e CORE_SECURITY_ENABLED=true -e CORE_SECURITY_PRIVACY=true -e CORE_PEER_PKI_ECA_PADDR=<IP_ADDRESS>:50051 -e CORE_PEER_PKI_TCA_PADDR=<IP_ADDRESS>:50051 -e CORE_PEER_PKI_TLSCA_PADDR=<IP_ADDRESS>:50051 -e CORE_SECURITY_ENROLLID=vp0 -e CORE_SECURITY_ENROLLSECRET=vp0_secret  hyperledger/fabric-peer peer node start
./docs/dev-setup/devnet-setup.md:docker run --rm -it -e CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375 -e CORE_PEER_ID=vp1 -e CORE_PEER_ADDRESSAUTODETECT=true -e CORE_SECURITY_ENABLED=true -e CORE_SECURITY_PRIVACY=true -e CORE_PEER_PKI_ECA_PADDR=<IP_ADDRESS>:50051 -e CORE_PEER_PKI_TCA_PADDR=<IP_ADDRESS>:50051 -e CORE_PEER_PKI_TLSCA_PADDR=<IP_ADDRESS>:50051 -e CORE_SECURITY_ENROLLID=vp1 -e CORE_SECURITY_ENROLLSECRET=vp1_secret -e CORE_PEER_DISCOVERY_ROOTNODE=<IP_ADDRESS>:30303 hyperledger/fabric-peer peer node start
./docs/dev-setup/install.md:Be aware that the Docker bridge (the CORE_VM_ENDPOINT) may not come
./examples/events/block-listener/README.md:docker run --rm -it -e CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375 -e CORE_PEER_ID=vp0 -e CORE_PEER_ADDRESSAUTODETECT=true -e CORE_PEER_VALIDATOR_CONSENSUS_PLUGIN=pbft hyperledger/fabric-peer peer peer
./examples/events/block-listener/README.md:docker run --rm -it -e CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375 -e CORE_PEER_ID=vp1 -e CORE_PEER_ADDRESSAUTODETECT=true -e CORE_PEER_DISCOVERY_ROOTNODE=<IP_ADDRESS>:30303 -e CORE_PEER_VALIDATOR_CONSENSUS_PLUGIN=pbft hyperledger/fabric-peer peer peer
./examples/events/block-listener/README.md:docker run --rm -it -e CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375 -e CORE_PEER_ID=vp2 -e CORE_PEER_ADDRESSAUTODETECT=true -e CORE_PEER_DISCOVERY_ROOTNODE=<IP_ADDRESS>:30303 -e CORE_PEER_VALIDATOR_CONSENSUS_PLUGIN=pbft hyperledger/fabric-peer peer peer
./examples/events/block-listener/README.md:docker run --rm -it -e CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375 -e CORE_PEER_ID=vp3 -e CORE_PEER_ADDRESSAUTODETECT=true -e CORE_PEER_DISCOVERY_ROOTNODE=<IP_ADDRESS>:30303 -e CORE_PEER_VALIDATOR_CONSENSUS_PLUGIN=pbft hyperledger/fabric-peer peer peer
./scripts/idsBuild.sh:	./docker -H $1 run --name=$2 --restart=unless-stopped -d -it -p $5:5000 -p $4:30303 -e CORE_VM_ENDPOINT=$COMPANION_HOST -e CORE_PEER_ID=$2 -e CORE_PEER_ADDRESSAUTODETECT=false -e CORE_PEER_ADDRESS=$3:$4 -e CORE_PEER_LISTENADDRESS=<IP_ADDRESS>:30303 -e CORE_VM_DOCKER_TLS_ENABLED=true -e CORE_VM_DOCKER_TLS_CERT_FILE="/companion_certs/cert.pem" -e CORE_VM_DOCKER_TLS_CACERT_FILE="/companion_certs/cacert.pem" -e  CORE_VM_DOCKER_TLS_KEY_FILE="/companion_certs/key.pem" openchain-peer obc-peer peer
./scripts/idsBuild.sh:	./docker -H $1 run --name=$2 --restart=unless-stopped -d -it -p $6:5000 -p $4:30303 -e CORE_VM_ENDPOINT=$COMPANION_HOST -e CORE_PEER_ID=$2 -e CORE_PEER_ADDRESSAUTODETECT=false -e CORE_PEER_DISCOVERY_ROOTNODE=$5 -e CORE_PEER_ADDRESS=$3:$4 -e CORE_PEER_LISTENADDRESS=<IP_ADDRESS>:30303  -e CORE_VM_DOCKER_TLS_ENABLED=true -e CORE_VM_DOCKER_TLS_CERT_FILE="/companion_certs/cert.pem" -e CORE_VM_DOCKER_TLS_CACERT_FILE="/companion_certs/cacert.pem" -e  CORE_VM_DOCKER_TLS_KEY_FILE="/companion_certs/key.pem" openchain-peer obc-peer peer
./tools/busywork/bin/userModeNetwork:set ::env(CORE_VM_ENDPOINT)             [busywork::dockerEndpoint]

If my understanding is right, that is all for core.yaml and for peer service. What I removed is for membersrvc.yaml and membersrvc service.

Sorry, more context: when working to clean up some more tests/YAML, we wanted to make a small change to the structure of the TLS section in membersrvc.yaml (started and detailed in #1796), @GrapeBaBa found out that the YAML file also contains the CORE_VM_ENDPOINT=http://<IP_ADDRESS>:2375. While CORE indeed needs CORE_VM_ENDPOINT and it is used in many places for docker services, Membership Services clearly does not need it (and thank you again @jeffgarratt, for confirming this).
The only concern raised is that there might have been cases in the past (again, not entirely sure about these, hence the 'might') where Membership Services tests launched a client at some point (something we should not do, IMHO). While I/we could not find these, I don't believe such configuration regarding some client setting/integration tests - should be part of the Membership Services (unit/feature) section, and rather happily live as part of the/an integration tests suite config section, or so.
@christo4ferris I can see how the title could make it sound at first as if this PR suggested that the Env variable is to be removed entirely because it's not used at all (because it is used all over the place, indeed), my apologies. Effectively, we could not find a reference for it in the Membership Service code or use, hence the suggestion/this PR to remove this one instance of the CORE_VM_ENDPOINT env variable from the Membership Service section only of the YAML...

reverify jenkins

LGTM, thanks!

@JonathanLevi Thanks your clarify. @christo4ferris Sorry for confusing,  I  will add more specific title and summary in future.

OMG, the dco-bot runs on coffee too! ;-)
It's all good @GrapeBaBa, it proved good to cover the 2 time-zones thanks again for this!


Keep "focus" on buttons when handling a form with multiple elements

In the Music Preferences experiment, we have a form composed of a ButtonArray and an IconRange component. After selecting a button, when interacting with the slider, the selected button loses focus:
https://github.com/Amsterdam-Music-Lab/MUSCLE/assets/11174072/f28a4bfd-e563-433e-b11e-be73fedfa4af
It would be clearer for participants if they kept the visual feedback from the first choice they made.

I think we shouldn't keep it in "focus" in the html semantics meaning of the word, because that would mean:

The focused element is the element that will receive keyboard and similar events by default.

Source: Mozilla
Which isn't the case, because the user has already moved on to the range slider input. Once it touches the range slider element, that element now has focus.
But yes, we should provide the user with information/feedback about the choice it made. Basically, we can compare it to a button group or radio buttons (but with different styling). Semantically, we therefore have to use the checked attribute to show the browser that the button is active/selected/chosen, and visually we can use a different color or border to make that clear.

Btw, where is this component located, or which specific props do I have to use to reproduce this? Perhaps I can already make a storybook story out of it. 😄


Cache data from remote resources

This PR adds

two new fields: gregorien_cached and ci_concordances_cached
two new properties:has_gregorien_page and ci_concordances, and
two new methods: update_gregorien and update_ci_concordances

to aid in quickly rendering the chant detail page.
When a request for the chant detail page is received, the view/template make use of new has_gregorien_page and ci_concordances properties, allowing the page to be loaded without having to wait for one response from gregorien.info and another from cantusindex.org.

Previously, in order to render the "concordances" section of the chant detail page, the chant detail view would

check for a 200 response from the relevant gregorien.info page before creating the link to gregorien.info, and
pull information on concordances from Cantus Index's json-con API, waiting for a response from CI before sending context to the template

Now, the Chant and Sequence models have

a has_gregorien_page property, which stores the result of the the 200-response check, and
a ci_concordances property, which stores the data from Cantus Index about concordances for the cantus_id in question.
both of these properties do the following:

check to see whether there is a cached value in gregorien_cached or ci_concordances_cached respectively
if there isn't, fetch that information, save it to gregorien_cached or ci_concordances_cached, and then return it
if there is, fetch that value, then call the update_gregorien method or the update_ci_concordances method respectively in the background (i.e. in a new thread), and immediately return the value

The upsides are:

faster load times for chant detail pages
if Cantus Index is having a bad day, we can still display concordances

the downsides:

if lots of changes have been made to CI since someone last visited a particular CantusDB chant detail page, the displayed results will be out-of-date
more data has to be stored in our database. A future optimization might be to make a model to store information on individual Cantus IDs (the concordances and the gregorien page are both specific to a single cantus ID, so if we have 50 different chants with a given Cantus ID, we end up storing up to 50 copies of the concordances)

As this PR adds a couple of new fields to the BaseChant model, be sure to run makemigrations and migrate after pulling!

Also, thanks is in order to @ahankinson, whose recent comment on #401 suggested these changes.

An alternate approach, if it's helpful: Create a Django Admin command that gets run periodically, and sets the value based on the most recent response from Gregorien / CI.
Advantages:

It has zero impact on users. At this point, you're still making the first user wait for responses
It is always up-to-date. If a reference or concordance has been added, subsequent runs will pick up on this.
Your model code is much simpler. You don't need to check various states, etc. -- you just need to set the field value based on the most recent run.

The Django Admin commands basically give you a way of building custom "shell scripts" that help manage and interact with your web app. It also frees you from being bound to things needing to happen via an HTTP request -- processes can take as long as they need, and they don't tie up the web serving "side" of the application.
I think there's also a bug here -- if the gregorien is "None" it will run the update and set either True / False. But if a new reference comes online after it's been checked, then the database will never get updated since it never calls out to update the value.

I'm not sure I see your bug (the spelling-out below is mostly as an exercise to make sure I understand what my code is doing. But also I'm thinking of implementing something similar in other places, so better that I don't introduce this bug into a bunch of places.)
Assume False is currently stored in gregorien_cached, but that gregorien.info has recently been updated to have a page that should load.
Someone requests a view which references has_gregorien_page. Start at line 130:
130: gregorien_cached is not None, it's False - proceed to line 134.
134: set up a thread to call update_gregorien
135: start the thread
136: return the value of gregorien_cached, i.e. return False. This is out-of-date, but that's fine - at least we returned a value quickly, and it will be up-to-date the next time someone visits the view. If the user wants up-to-date concordances info, they can reload the page.
in the meantime, a thread is running, which begins at line 143.
144: we try to visit the gregorien.info page.
147: the status code is 200! Proceed to line 148.
148: set gregorien_cached to True
149: save! now the value is up-to-date for future page loads.
Unless I've missed something, this is the behavior we want - quickly return a value that was accurate the last time we needed to check the value of has_gregorien_page, and in the background we make sure our cached value is up-to-date.

I'm specifically suggesting this for the external resources -- how you cache internal links is up to you! This may also be down to my personal biases about these sorts of things... which I will explain below. I now see that I wasn't reading your code correctly, but that you're actually still doing a request on every page load. I was suggesting this could be avoided with a check once every few days / weeks / months. The data don't actually change that often, so checking on every user request seems like it slows down the user interaction for very little gain. (It was false last time, it's probably going to be false this time...) Nevertheless you do need to check sometimes, so having some process that periodically updates the site is necessary.
As for the number of requests, you could optimize that so that it's not so large; for example, you could assume that a Gregorien record will not get deleted very often, so anything with a link now will have a link later, and thus you can skip any record with a value of True. You could also do the opposite, and skip those with a value of False to see if anything has been deleted, or None to only get those that have not been checked yet. You can also set a rate limit (say 5 r/s) and let it run -- it will take as long as it takes, but that doesn't actually matter.
Right now you're triggering a request on the Gregorien site for every user request on the Cantus site. With a script you can control how many requests-per-second you send to the site so that the traffic is manageable and consistent; with an on-request technique you tie their infrastructure to yours, and require that they be able to handle the same traffic "bursts" as you.  If Cantus starts getting complaints from Gregorien that it's sending too much traffic, you can adjust that in a shell script. But otherwise there's actually no recourse other than to remove the on-request method, since the other option is to limit the number of users. (I know that this is probably not a big deal in this case, but as a general architectural principle it's not really that great to tie sites together like that, particularly if you don't control one of them.)
All that's to say that I would rather have a shell script fail, where I can take my time fixing it and the only consequence is that some data doesn't get updated, than have user requests fail or slow down the site and I need to fix it ASAP since it affects the actual function and performance.

A note on my personal biases: I'm very conservative about what I do, and what I don't do, during a request. When I write HTTP request handlers, I have two driving factors: How fast can it return, and how easily can it fail?
Speed is the number 1 feature that most users look for in a website -- they don't really notice if it works well, but they certainly do notice if it's slow. Calling out to external APIs at request time adds quite a bit of latency to every request, so I only do it if I absolutely need the latest answer -- and generally then I would prefer to cache a response locally and update in the backend through a separate indexing process.
For failure, I look at it two ways.
Exceptions in application servers, depending on how they happen, can take the application down and make everyone grumpy. I get nervous about using libraries  like threading at request time, since I'm never 100% sure that I know that I'm handling the exceptions the thread raises correctly, or that all the wrappers around it (WSGI, etc) will know what to do with it either. requests.get can raise exceptions, which would cause the thread to stop. What happens after that ... I don't know? Will the user know what happened? Will the application keep running? Will the data be consistent? Will anyone ever know if it just keeps failing silently?
The other failure mode is security. This can be as "simple" as not accepting unsanitized input (not a problem here) but could also require thinking about the effects of DDOS -- either targeted or inadvertent. I've seen bad crawlers get stuck on a page and do thousands of requests as they churn through all sorts of options in a form, resulting in a pretty large traffic spike. In this code, that would generate lots of threads requesting the same thing lots of times to Gregorien as well.
json.loads will also raise an exception if the response it gets is not well-formatted JSON. It is now, but if the API on cantus index changes and this page returns a 404, it will break the caching mechanism. (Maybe even silently -- I don't know that anything would ever appear if the thread started raising exceptions? Probably worth testing.)

Thanks for taking the time to write this up, @ahankinson! This is really useful.

With an on-request technique you tie their infrastructure to yours, and require that they be able to handle the same traffic "bursts" as you. If Cantus starts getting complaints from Gregorien that it's sending too much traffic, you can adjust that in a shell script. But otherwise there's actually no recourse other than to remove the on-request method, since the other option is to limit the number of users. (I know that this is probably not a big deal in this case, but as a general architectural principle it's not really that great to tie sites together like that, particularly if you don't control one of them.)

This is a good point. Notably, I'm pretty sure that CantusIndex, and the other sites in the Cantus Network, use the on-request method - when a request is made of http://cantusindex.org/json-con/<cantus ID>/refresh, (I gather that) CI sends a request to the json-cid API of each of the Cantus Network websites, compiles the results, and then returns. But that's maybe an approach we don't want to emulate on visible, more-likely-to-be-crawled pages.

I would rather have a shell script fail, where I can take my time fixing it and the only consequence is that some data doesn't get updated, than have user requests fail or slow down the site and I need to fix it ASAP since it affects the actual function and performance.

This is an excellent point.

Exceptions in application servers, depending on how they happen, can take the application down and make everyone grumpy. I get nervous about using libraries like threading at request time, since I'm never 100% sure that I know that I'm handling the exceptions the thread raises correctly, or that all the wrappers around it (WSGI, etc) will know what to do with it either. requests.get can raise exceptions, which would cause the thread to stop. What happens after that ... I don't know? Will the user know what happened? Will the application keep running? Will the data be consistent? Will anyone ever know if it just keeps failing silently?
...
json.loads will also raise an exception if the response it gets is not well-formatted JSON. It is now, but if the API on cantus index changes and this page returns a 404, it will break the caching mechanism. (Maybe even silently -- I don't know that anything would ever appear if the thread started raising exceptions? Probably worth testing.)

Another excellent point.

I've seen bad crawlers get stuck on a page and do thousands of requests as they churn through all sorts of options in a form, resulting in a pretty large traffic spike. In this code, that would generate lots of threads requesting the same thing lots of times to Gregorien as well.

This is a good point.

A feature that I like of the implementation in this PR is that the cached concordances of chants whose pages are visited frequently get updated often, whereas we're not constantly updating the concordances of less-visited chants. Two alternate approaches suggest themselves that preserve this property while addressing the concerns you raised:

Whenever a chant's detail page is visited, set a flag on that object in the database indicating it's been visited. In our management command that gets run every so often, only update the concordances of chants whose detail pages have been visited, then set the object's flag back to unvisited.

downside: if a user needs up-to-date concordances, they can't get them.

On the chant detail page, default to displaying whatever concordances we have cached. But if the url has an ?refresh-concordances=true query parameter (or something similar), take the time to update our cached concordances before returning a page with the updated version. Add a link to the Concordances section with a link to the "refresh" version of the page.

downside: there's still the possibility of a crawler getting stuck in a loop on the "refresh" version of the page, and a bunch of requests getting sent off to other databases.
upside (kind of) - if an exception is raised, the failure to update the data will at least be noticeable (i.e. the "refresh" version of the page won't load), and if this is causing problems, someone will know to let us know.

I'm leaning now towards option 2, which seems fairly transparent to users, and is similar to the behavior of other websites in the Cantus Network.
Please don't feel the need to type up a response to this unless you're feeling really motivated - this is mostly me thinking out loud, so to speak. Again, thank you!

I hope this doesn't feel like badgering!
I would generally agree with option 2, but for two things:

My REST spidey-sense is tingling with the addition of query parameters that act as changes to state on the server. GET requests, and query parameters, are generally not meant as control mechanisms for server state, since including them (even relatively harmless ones) makes system security more difficult (e.g., you can generally assume that GET requests can be done by anyone, while state-changing requests such as PUT, PATCH or POST, can be secured to require authentication). Query parameters are called as such because they're designed to filter things, not as a way of passing actions to the server. I don't want to bore you with a long-winded diatribe, so I'll just leave it there.
I might suggest doing the offline caching bit first, and when you do it, print out the number of sources that have been changed in a given run. Run it a couple times manually over the span of a week or so, and see how many records are changed. Use that number to inform your decision on whether you actually need the ability to get the latest ones on-the-fly. You could also potentially tie the initial cache in to the saving mechanism of the chants so that it caches the response when the record is saved as well, so your editors would be able to see the latest data. Then if you feel it's out-of-date it would just require a simple re-save of the record to fetch the latest result. Just an idea.

I hope this doesn't feel like badgering!

Not at all - I want to get the implementation right before we go to full production mode! My "don't feel the need to type up a response" mostly me trying to respect your time. But I really appreciate the suggestions!

My REST spidey-sense is tingling with the addition of query parameters that act as changes to state on the server. GET requests, and query parameters, are generally not meant as control mechanisms for server state, since including them (even relatively harmless ones) makes system security more difficult (e.g., you can generally assume that GET requests can be done by anyone, while state-changing requests such as PUT, PATCH or POST, can be secured to require authentication). Query parameters are called as such because they're designed to filter things, not as a way of passing actions to the server. I don't want to bore you with a long-winded diatribe, so I'll just leave it there.

Thinking about it a bit more, I think it would be approximately as easy to set the URL up to look like /chant/<id>/refresh rather than /chant/<id>?refresh-concordances=true. This would solve the concern of non-standard use of query parameters, also bringing the implementation even more in line with other parts of Cantus Index, but it would not address the GET-requests-triggering-state-change concern.

I might suggest doing the offline caching bit first, and when you do it, print out the number of sources that have been changed in a given run. Run it a couple times manually over the span of a week or so, and see how many records are changed. Use that number to inform your decision on whether you actually need the ability to get the latest ones on-the-fly, or if so few change that waiting between runs would be fine.

This is a good point - it's possible this is all much ado about nothing.

You could also potentially tie the initial cache in to the saving mechanism of the chants so that it caches the response when the record is saved as well, so your editors would be able to see the latest data. Then if you feel it's out-of-date it would just require a simple re-save of the record to fetch the latest result. Just an idea.

This raises a question best answered by the musicologists, I think. O Musicologi musicologiaeque (@annamorphism)! Do we foresee many non-indexers using the concordances, or do we expect it mostly to be people who are actively adding chants to and/or editing manuscripts?

Thinking about it a bit more, I think it would be approximately as easy to set the URL up to look like /chant/<id>/refresh rather than /chant/<id>?refresh-concordances=true

If you elevate the "verb" ("refresh") to a path in the URI, you are implicitly suggesting, in the semantics of the HTTP "Resource", that loading this URL will return a "refresh" resource, and that resource is a sub-component of /chant/<id>. The semantics of URLs / URIs are very specific in the HTTP spec, and you need to think of the whole cycle of the request -- not only what it will trigger when you enter the URL, but what it will return when it's successful or it fails. (See also the section on "Safe methods" in the HTTP spec as well, since it ties in to my earlier comment about security with GET / PUT / POST, etc.)
I am being a bit pedantic here, of course. Lots of people do this all the time and it's certainly a very convenient way of writing web apps. I'm mostly coming at this thinking ahead to the LinkedMusic grant, where we're going to be using these URLs as URIs in graph databases. Having to distinguish between "resource" URLs and "function" URLs isn't impossible, but it's nice to limit their use as much as possible.

...or do we expect it mostly to be people who are actively adding chants ...

I guess I'm suggesting that the initial status of the Gregorien concordance is set when an "indexer" saves the record, but then that's immediately available to "non-indexers" as well. So as soon as the record is published, that value will be available. Since the number of people that are editing records is going to be much fewer than those who are looking at the records, triggering an HTTP request on the chant save would seem like a good place to set the initial state of the cache. Then it's down to the periodic refreshes to keep those initial values up-to-date.

https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.1 says that its

definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and cause the server to fail.

If we're caching things related to remote resources upon receiving a GET request, does this not fall within "not entirely read-only, [and/or] caus[ing] side effects"? But if we were to include /refresh or ?refresh-concordances=true, it would contradict the specification that "the client... not request that additional behavior and [not] be held accountable for it".
Your point about chant/<id>/refresh suggesting that we're returning a "refresh" resource is a good point. So yes, let's not do that.

json.loads will also raise an exception if the response it gets is not well-formatted JSON. It is now, but if the API on cantus index changes and this page returns a 404, it will break the caching mechanism. (Maybe even silently -- I don't know that anything would ever appear if the thread started raising exceptions? Probably worth testing.)

I just ran a small test - an exception in a thread just cause just that thread to stop, without causing exceptions in any processes. Details on the exceptions are printed to the terminal. It might still be worth testing this in a running django project, but it looks very likely that if json.loads tries to digest some poorly-formed JSON,

it won't take the server down with it
anything following the exception in the threadified function simply won't be executed, and
details of the exception should appear in the terminal of anyone connected to the django container

Perhaps if we set up a system to log any errors we hit (I'm a bit confused why we don't have any kind of logging set up already) it would be enough to reassure ourselves that updating-our-cached-values-asynchronously-via-threading will not lead us down a path of the caching process failing completely silently.

Looking at the examples they give, I think the intention is to highlight that some processes may make changes on the server -- such as writing to a log file, or charging an accounting department. The key phrase is "that the client did not request that additional behavior and cannot be held accountable for it" -- I take this to mean that any specific requests for behaviours (like the client calling "refresh" to get a refreshed record) falls outside of these exceptions; the client did request it, and they can be held accountable for it.

Details on the exceptions are printed to the terminal. It might still be worth testing this in a running django project ...  should appear in the terminal of anyone connected to the django container

Thinking about this some more, I think the problem with that is that it's only available if a human is connected... You can't catch the exception and send back a status code indicating failure, so effectively it will only be noticed if someone connects and happens to see it. I think this means that it can fail silently, and until someone figures out that the IDs aren't updating (days? weeks? months?), only then would it be fixed.


threaded: make sure that initialization errors aren't panics

this is occuring because of a race when the cpu transfers between threads and makes the "impossible" condition occur.  We (unfortunately) need to spinlock.  This is pretty random and even when it happens it's an exceedingly short amount of time, so it shouldn't be a big deal.


Enable app channels

Codecov Report

Merging #16 (5c15cd1) into master (b5a1897) will decrease coverage by 0.48%.
The diff coverage is 93.93%.

@@            Coverage Diff             @@
##           master      #16      +/-   ##
==========================================
- Coverage   95.82%   95.34%   -0.49%
==========================================
  Files           9        9
  Lines        1007     1118     +111
==========================================
+ Hits          965     1066     +101
- Misses         42       52      +10

Impacted Files
Coverage Δ

src/types.rs
95.83% <87.50%> (+0.59%)
:arrow_up:

src/lib.rs
95.47% <87.75%> (-2.58%)
:arrow_down:

tests/common/mock.rs
94.33% <88.88%> (-3.49%)
:arrow_down:

tests/conclude.rs
94.40% <96.72%> (+0.34%)
:arrow_up:

tests/common/utils.rs
96.38% <100.00%> (+0.23%)
:arrow_up:

tests/deposit.rs
98.52% <100.00%> (ø)

tests/dispute.rs
94.06% <100.00%> (ø)

tests/unit.rs
96.82% <100.00%> (ø)

tests/withdraw.rs
96.61% <100.00%> (ø)

... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b5a1897...5c15cd1. Read the comment docs.


Cannot add document for work group

While I can still as an admin add documents on the circle level, I can no longer do so as admin or group organizer on the group level.

It displays the button "Dokument erstellen" and clicking it does nothing but switches back to the group dashboard. On the circle level, we get the button "Datei hochladen" which opens the upload dialog.

@phillipoertel Now reported by 2 production customers. Would be good to take a quick look and see if it is an easy glitch...

Hi @dottorer , I'm unable to reproduce this on the latest master. Are there some specific steps to take? I can create documents in working groups using the Admin profile or Working Group organizer

Was fixed already; check the last commits :-)
Von unterwegs gesendet, deswegen kurz und evtl. mit Tippfehlern

Am 15.10.2016 um 21:46 schrieb Nolan Chan<EMAIL_ADDRESS>Hi @dottorer , I'm unable to reproduce this on the latest master. Are there some specific steps to take? I can create documents in working groups using the Admin profile or Working Group organizer
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Sorry, was not able to close this out as fixed yet :-) done now...


Allows to control whether setting the dataSource enqueues an update immediately

This allows to make it manually and save a model update which can speed up loading the conversation.

Current coverage is 64.23%

Merging #98 into dev will increase coverage by +0.07% as of 3440354

@@              dev     #98   diff @@
=====================================
  Files          59      59
  Stmts        3084    3090     +6
  Branches        0       0
  Methods         0       0
=====================================
+ Hit          1979    1985     +6
  Partial         0       0
  Missed       1105    1105

Review entire Coverage Diff as of 3440354

Powered by Codecov. Updated on successful CI builds.


[docs] adding missing accessibility labels

[x] I have followed (at least) the PR section of the contributing guide.

Fixes #33781

@oliviertassinari
Can you please review this one ?
Thanks

@PunitSoniME please share on the issue a description of what the problem really as. Also, can you provide some link to wai aria docs with more explanation for the changes related in the PR? Thanks!

@mnajdova
Description added with links and fixes in the Issue - #33781 33781


Can we output html files?

Hi I see an example for svg but can we output html instead?

Hi Aaron
<svg> is a valid HTML tag so it should just work by changing the extension to .html.
Haven't tried it yet but it should work.
Thanks


iter.map() should not guarantee that the closure is executed for all the iterated elements.

This would allow things like optimizing iter::Map's implementation of skip.

It doesn't guarantee it right now, but the implementation is limited, as if it was necessarily true.

To be more specific, executed or not for all elements when? Since Iterator::map does not call the closure a single time unless something more happens to the iterator.
I associate to special-casing the method count for map which I still believe is a significant breaking change if it would be done so that it does not call the mapping function. Previously discussed in https://github.com/rust-lang/rust/pull/28125

Alternatively, we could introduce a notion of purity (this has been discussed in the past but I don't remember where). That is, add a marker trait trait PureFn: Fn {}, automatically infer it for applicable closures/functions, and then add a #[pure] attribute for telling the compiler that a function has no important side effects (even if it looks like it might, e.g., panic, increment some global counter, etc...). This would allow optimizations based on purity. IMO, these optimizations should be done at the type level through specialization, not by the compiler itself.
Unfortunately, 99% of methods in debug mode wouldn't be pure because integer overflow panics in debug mode. This would make debug/release behavior differ significantly (although, arguably, it already does...).

If the map function is pure then the compiler can already optimize it away.

@Stebalien But if it's pure, then LLVM not being able to optimize it is more or less a bug.

Sorry, "pure", not pure. My point is that most non-trivial functions in rust aren't pure (there's going to be an assert/unwrap/allocation etc. somewhere). However, many of these side effects aren't really important and it would be nice to be able to say "this function has no important/noticeable side effects, you can avoid calling it if you don't use the result". Basically, make this kind of optimization (this RFC issue) opt-in.

To defend the cause for some kind of special casing of the counting, the iterator might not be so simple so that a plain .count() without side effects can be reduced to a number (BTreeMap iterators and so on, maybe not even the VecDeque one).

@bluss That's different, in that the data structure may have some simpler way to get the value.
Or do you mean that kind of special-casing combined with @Stebalien's "pure"?

sure, the latter.

What about putting the guarantee not on map, but on count? That is, document count as "consumes all items from the iterator and returns the count". We could add another method that's documented to be specializable.

@durka Once specialization lands, external crate could actually provide that using ExactSizeIterator:
#![feature(specialization)]

pub trait Count {
    fn count(self) -> usize;
}

impl<I> Count for I where I: Iterator {
    default fn count(self) -> usize {
        Iterator::count(self)
    }
}

impl<I> Count for I where I: ExactSizeIterator {
    fn count(mut self) -> usize {
        ExactSizeIterator::len(&mut self)
    }
}

pub fn len<I: IntoIterator>(iter: I) -> usize {
    Count::count(iter.into_iter())
}

@durka That's more or less what count already says Iterator::count in rustdoc

@Stebalien not sure what that adds over len anyway.

@durka len only exists on iterators that implement ExactSizeIterator. This way, you can accept any Iterator (or IntoIterator) and get its length.

There's an intermediate way there too, let (lo, hi) = iter.size_hint(); if Some(lo) == hi { lo } else { iter.count() }

Famous example: chain will often have a dynamically exact size hint.


Human Readable UUID

Hashids hashids = new Hashids("this is my salt");         String id = hashids.encodeHex("586e8cc62663421eadf9d4efa2bd19f4");
This gives yNZEZnb9oDTmEvJpLDqxhw9MQeZ. Can it be shorter at all ?

Plain simple, no. 😉 You can reduce the number, you will reduce the output.


Add a compound launch config to lsp-sample

An LSP implementation with client + server seems like the ideal use case for a compound launch config (I use it all the time when working on the Haxe extension / language server at least), so it seems like a good idea to include one here.
Also fixed some inconsistent indentation.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: Gama11 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks.


Release v1.13.0

Set TTL to 0 for container names
Allow forwarding of names with no ndots
DNS: limit to 3 resolvers and use better timeout for them
Ignore unknown resolv.conf options

/lgtm


Add Orleans 'voting' sample

This adds an Orleans 'voting' sample.
It is based on top of https://github.com/dotnet/aspire-samples/pull/108, so that must be merged before this is (and this will need to be rebased once that PR is merged).

This is ready for review if anyone is willing to take a look.


DO NOT MERGE: minimal task and taskrun controller impl

This PR adds minimal controller logic to the task and taskrun controllers.  The task controller now creates taskruns and the taskrun controller creates builds. Additionally the config/200-clusterrole.yaml file was added to have knative cache access.

Currently when Task/TaskRun CRDs are submitted, the controller syncHandler does not run.  Currently trying to figure out what the issue is there.

Why do we need a Task controller? Does the task automatically trigger a run once its created, doesn't the user or the pipeline have to trigger a taskRun?
I was assuming we would just need a PipelineRun and TaskRun controllers

It seems to be hanging waiting for caching forever here: https://github.com/knative/build-pipeline/blob/master/cmd/controller/main.go#L146

I had assumed that the method for manually triggering a TaskRun would be to create a Task with some "manual run" field set and the Task controller would then spawn a TaskRun in this case.

TaskRun has its own CRD with a TriggerRef so you can just create a TaskRun and that should be the one creating a build and tracking it. The trigger value can be pipelineRun or Manual

Ah I misunderstood this, thanks!  I will change the Task/TaskRun controller to reflect this.


fix: do not use aria-hidden in heading anchor links

Motivation
Fix a11y issue with hash links reported by Rocket Validator, I keep forgetting that.

ARIA hidden element must not contain focusable elements

Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Preview
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/facebook/docusaurus, and link to your PR here.)

wouldn't this revert your fix done in https://github.com/facebook/docusaurus/pull/5708 ?

wouldn't this revert your fix done in #5708 ?

Nah, that's okay, in the last PR I made mistake on the contrary.