HBASE-28576 Remove FirstKeyValueMatchingQualifiersFilter

https://issues.apache.org/jira/browse/HBASE-28576

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 33s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 37s
master passed

+1 :green_heart:
compile
4m  0s
master passed

+1 :green_heart:
checkstyle
1m  7s
master passed

+1 :green_heart:
spotless
0m 55s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 56s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  0s
the patch passed

+1 :green_heart:
compile
4m 21s
the patch passed

+1 :green_heart:
javac
0m 50s
hbase-client generated 0 new + 101 unchanged - 1 fixed = 101 total (was 102)

+1 :green_heart:
javac
3m 31s
hbase-server in the patch passed.

-0 :warning:
checkstyle
0m 51s
hbase-server: The patch generated 1 new + 6 unchanged - 0 fixed = 7 total (was 6)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
7m 25s
Patch does not cause any errors with Hadoop 3.3.6.

-1 :x:
spotless
0m 59s
patch has 21 errors when running spotless:check, run spotless:apply to fix.

+1 :green_heart:
spotbugs
3m 36s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 21s
The patch does not generate ASF License warnings.

44m 19s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5891

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux 8251d89f8f97 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 23fa363d36

Default Java
Eclipse Adoptium-11.0.17+8

checkstyle
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

spotless
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/artifact/yetus-general-check/output/patch-spotless.txt

Max. process+thread count
84 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 27s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 12s
master passed

+1 :green_heart:
compile
1m  8s
master passed

+1 :green_heart:
shadedjars
6m  1s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 42s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 56s
the patch passed

+1 :green_heart:
compile
1m  9s
the patch passed

+1 :green_heart:
javac
1m  9s
the patch passed

+1 :green_heart:
shadedjars
5m 57s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 39s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 42s
hbase-client in the patch passed.

+1 :green_heart:
unit
225m 57s
hbase-server in the patch passed.

254m 42s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5891

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 8269abd1d087 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 23fa363d36

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/testReport/

Max. process+thread count
5061 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 34s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 10s
master passed

+1 :green_heart:
compile
1m 12s
master passed

+1 :green_heart:
shadedjars
6m 35s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 49s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 16s
the patch passed

+1 :green_heart:
compile
1m 20s
the patch passed

+1 :green_heart:
javac
1m 20s
the patch passed

+1 :green_heart:
shadedjars
6m 32s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 50s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 47s
hbase-client in the patch passed.

-1 :x:
unit
274m 55s
hbase-server in the patch failed.

306m 16s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5891

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 7d07d84f86cb 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 23fa363d36

Default Java
Temurin-1.8.0_352-b08

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/testReport/

Max. process+thread count
5086 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 38s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 52s
master passed

+1 :green_heart:
compile
1m 36s
master passed

+1 :green_heart:
shadedjars
6m 34s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 56s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 35s
the patch passed

+1 :green_heart:
compile
1m 26s
the patch passed

+1 :green_heart:
javac
1m 26s
the patch passed

+1 :green_heart:
shadedjars
6m 25s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  3s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 53s
hbase-client in the patch passed.

-1 :x:
unit
278m 43s
hbase-server in the patch failed.

312m 51s

Subsystem
Report/Notes

Docker
ClientAPI=1.45 ServerAPI=1.45 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5891

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 22844cec4423 5.4.0-172-generic #190-Ubuntu SMP Fri Feb 2 23:24:22 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 23fa363d36

Default Java
Eclipse Adoptium-17.0.10+7

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/artifact/yetus-jdk17-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/testReport/

Max. process+thread count
4452 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/1/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

I will fix the spotless check errors

The failed UTs  TestBlockingIPC/TestPrefetchWithBucketCache is not related to the changes, let's see if it will still fail in the new commit.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 40s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 55s
master passed

+1 :green_heart:
compile
3m 23s
master passed

+1 :green_heart:
checkstyle
0m 54s
master passed

+1 :green_heart:
spotless
0m 45s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 16s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 11s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 44s
the patch passed

+1 :green_heart:
compile
3m 15s
the patch passed

+1 :green_heart:
javac
0m 40s
hbase-client generated 0 new + 101 unchanged - 1 fixed = 101 total (was 102)

+1 :green_heart:
javac
2m 35s
hbase-server in the patch passed.

+1 :green_heart:
checkstyle
0m 52s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
4m 54s
Patch does not cause any errors with Hadoop 3.3.6.

+1 :green_heart:
spotless
0m 44s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
2m 33s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 21s
The patch does not generate ASF License warnings.

33m  5s

Subsystem
Report/Notes

Docker
ClientAPI=1.45 ServerAPI=1.45 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5891

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile

uname
Linux 8adb72ad8a29 5.4.0-174-generic #193-Ubuntu SMP Thu Mar 7 14:29:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 23fa363d36

Default Java
Eclipse Adoptium-11.0.17+8

Max. process+thread count
84 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 35s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 49s
master passed

+1 :green_heart:
compile
1m 16s
master passed

+1 :green_heart:
shadedjars
5m 17s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 47s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 49s
the patch passed

+1 :green_heart:
compile
1m 17s
the patch passed

+1 :green_heart:
javac
1m 17s
the patch passed

+1 :green_heart:
shadedjars
5m 10s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 47s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 31s
hbase-client in the patch passed.

-1 :x:
unit
226m 55s
hbase-server in the patch failed.

254m 21s

Subsystem
Report/Notes

Docker
ClientAPI=1.45 ServerAPI=1.45 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5891

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 33dc367ffb76 5.4.0-172-generic #190-Ubuntu SMP Fri Feb 2 23:24:22 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 23fa363d36

Default Java
Eclipse Adoptium-17.0.10+7

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/artifact/yetus-jdk17-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/testReport/

Max. process+thread count
5580 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 29s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 33s
master passed

+1 :green_heart:
compile
0m 54s
master passed

+1 :green_heart:
shadedjars
5m 30s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 36s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 19s
the patch passed

+1 :green_heart:
compile
0m 54s
the patch passed

+1 :green_heart:
javac
0m 54s
the patch passed

+1 :green_heart:
shadedjars
5m 29s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 35s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 24s
hbase-client in the patch passed.

+1 :green_heart:
unit
230m 17s
hbase-server in the patch passed.

255m 42s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5891

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux dd455ae1ac74 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 23fa363d36

Default Java
Temurin-1.8.0_352-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/testReport/

Max. process+thread count
5610 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 27s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 21s
master passed

+1 :green_heart:
compile
1m  7s
master passed

+1 :green_heart:
shadedjars
5m 59s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 42s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m  2s
the patch passed

+1 :green_heart:
compile
1m  8s
the patch passed

+1 :green_heart:
javac
1m  8s
the patch passed

+1 :green_heart:
shadedjars
6m  1s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 40s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 39s
hbase-client in the patch passed.

+1 :green_heart:
unit
230m 34s
hbase-server in the patch passed.

259m 18s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/5891

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 5a8d6170ee61 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 23fa363d36

Default Java
Eclipse Adoptium-11.0.17+8

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/testReport/

Max. process+thread count
4465 (vs. ulimit of 30000)

modules
C: hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5891/2/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

This time, it was a different UT TestNamespaceReplication that failed, and it is not related to the changes.


Removes screenshot in order to make new ones due to a breaking update

for Sankey

@ignatvilesov,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Mar 16th 2021 - Currency Ref Data Meeting Minutes

Currency Reference Data Meeting
Date
20210316 - 10am ET / 3pm GMT
Untracked attendees

Fullname, Affiliation, (optional) GitHub username
...

Meeting notices

FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact<EMAIL_ADDRESS>with any questions.

FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

[ ] Convene & roll call (5mins)
[ ] Display FINOS Antitrust Policy summary slide
[ ] Review Meeting Notices (see above)
[ ] Approve Feb 9th and Feb 23rd meeting minutes
[ ] Sailesh to provide an update on the architecture
[ ] Sailesh to discuss next steps
[ ] AOB, Q&A & Adjourn (5mins)

Decisions Made

[ ] Decision 1
[ ] Decision 2
[ ] ...

Action Items

[ ] Action 1
[ ] Action 2
[ ] ...

WebEx info

WebEx Meeting URL
Meeting Number:<PHONE_NUMBER>
Join by phone: +1.415.655.0003 USA Toll | +44-20319-88141 UK Toll | Access code:<PHONE_NUMBER>
Password: VXcd2eQgh82
Global call-in numbers

closing this issue as it's a duplicate of https://github.com/finos/secref-data/issues/62


Add date-range as parameter to events api

Description
Current GET request for events returns all the events in the database.

Modify the api to take an additional optional parameter for datarange in the request. If the data-range parameters are correct, return only those events in the date-range.
If no date range is provided, return all the events by default.
Perform proper validation of the data-range parameters.**

Acceptance Criteria

events api supports returns events only the date-range provided in the request parameters

User Story
I want to be able to choose a date range and view the statistics (# of registered/participated/absent volunteers, total hours contributed by all volunteers) within this range.

Checkin 1: url parameters- startdate=yyyy-mm-dd&&enddate=yyyy-mm-dd .


Deploying from outside the app's repo with deis pull -a xxx destroys custom process types

I think that this is caused by deis not detecting the app's Procfile, right? But is deleting the custom process types really the desired behavior here? Shouldn't it be better to read the Procfile from inside the image being deployed for example? Or just leaving the processes there, not deleting them if Procfile is not found but continue adding them whenever there is a Procfile within the path...

Was the application a git push app originally (with a Procfile) and then you are doing a deis pull on top of that? Or was it always a deis pull app?

It has mixed deploy types, the first one was a git push, later our Jenkins made a Deis Pull

@felipejfc you can specify a procfile with custom proctypes during a deis pull   either through argument and keeping it in the directory of the pull.
deis pull --help
Creates a new build of an application. Imports an <image> and deploys it to Deis
as a new release. If a Procfile is present in the current directory, it will be used
as the default process types for this application.

Usage: deis builds:create <image> [options]

Arguments:
  <image>
    A fully-qualified docker image, either from Docker Hub (e.g. deis/example-go:latest)
    or from an in-house registry (e.g. myregistry.example.com:5000/example-go:latest).
    This image must include the tag.

Options:
  -a --app=<app>
    The uniquely identifiable name for the application.
  -p --procfile=<procfile>
    A YAML string used to supply a Procfile to the application.

Reading from inside the image is not going to be accepted as that would playing with the image which not many/any users want.
If you want to always add or just leave the proctypes as it is, how can one delete existing proctypes.

@kmala, maybe with deis ps:delete proctype... I agree that getting from inside the Docker image is not a good option but deleting proctypes stealthily this way can cause confusion... It happened with a dev on my team this week.

@felipejfc Think the big issue here is mixing deployment types - Not something we'd recommend if you have multiple process types.
What happened in your scenario is how Deis has always worked. For deis pull you have to provide the yaml string of the Procfile to keep the behaviour you are mentioning above.

Maybe just a warning that deploying will delete proctypes would be sufficient...

I touched on the intended workflow of deis pull in https://github.com/deis/controller/issues/1094#issuecomment-250603486, so this is working as intentional. However some documentation around this wouldn't hurt.

Today my team faced the same issue of one people deploying with deis pull outside of the app's folder and because of that we were running our app without one of its components for a week... I do think this is a serious bug and we should at least warn the user that process types will be deleted when one pushes without being in Procfile's folder or specifying one.

We may want to consider preventing a deis pull or git push when the app has been deployed one way or the other first. It is rather artificial but could do the trick. We'd have to keep track of how the build was started
In the past we could have looked at the Push model but that got removed... hmm - @bacongobbler do you think that'd work out in addition to docs so @felipejfc and others don't have the accidental scenario happening still

@helgi i don't think it help in this case as i assume from @felipejfc comments that they are doing a deis pull all the times but sometimes within the app folder which has procfile and sometimes from another folder which doesn't have procfile

Yeah, however in @felipejfc earlier comments he said the (original) app was started with git push and then Jenkins did pull. In that scenario we'd restrict the app to git push only - It's not a clean solution tho :(

I also don't like this solution (restrict the app to git push only)... I don't think the problem here is with mixed deployments (git push or deis pull), what happened like 3 times already was different people deploying without being in app's folder and using deis pull... then some of the process types are deleted by deis. I think the problem here is that one assume the deployment succeded because of deis telling so but some process types was deleted in background without even warning the user...  I don't think docs would solve this either :/

@felipejfc I understand why you are frustrated by this but that's how Deis has always worked, and I believe Heroku. With documentation.
What we are coming up against here is the notion that the Procfile can add/update/remove process oppose to only do an add/update operation.
To prevent your scenario then we'd have to change the whole system so that when a user wants to remove a process type they have to do a deis scale --type foo 0 before/after their deploy, regardless of them describing the intent by removing the foo process from the Procfile. @felipejfc I would be curious how you would want that scenario to work yet still support people accidentally leaving out the -p on deis pull or not being in the right directory when doing the deploy?
That's a rather large behavioural change in Deis - That's why I am trying to propose alternatives.

@helgi thanks for the attention :) Can't we just warn the user? like...
Hey, you are using deis pull without specifying a Procfile and Deis could not detect any in the current path, are you sure you want to proceed? This may delete some of your custom process types... [y/n]
This message may only be placed when deis detects that the user has more process types than just cmd for example...

As far as the CLI goes, I personally never use a Procfile with Deis - That question would drive me nuts :) Could potentially look and see if we have extra process types, as you said, beside cmd or web and go from there - Means the CLI has to do a double query.
The communication between the API and the CLI is not that fluid during an operation such as Deploy. The API will return a 200 and the CLI will go "okay, done!" - So far we have not had a scenario of doing a 200 with a custom message. We could reject the deploy on the basis of removal but that's again changing behaviour.
I only mention the above as an illustration that if the CLI is doing such double checking then that's a CLI feature - Not something we have available as a "oh no!" kind of warning coming from the API directly. Other SDKs would run up against this. And that might be just fine?

I understand and I do think that making it a CLI feature is not the ideal solution here, but I do think it is better than nothing, right? I really don't see any other options besides making a double query in the CLI or rejecting the deploy in API level. But one thing I do know, only making some docs on this will not prevent 100% of the people from making this same mistake, me and 3 others of my team already did it because some of our deployments are automatic (made by Jenkins) and some others are manual... the manual ones are error prone. From our experience, you only learn about this issue when it harms you.

Hi @helgi,
First of all, I'd like to thank the whole team behind Deis. We are enjoying it tremendously and it's helping make us more agile.
That said, I'm very concerned about the current behavior in Deis. I wholeheartedly disagree with the statement that removing the line from the Procfile and not having a Procfile at all are the same scenario.
I think the problem boils down to three different scenarios:

Scenario A - App was deployed with git push and obviously the Procfile is available, and then it is deployed with deis pull in a folder where the Procfile is not available;
Scenario B - App was deployed with deis pull in the folder with the Procfile, and then it is deployed with deis pull in a folder where the Procfile is not available;
Scenario C - Both times the deployiment was with deis pull, but first in the folder with the Procfile and then in a folder without it.

The point we have to make here is that all the above scenarios perform destructive operations (unless the procfile only did have one command). In my experience, the old saying pays every time: it's better to be safe than sorry.
In order for Deis to be more reliable, I believe it just needs to be more straightforward with the users when it does not know what to do. If a deploy was made with a Procfile and the next one is not, then just let the user know: No Procfile was found and the API reports that the previous deployment was made with a Procfile. Please use --no-procfile if you removed it.
This way, if it the user really intended to remove the Procfile, they will just retry with --no-procfile and from that point forward no message will be given (after all, there will not be a Procfile in the previous deployment, right?).
Don't get me wrong, I'm all for docs explaining what the system does. I try to get the most complete docs I can in every open source project I maintain. The point here is that every system should be secure by default and be made less secure intentionally by users (AWS is a good example). Right now, the behavior Deis is exhibiting is not the most secure possible.
If you do need help with this issue, let us know what we can do.

Right now, the behavior Deis is exhibiting is not the most secure possible.

I'm not sure how this has to do with security, but I see your point.
So to summarize your concerns, if one deploys an app via git push with a web and a worker process type, then another user deploys to the same application another image using deis pull without any process types, the client should pull down the current app structure, verify the current structure against the proposed structure, display a warning that the process types differ and ask for confirmation. Does that sound fair to you?

In order for Deis to be more reliable, I believe it just needs to be more straightforward with the users when it does not know what to do. If a deploy was made with a Procfile and the next one is not, then just let the user know: No Procfile was found and the API reports that the previous deployment was made with a Procfile. Please use --no-procfile if you removed it.

This sounds like a good idea at first, but we cannot do this in a backwards-compatible fashion. We cannot refuse the incoming request with No Procfile was found and the API reports ... because we allow users to deploy images with differing process types between releases. However, making a client-side validation for users using both git push and deis pull sounds like a reasonable compromise.
If you're willing to take a crack at a PR, feel free to write one up!

It does sound fair enough as it alleviates our scenario.
When I say it's not the most secure possible I do not mean as in someone can take control of my app or something like that. I mean secure as in safe. It means that I will not take down a portion of my app by misunderstanding of Deis internals.
I can definitely see the flow of git pushing a Procfile with additional targets. What I meant is that a confirmation should be required whenever a destructive action is detected (removing a target). The issue arises whenever the user is pushing a Procfile without a specific target. I do not have a good answer here, I think. I still feel the safer side is best, since a destructive operation might be very bad in specific scenarios.
What do you say of a specific configuration in Deis that disallows destructive actions without confirmation? Then the admin of the Deis farm can set that flag to true if they so wish. This way, Deis would be backwards compatible (flag defaults to false) and still enable us to "harden" it a little bit.
I'm proposing this, because I feel if this is not at the API level, it might be abused anyway.
If that is something acceptable, I can definitely take a crack at it.

One solution would be to add a --keep-proc-types (name TBD) and it would allow your use case as long as you guys remembered to add that flag... That's the best compromise I can come up with that involves the API in the solution.
That way you'd simply have to use the flag or use a deis pull --keep-proc-types alias for everyone. I haven't investigated yet about being able to use the deis CLI config file to set defaults like that... We could potentially take it as far as people setting the behaviour in .deis/config or similar but not promises on that one until I've looked into it further.
I do realise that by default this still keeps the less forgiving and more destructive behaviour.
Thoughts @felipejfc @heynemann ? This is a slightly different thing than what @heynemann just proposed (I still think that'd be a worthwhile second proposal overall - Worth opening up a proposal ticket?)

Yep, what I meant is that if it's not something that we can turn on (or off depending on your perspective) from the admin side of things, we'd still have issues with it.
Right now we are in the process of rolling out Deis for something like 50 devs. It's going to make it harder and more error prone if we have to remind everyone to always use a flag when doing deis pull.
Don't get me wrong, it is doable and we'll do it. I just feel that we have an opportunity here to improve the platform. If the team maintaining Deis disagrees, I'll respect your opinion and we can close this ticket.
If you feel I should open a new issue with the proposal for the API changes, just let me know and I'll try to come up with something that works for everyone while still being backwards-compatible.
Thanks for your time in replying here.

I do realise that by default this still keeps the less forgiving and more destructive behaviour.

Hi @helgi , I agree with you and I also agree with what @heynemann said before:

The point here is that every system should be secure by default and be made less secure intentionally by users (AWS is a good example)

And I think that just adding a non-default flag will not make it "secure" by default...

So to summarize your concerns, if one deploys an app via git push with a web and a worker process type, then another user deploys to the same application another image using deis pull without any process types, the client should pull down the current app structure, verify the current structure against the proposed structure, display a warning that the process types differ and ask for confirmation. The validation (read: the second API request) and prompt can be overridden with a --yes or -y flag. Does that sound fair to you?

Yes, this sounds very fair!

@heynemann A proposal around the destructive things would be fine - We do ask people (on the CLI) when destroying resources (app, certs, domains, etc) for confirmation already but that's not something enforced in the API as needing a confirmation.
If you want to try to find a generally backwards compatible way to achieve non-destructive process type actions without --keep-proc-typesflag or a configuration for the CLI (as in neither is enforced in the API)
Just so we are on the same page, we are being cautious since the behaviour that is biting you is a behaviour other users may depend on, so we are trying to keep things backwards compatible during the 2.x cycle - mixing git push and deis pull is rather unique in this all :)

@helgi you do not need to mix git push with deis pull to hit the issue, I think that if my first deploy is from inside the project folder with a deis pull (deis-cli detects the procfile) and a second deploy is made also with deis pull but from outside the project folder I would still hit this scenario (deleted process types), right?

mixing git push and deis pull is rather unique in this all :)

To add onto this, I think the question on our minds is how come you are using two separate workflows for the same application.  Originally, we only provided git push as the only workflow for deploying apps, then added Dockerfile functionality to the builder. deis pull was intended to be used for the CI/CD workflow. Each deployment type has their own unique workflow, either by using a Procfile in the app or by providing a list of process types in --procfile.

I think that if my first deploy is from inside the project folder with a deis pull (deis-cli detects the procfile) and a second deploy is made also with deis pull but from outside the project folder I would still hit this scenario (deleted process types), right?

If reading from a local Procfile on local disk via deis pull is the issue you're facing, then perhaps we should deprecate that functionality altogether and require users to use deis pull --procfile $(cat Procfile) deis/example-go instead.

If reading from a local Procfile on local disk via deis pull is the issue you're facing, then perhaps we should deprecate that functionality altogether and require users to use deis pull --procfile $(cat Procfile) deis/example-go instead.

The issue we are facing is when the cli does not detect the procfile and defaults to deleting custom process types...
This may help to solve the problem but also makes harder to deploy with deis pull in the cases that I do not need a Procfile at all (just letting cmd run the default image cmd is enough)... What do you think about that @bacongobbler?

@bacongobbler I'm all for requiring a --procfile if the previous deployment was made with a Procfile. That would prevent our issue altogether.
Just to clarify what exactly is the scenario that is biting us.

Developer A wants to deploy his app to Deis. As we use containers for all our apps, he deploys with deis pull. Dev A deploys in the folder that contains the Procfile (or uses --procfile) and we get both worker and web targets in Deis.
After some time, Developer B want to deploy a new version of the app. She makes her changes, waits for the CI to finish building the docker image in our private repository. Once it is done and deployed to staging, she gets the new version and decides to do a deis pull to production with that version. As it is already working in staging, she just fires a new terminal window and does a deis pull.
Deis silently removes both targets web and worker and replaces them with cmd that defaults to whatever entrypoint the docker image has. After the deployment is done, it tells her that everything is fine.

Just by reviewing this workflow in my head I can see that we could easily improve a lot (even if we do not fix the current behavior) just by returning the new targets with their allocated units:
Creating build... ...o  (cropped output for clarity)
done

Targets before this version:
* web (2 units)
* worker (2 units)

Targets after this version:
* cmd (1 unit)

What do you guys think about this? We could even give the same output in the CLI and confirm:
Targets before this version:
* web (2 units)
* worker (2 units)

Targets after this version:
* cmd (1 unit)

The targets differ between version 5 and version 4. Are you sure you want to continue? y/n

The problem with that approach returns us to the double query problem. That is, we need to first fetch the app's procfile structure, compare it to what's proposed then push the new build after confirmation. For properly formed deis pull commands (i.e. one that supply --procfile, have a Procfile in the local directory or don't supply a Procfile at all) that's one request too many compared to the current workflow.

Just by reviewing this workflow in my head I can see that we could easily improve a lot (even if we do not fix the current behavior) just by returning the new targets with their allocated units:

Sure, we could display the application's process types after a push. Would that work for you?

The reason we are against most of these changes are because the main reason this came up is due to user error. While it is true that using deis pull outside of the intended directory is a destructive action (and I understand the frustration), all of the solutions provided so far requires changes or sub-optimal solutions to users that do not have this problem because either
a) they explicitly use --procfile every deployment, which then they don't rely on being in the right subdirectory
b) CI deploys the image for them in the same workspace every time, getting rid of the user error problem
c) they use a different workflow that embeds the Procfile as part of their workflow
In other words, any solution we write is going to be a win for you guys (no more destructive actions), but it's a loss for everyone else (extra API requests, breaking changes, etc). That's why we're more prone to lean on documentation or suggest a different workflow to your org for this issue.

I agree 100% @bacongobbler and that's why I want to provide the strict mode as a configuration that the Deis farm admin can enable. We'd be using it to ensure that people can't perform destructive actions without confirmation. Deis default could be the way it works right now.
If that's not something you see going forward, I would be very happy if the API returned the targets before and after the deployment so that the CLI could tell that to the user. Highlighting that the targets changed should be enough to tell the user that something's amiss (unless they expect the targets to change).
What would be a workflow that would work with containers? What this means is that we want the exact same container image that's running on staging to be deployed to production. If you guys could shed some light on that we'd appreciate it immensely.
What do you think?

What would be a workflow that would work with containers? What this means is that we want the exact same container image that's running on staging to be deployed to production.

Assuming all your images are on a private registry after your changes are merged into HEAD and you have CI infrastructure set up, you can maintain two separate apps called myapp and myapp-staging. myapp-staging is then a direct mirror of whatever's in HEAD via CI running deis pull at the end of the job that's run when merged into master. Once you're happy with what's in HEAD, you can run a job that pulls that image into production.
CI isn't necessary here, but it helps with the automation from merging the commit(s) into HEAD to your staging environment. For an example, you may want to take a look at our own Jenkins job flow. We're not deploying to a Workflow cluster (though we have our own clusters for in-house apps like Slack/Github bots), but we are pushing our staging bits to quay.io.

I agree 100% @bacongobbler and that's why I want to provide the strict mode as a configuration that the Deis farm admin can enable. We'd be using it to ensure that people can't perform destructive actions without confirmation. Deis default could be the way it works right now.

As long as we get it documented on how it works, where it's useful and writing the necessary tests I'm all for a PR for an opt-in server-side feature flag.

Please see https://github.com/deis/controller/pull/1099 - It is only a proposed solution or at least a partial solution. It only tackles the notion of giving Deis operators (admins) and the developers the ability to turn off the removal of processes when Procfile is missing - It does not try to cover other (potentially) destructive behaviours and so on.
@heynemann This could potentially serve as the basis of future work you may want to do?

I'm going to call this closed as #1099 got merged - Anyone involved here, please reopen this ticket if we didn't cover concerns


EveMarketData.GetItemHistory() returns no results.

I have:
EmdOptions options = new EmdOptions();             EveMarketData data = new EveMarketData(EveMarketData.DataFormat.Json);             for(int i = 20; i < 100; i++)             {                 options.Items.Add(i);             }             options.Regions.Add(10000002);             options.AgeSpan = new TimeSpan(TimeSpan.TicksPerDay * 10);
Which looks like all I should need but I get no results. What am I doing wrong?

I think the history endpoint has been removed completely, haven't used emd
in a long time. The config looks correct.
On Dec 23, 2016 21:51, "themightymanuel"<EMAIL_ADDRESS>wrote:

I have:
EmdOptions options = new EmdOptions(); EveMarketData data = new
EveMarketData(EveMarketData.DataFormat.Json); for(int i = 20; i < 100;
i++) { options.Items.Add(i); } options.Regions.Add(10000002);
options.AgeSpan = new TimeSpan(TimeSpan.TicksPerDay * 10);
Which looks like all I should need but I get no results. What am I doing
wrong?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ezet/evelib/issues/106, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcHQwlAh_pQu-9LSQG9rDIJi_x0KuKxks5rLDQ3gaJpZM4LVDur
.


Classification Rules as iThoughts CSV Tree

Allow all or part of the classification rules to be exported in tree form. If we do it in iThoughts CSV format then filterCSV can transform to eg Freemind or OPML.
Exact UI needs working out for the selection of eg DDF subsystem.

Done. Better UI implementations welcome, though.


Improve clipboard handling in "drag and drop" scenario

Summary of the Pull Request
This PR improves the clipboard handling logic of "drag and drop" in TermControl, making it more useful and less likely to crash.

Added support for two more categories of content, ApplicationLink and WebLink.
Reordered the ifs, making StorageItem the last clause. With WT being a text-oriented application, I think we can safely assume that the content being pasted is likely to be text/links.
Catch possible exceptions during e.DataView().GetStorageItemsAsync().

PR Checklist

[X] Closes #7804
[X] CLA signed. If not, go over here and sign the CLA
[ ] Tests added/passed
[ ] Documentation updated. If checked, please file a pull request on our docs repo and link it here: #xxx
[ ] Schema updated.
[ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Validation Steps Performed
Manually tested.

During the development of this PR, I found that simply putting Text before StorageItem would fix the crash described in #7804, although the content being pasted isn't really useful. This is what I got which seems like a internal URI used by VSCode:
walkThrough:/c%3A/Program%20Files/Microsoft%20VS%20Code/resources/app/out/vs/workbench/contrib/welcome/page/browser/vs_code_welcome_page?%7B%22moduleId%22%3A%22vs%2Fworkbench%2Fcontrib%2Fwelcome%2Fpage%2Fbrowser%2Fvs_code_welcome_page%22%7D

But just in case there is any other possible exceptions, I added the catch anyway.
For WebLink, you can drag a hyperlink in Firefox and drop it in WT, it should work.
For ApplicationLink I didn't find an application that actually produces this kind of content, but I assume it should be the same as WebLink, so I added it alongside WebLink.

Yes! The comment is exactly what I want to add but failed to compose. You have read my mind 😄

😎


LinkedList to PyList conversion

For some functions, I'd like to return a LinkedList. However, IntoPy is only implemented for Vec<T>, so I currently first convert to a Vec, then allow pyo3 to convert the Vec to a PyList. This seems a bit inefficient, if I'm properly understanding how the conversions happen under the hood. It seems like going directly from LinkedList to PyList would be more efficient. I am willing to implement this, if such a PR would be welcome here.
This project's awesome!

I think PyList::new(py, my_linked_list) should work for a manual conversion?
A PR to implement IntoPy and ToPyObject for LinkedList<T> would be very welcome - see the implementations for Vec<T> as a starting point.

I may give this a try!

@OliverFM see https://github.com/PyO3/pyo3/pull/2446 - we almost merged this previously but stalled as we weren't convinced that it's definitely helpful.
Before putting effort into rebooting the implementation we should justify whether this conversion should exist.

Thanks for the heads up – it looks like that issue is surmountable, and was only because of the way the test was constructed.
Very happy to skip this on the basis of it not being useful though.
I don't make very extensive use of pyo3 at the moment, and very rarely use linked lists, so I wouldn't know if this would be a useful addition.

I mean, they're very different data structures. I'm not convinced that linkedlist -> pylist is the obvious thing to do.

This is the comment I am referring to as being the concern from @mejrs which we never resolved.

very rarely use linked lists

As does everyone else 😆 So this wouldn't be very useful.
My main concern is that it doesn't do what people expect. If you naively write some Rust code returning a String, Vec or HashMap to Python you can reasonably expect what you'll get on the Python side. What do you get when you return a LinkedList to Python?

Maybe worth closing this issue in that case?

I think that's probably a good idea 👍


How to detect when invalid password is provided?

please provide more details (at least code example)

@skywinder Thank you for your reply. Here I try to provide more details.
I have a function which imports a wallet with its keystore.
    func importByKeystore(keystore: String, password: String) -> String {

        // Before initing keystore I want to check provided password is correct.
        let keyStore = EthereumKeystoreV3.init(keystore)
        return (keyStore?.getAddress()!.address)!
    }

Thank you.

@skywinder Thank you for your reply. Here I try to provide more details.
I have a function which imports a wallet with its keystore.
    func importByKeystore(keystore: String, password: String) -> String {

        // Before initing keystore I want to check provided password is correct.
        let keyStore = EthereumKeystoreV3.init(keystore)
        return (keyStore?.getAddress()!.address)!
    }

Thank you.


Management of (external) Transit Gateway Attachments

**Problem statement (with example)
Integrating Enterprise AWS Cloud Platform to Mulesoft Private Spaces using Transit Gateway Attachments

Overall process:

Customer creates Transit Gateway Route table within the Landing Zone Accelerator
Customer Shares Transit Gateway with Mulesoft
Mulesoft create TGW attachment
Customer accepts TGW attachment
Customer configures routing (snippet: Interim auxiliary template for route propagation and route table association)

A east/west firewall is used in this architecture for traffic inspection
Describe the feature you'd like

Ability to propagate routes from attachments not defined in LZA. Currently available through TransitGatewayAttachmentConfig routePropogations for defined VPCs

TransitGatewayRouteEntryConfig supports attachment which does not support a physical resource (only resources selected by name of the various types)

Similar to the above, cannot associate attachments (created outside of LZA) to LZA defined TGWs

Additional context
Transit Gateway Config:
transitGateways:
  - name: tgw-networking-prod
    account: Network
    region: *HOME_REGION
    shareTargets:
      accounts:
        - NetworkEdge
    routeTables:
      # Routes to spoke VPCs are propogated to the route table
      - name: tgw-rt-infra-firewall-apse2
        routes: []
      - name: tgw-rt-external-np-mulesoft-apse2
        routes:
          - destinationCidrBlock: <IP_ADDRESS>/0
            attachment:
              vpcName: vpc-d-infra-prod-firewall-apse2
              account: NetworkEdge

Interim auxiliary template for route propagation and route table association:
AWSTemplateFormatVersion: "2010-09-09"

Description: Integrate Mulesoft to Existing TGW via Firewall (from Network Core)

Parameters:
  MulesoftAttachmentId:
    Type: String
    Description: Mulesoft Attachment Id

  MulesoftRouteTableId:
    Type: AWS::SSM::Parameter::Value<String>
    Description: SSM path to specific MuleSoft Route Table Id
    Default: /accelerator/network/transitGateways/tgw-networking-prod/routeTables/tgw-rt-external-np-mulesoft-apse2/id

  FirewallRouteTableId:
    Type: AWS::SSM::Parameter::Value<String>
    Description: SSM path to specific Firewall Route Table Id
    Default: /accelerator/network/transitGateways/tgw-networking-prod/routeTables/tgw-rt-infra-firewall-apse2/id

Resources:
  MulesoftRouteTableAssociation:
    Type: AWS::EC2::TransitGatewayRouteTableAssociation
    Properties:
      TransitGatewayAttachmentId: !Ref MulesoftAttachmentId
      TransitGatewayRouteTableId: !Ref MulesoftRouteTableId

  # Firewall
  PropogateMulesoftToFirewall:
    Type: AWS::EC2::TransitGatewayRouteTablePropagation
    Properties:
      TransitGatewayAttachmentId: !Ref MulesoftAttachmentId
      TransitGatewayRouteTableId: !Ref FirewallRouteTableId

Hi Richard!
I've went ahead and created a feature request for this. I'll keep this issue open as we continue to evaluate the request in our backlog. If you have any other questions or concerns in the meantime, please do not hesitate to contact us.


Logout after browser's restart

ungoogled-chromium version: 67.0.3396.87
Configuration and/or platform(s): Ubuntu 18.04
Problem description:
Each browser restart it logouts me from all resources: Youtube, GitHub etc. Is it bug or feature?

It's a feature, see #484.


Allow users to specify the resource folder name

What's the problem this feature will solve?
It will allow users to specify the resource folder name and change it while running.
Describe the solution you'd like
Property on BaseBot to set the resource folder name
Additional context
Requested via Forum (https://community.botcity.dev/t/change-resources-folder/476/3)

Solved via #5


Ability to parse/check Helm chart repository metadata

I've been trying to get version data for Helm charts where there is no apparent git tag or release, this is pretty common for repositories that contain multiple Helm charts.
Example: https://github.com/bitnami/charts/tree/master/bitnami
I see a couple various ways of doing this.

All charts has a Chart.yaml that contains a version, example: https://github.com/bitnami/charts/blob/master/bitnami/apache/Chart.yaml

Most repositories, but not all, produce a repository manifest. Example: https://charts.bitnami.com/bitnami/index.yaml

I'm not sure about this.
With option 2, the "index file" of sorts for all helms available in the repository, you can query helm versions available by running helm ....
With option 1, how do you envision invoking lastversion ...
All in all, I don't understand what would be a useful use case :-)

My use case is making a small tool to compare one version, for instance the currently installed, against available version. Preferably without having helm installed.
I've not looked at the lastversion cli all that much, but rather using it as a module I envision using it as lastversion.latest('https://github.com/bitnami/charts/blob/master/bitnami/apache/Chart.yaml')
No problem if this is outside of lastversion usage/scope, I'll always find another way. We use lastversion for some charts that rely on git tagging and would prefer to use one module/method for all charts :-)
lastversion.latest('https://github.com/codecentric/helm-charts/tree/master/charts/keycloak') is an example that works since they use tags

@terbolous can you check if it behaves as desired, from the master commit of lastversion.
With invocation like lastversion.latest('https://github.com/bitnami/charts/blob/master/bitnami/apache') (on a repository without tags), there's no telling that there's Chart.yaml without trying checking for its existence, which we better avoid.
So for such URLs, you'll have to explicitly specify the type via  lastversion.latest('https://github.com/bitnami/charts/blob/master/bitnami/apache', at='helm_chart').
For URLs with Chart.yaml, specifying at is not needed.

LGTM, thanks :)

Released in v1.3.5.


ClassCastException when running in AOT mode applying aspect to @RefreshScope bean

Was referred from https://github.com/spring-projects/spring-boot/issues/34433
When running an AOT build of an application with a @RefreshScope bean that has an aspect applied to it, the application fails during runtime startup with the following stack trace.
I have created a reproducer at https://github.com/justin-tay/spring-boot-refresh-aspect-issue which demonstrates the issue.
In my actual application both the @RefreshScope RestController and the aspect are being contributed by two separate libraries so I'm not sure if I'm doing something wrong.
Running mvn spring-boot:run shows that it starts up normally.
Running mvn clean package -Pnative and then java -Dspring.aot.enabled=true -jar target/demo-0.0.1-SNAPSHOT.jar shows the exception.
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'demoController': Unexpected AOP exception
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:607) ~[spring-beans-6.0.5.jar!/:6.0.5]
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:522) ~[spring-beans-6.0.5.jar!/:6.0.5]
        at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:326) ~[spring-beans-6.0.5.jar!/:6.0.5]
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) ~[spring-beans-6.0.5.jar!/:6.0.5]
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:324) ~[spring-beans-6.0.5.jar!/:6.0.5]
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:200) ~[spring-beans-6.0.5.jar!/:6.0.5]
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:955) ~[spring-beans-6.0.5.jar!/:6.0.5]
        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:917) ~[spring-context-6.0.5.jar!/:6.0.5]
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:584) ~[spring-context-6.0.5.jar!/:6.0.5]
        at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:146) ~[spring-boot-3.0.3.jar!/:3.0.3]
        at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:732) ~[spring-boot-3.0.3.jar!/:3.0.3]
        at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:434) ~[spring-boot-3.0.3.jar!/:3.0.3]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:310) ~[spring-boot-3.0.3.jar!/:3.0.3]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1304) ~[spring-boot-3.0.3.jar!/:3.0.3]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1293) ~[spring-boot-3.0.3.jar!/:3.0.3]
        at com.example.demo.DemoApplication.main(DemoApplication.java:10) ~[classes!/:0.0.1-SNAPSHOT]
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[na:na]
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
        at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[na:na]
        at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:49) ~[demo-0.0.1-SNAPSHOT.jar:0.0.1-SNAPSHOT]
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:95) ~[demo-0.0.1-SNAPSHOT.jar:0.0.1-SNAPSHOT]
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:58) ~[demo-0.0.1-SNAPSHOT.jar:0.0.1-SNAPSHOT]
        at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:65) ~[demo-0.0.1-SNAPSHOT.jar:0.0.1-SNAPSHOT]
Caused by: org.springframework.aop.framework.AopConfigException: Unexpected AOP exception
        at org.springframework.aop.framework.CglibAopProxy.buildProxy(CglibAopProxy.java:222) ~[spring-aop-6.0.5.jar!/:6.0.5]
        at org.springframework.aop.framework.CglibAopProxy.getProxy(CglibAopProxy.java:158) ~[spring-aop-6.0.5.jar!/:6.0.5]
        at org.springframework.aop.framework.ProxyFactory.getProxy(ProxyFactory.java:110) ~[spring-aop-6.0.5.jar!/:6.0.5]
        at org.springframework.aop.scope.ScopedProxyFactoryBean.setBeanFactory(ScopedProxyFactoryBean.java:115) ~[spring-aop-6.0.5.jar!/:6.0.5]
        at org.springframework.cloud.context.scope.GenericScope$LockedScopedProxyFactoryBean.setBeanFactory(GenericScope.java:448) ~[spring-cloud-context-4.0.1.jar!/:4.0.1]
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeAwareMethods(AbstractAutowireCapableBeanFactory.java:1773) ~[spring-beans-6.0.5.jar!/:6.0.5]
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1740) ~[spring-beans-6.0.5.jar!/:6.0.5]
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:600) ~[spring-beans-6.0.5.jar!/:6.0.5]
        ... 23 common frames omitted
Caused by: java.lang.ClassCastException: class org.springframework.aop.framework.CglibAopProxy$SerializableNoOp cannot be cast to class org.springframework.cglib.proxy.Dispatcher (org.springframework.aop.framework.CglibAopProxy$SerializableNoOp and org.springframework.cglib.proxy.Dispatcher are in unnamed module of loader org.springframework.boot.loader.LaunchedURLClassLoader @3eb07fd3)
        at com.example.demo.api.DemoController$$SpringCGLIB$$0.setCallbacks(<generated>) ~[classes!/:0.0.1-SNAPSHOT]
        at org.springframework.aop.framework.ObjenesisCglibAopProxy.createProxyClassAndInstance(ObjenesisCglibAopProxy.java:91) ~[spring-aop-6.0.5.jar!/:6.0.5]
        at org.springframework.aop.framework.CglibAopProxy.buildProxy(CglibAopProxy.java:213) ~[spring-aop-6.0.5.jar!/:6.0.5]
        ... 30 common frames omitted

After debugging I can somewhat see the sequence of events but I don't really know how this can be fixed.
During a normal run (-Dspring.aot.enabled=false) the proxy generation follows the following sequence

org.springframework.cloud.context.scope.GenericScope$LockedScopedProxyFactoryBean.setBeanFactory runs first
org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.postProcessAfterInitialization runs next due to the bean being initialized with the aspect

Due the AOT compilation run the proxy generation follows the following sequence

org.springframework.context.aot.ApplicationContextAotGenerator causes org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.buildProxy to run -> writes DemoController$$SpringCGLIB$$0.class
org.springframework.context.aot.ApplicationContextAotGenerator causes org.springframework.cloud.context.scope.GenericScope$LockedScopedProxyFactoryBean.setBeanFactory to run -> writes DemoController$$SpringCGLIB$$1.class

During the AOT run (-Dspring.aot.enabled=true) the proxy generation seems to follow the normal sequence.

org.springframework.cloud.context.scope.GenericScope$LockedScopedProxyFactoryBean.setBeanFactory runs first and attempts to use DemoController$$SpringCGLIB$$0.class but the signature of the callbacks isn't correct as the correct one is in DemoController$$SpringCGLIB$$1.class and throws

I'm not entirely sure but I think that this can be fixed if org.springframework.cloud.context.scope.GenericScope implements org.springframework.beans.factory.config.SmartInstantiationAwareBeanPostProcessor.
https://github.com/spring-projects/spring-framework/blob/c9aba1eaad3ce0bcf68b09305a61d67c942d3660/spring-context/src/main/java/org/springframework/context/support/GenericApplicationContext.java#L421

same problem,  wait for update. AOT and native image support is not available

A more in-detail analysis based on the provided sample:
JVM runtime
As the context is being refreshed, configuration bean definition processing takes place, triggering scanning for candidates. As ContextAotProcessor runs performAotProcessing(...), ApplicationContextGenerator’s processAheadOfTime(...) method is called, in turn calling refreshForAotProcessing(...) on GenericApplicationContext. demoController is found, and since it has ScopedProxyMode.TARGET_CLASS, ScopedProxyCreator.createScopedProxy(...) is triggered.
While finishing BeanFactory initialisation, preInstanatiateSingletons() is called and, consequently, getSingleton(...) and createBean(...) methods for demoController. Since it’s a ScopedProxyFactoryBean, and therefore, BeanFactoryAware, setBeanFactory(...) is called on it, and setBeanFactory(...) in ScopedProxyFactoryBean finishes its execution with proxy creation. That’s when the CGLiB proxy with corresponding file indexed $$0 gets created.
Subsequently, finishRefresh() is called and ContextRefreshedEvent is published and RefreshScope is initialised, which includes context.getBean(...) being called for every bean within the scope, including scopedTarget.demoController. As the bean is post-processed during after initialisation by AbstractAutoProxyCreator, the aspect-specific interceptors are found, and the proxy creation is carried out through a call to createProxyClass(). That’s when the CGLIB proxy with corresponding file indexed $$1.
AOT processing
As ContextAotProcessor runs performAotProcessing(...), ApplicationContextGenerator’s processAheadOfTime(...) method is called, in turn calling refreshForAotProcessing(...) on GenericApplicationContext.
That triggers post-processing of BeanDefinitionRegistry and processing configuration classes, including scanning for candidates. demoController is found, and since it has ScopedProxyMode.TARGET_CLASS, ScopedProxyCreator.createScopedProxy(...) is triggered. targetBeanName is evaluated and scopedTarget.demoController bean definition is registered, and the bean definition for the proxied demoController bean is registered as well.
Up until here the order looks right.
As the last step within refreshForAotProcessing(...), predetermineBeanTypes(...) is called in determineBeanType() in AutoProxyCreator runs for scopedTarget.demoController. As part of this process, interceptors for that bean are searched with getAdvicesAndAdvisorsForBean(...) method, which recognises the existence of DemoControllerAspect. Since interceptors are found, the type determination will be done for proxy type, but in order to verify the relevant proxy type, actual proxy creation is attempted through a call to createProxyClass(). That’s when the CGLIB proxy with corresponding file indexed $$0, so this seems to be the root of the problem. (Maybe there would be a way to reason about the proxy type without finalising the proxy creation?)
Later on, the predetermineBeanTypes(...) execution reaches the demoController (without scopedTarget prefix) bean definition. getType(...) is called for that bean and, consequently, getSingleton(...) and createBean(...). Since it’s a ScopedProxyFactoryBean, and therefore, BeanFactoryAware, setBeanFactory(...) is called on it, and setBeanFactory(...) in ScopedProxyFactoryBean finishes its execution with proxy creation. That’s when the CGLiB proxy with corresponding file indexed $$1 gets created.
AOT-processed jar execution
This phase executes in an order akin to the one from a simple JVM runtime execution. As AotApplicationContextInitializer runs, both scopedTarget.demoController and demoController bean definitions are registered. While finishing BeanFactory initialisation, preInstanatiateSingletons() is called and, consequently, getSingleton(...) and createBean(...) for demoController. In keeping with the AOT generation run,  setBeanFactory(...) in ScopedProxyFactoryBean is called for the bean, triggering proxy creation. Since the proxy files are matched per class and then by index, and the proxy creation order for the DemoController class is different, wrong file gets picked (based on the order of processing during AOT generation, the corresponding one would be indexed $$1, but since $$0 has not yet been used during the execution, that one is picked), the callback types do not match the file and we get:
java.lang.ClassCastException: class org.springframework.aop.framework.CglibAopProxy$SerializableNoOp cannot be cast to class org.springframework.cglib.proxy.Dispatcher (org.springframework.aop.framework.CglibAopProxy$SerializableNoOp and org.springframework.cglib.proxy.Dispatcher are in unnamed module of loader org.springframework.boot.loader.launch.LaunchedClassLoader @6e2c634b)

This is not specifically related to Spring Cloud, but rather is a Framework issue. The same will happen if any other Scope with ScopedProxyMode.TARGET_CLASS is applied. Can be reproduced in the same demo with @ApplicationScope annotation used instead of @RefreshScope.

@justin-tay, I have further verified the issue. I will report the issue to the Framework team (see comments above for the details), however I also wonder about what your use case is here. As documented, we don't support refresh scope in any form for AOT-processed and native applications and you need to build and run them with spring.cloud.refresh.enabled set to false. On the other hand, if you attempt using a @RefreshScope-annotated bean with that prop disabled, the app will fail, since this has never been supported (independent of any AOT-specific changes). The only way you could use that app in a regular JVM runtime with spring.cloud.refresh.enabled=false is if you never call that @RefreshScope-annotated controller, so, in any case, it's not going to be a good practice (or very useful) to have @RefreshScope-annotated beans in any AOT-processed app.

Just to elaborate a bit on the scenario. There was a library that had some @AutoConfiguration that was creating beans that were annotated with  @RefreshScope. Separately there was another library contributing an aspect. My application was just using these two libraries as dependencies so it was difficult to remove the @RefreshScope other than by copying the @AutoConfiguration beans and removing the @RefreshScope as I didn't actually need the beans to be refreshable. It would just have been nice to have a means to continue using the @AutoConfiguration as is. In the end I managed to get changes merged into the upstream library to have two separate sets of configuration depending on whether spring.cloud.refresh.enabled was true or false.
Thanks for taking the time to look into this!

Related issue opened in Framework: https://github.com/spring-projects/spring-framework/issues/32669.


Update http4s-blaze-client, ... to 0.21.26

Updates

org.http4s:http4s-blaze-client
org.http4s:http4s-blaze-server
org.http4s:http4s-circe
org.http4s:http4s-dsl
org.http4s:http4s-server

from 0.21.14 to 0.21.26.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s" } ]

labels: library-update, semver-patch

Superseded by #538.


Wilsongp patch 1

Coverage remained the same at 100.0% when pulling fdacf405d1c5815e3d00ad42b2228161569334bf on wilsongp-patch-1 into 0d2bbadfea4fac3d1c73708e66a76a6e6e993849 on development.


Add code coverage tracking to e2e and backend tests

This should run as part of the github actions workflow. As part of this task we should also see whether it's straightforward to generate a test report - see comments on the first automated testing PR

Also warn if the coverage dropped, and fail if the coverage is below a threshold.


Polymorphism belongs to

Polymorphism belongs to
Hello, I try to have a polymorphic relation like that:
TicketMessage struct {
  SenderType     string    `json:"senderType"`
  SenderID       uuid.UUID `json:"senderId"`
  AccountSender  *Account  `json:"sender,omitempty" gorm:"polymorphic:Sender;polymorphicValue:account"`
  CustomerSender *Customer `json:"sender,omitempty" gorm:"polymorphic:Sender;polymorphicValue:customer"`
}

But it's not working. I've checked in the documentation, nothing is said to do that.
There is a way to do this?
Thank you.
The document you expected this should be explained
https://gorm.io/docs/belongs_to.html
GORM Playground Link
https://github.com/go-gorm/playground/pull/234

https://github.com/go-gorm/playground/pull/234

this is not supported, you could only use polymorphism has one

After few days thought, not going to support this, hard to support the preloading feature for this kind of relationship, maybe you should define it in polymorphism has one style

After few days thought, not going to support this, hard to support the preloading feature for this kind of relationship, maybe you should define it in polymorphism has one style

Im also looking for this functionality. instead of defining the polymorphic gorm attributes on the model without OwnerID and OwnerType I would like to  define this only on the model containing the OwnerID and OwnerType and not on the model it refers to.

@meruiden Did you find solution like this?


Add a new ruby version and alias to use it.

https://trello.com/c/1EEslr7W

:+1: Merge when ready.


Remove const_err lint

As of Rust 1.66 this produces:
warning: lint `const_err` has been removed: converted into hard error, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> for more information
 --> /mnt/devel/external/Rust/github.com/atsamd-rs/atsamd/pac/atsamd51p/src/lib.rs:3:9
  |
3 | #![deny(const_err)]
  |         ^^^^^^^^^
  |
  = note: `#[warn(renamed_and_removed_lints)]` on by default

The problem was fixed in svd2rust 0.27.0  but using 0.27 in update-pacs.sh  breaks everything, so this patch can be applied to remove the problem until the more general solution can be applied.
See #648.

@pabigot, did you happen to notice what the major problems were with the updated PACs? It would be nice to update. We should try not to fall too far behind.

@bradleyharden My recollection was I changed update-pacs.sh to use svd2rust 0.27.2 and builds produced cascading errors, though I can't replicate that now.
As of yesterday current svd2rust is at 0.28.0.  One point is that per the CHANGELOG MSRV for pacs would increase to 1.61 at 0.27.0.
I've tried builds in wio_terminal and feather_m0 using 0.28.0, which also required changing update-pac.sh svdrust --nightly to svdrust --atomics   I get conflicting definitions of CHANNEL as a struct and as a type in pac/atsmd51p/src/evsys/channel.rs, and use of unresolved import portable_atomic in atsamd/pac/atsamd21g/src/generic/atomic.rs which continues to produce errors after the package is added.
So it shouldn't be as bad as I thought, but there's some weirdness going on.

Hmm, ok. We should probably prioritize upgrading. If we continue to let it go, it will only get harder to catch up in the future. Maybe I'll take a look myself this week.

Also, we bumped the MSRV to 1.65 with the merge of #450, because it uses GATs, so that's not an issue.


Transcript output points user to incorrect log location

#45
Simple change so that the last output an end user sees points to the correct log location.

Merged, thank you!


Parsing callback SAML data

So i'm a little confused on how the callback function should look. Should the call back function be using the passport saml middleware? As pictured below and in your ReadMe?

or should the code be structured more like this?

The issue is -- i'm getting an error with the code in the first image (your provided example code) because the post request is attempting to send another authenticate saml request as I can see in my SAML browser plugin (with an invalid NameId of course), where as if i use the code in the second image, i can get a response back but the request isn't being parsed for me.. and I'm having to parse it myself in a very ugly manner.
Thanks in advance

I assume the error you see is the same one I see from the callback route as described in the first picture. The error is TypeError: Converting circular structure to JSON. Seems to be at at validateCallback (<project>/node_modules/passport-saml/lib/passport-saml/strategy.js:59:14).
At line 59 in strategy.js, we see the call self._verify(req, profile, verified);. There I lose the path of the logic.
Can I ask how you are parsing the request yourself? The project doesn't appear to be being maintained, yet we're stuck with it.


update docs how to use custom UI

Hello! 👋
I've spotted a small documentation bug, here is a PR to fix it!

Hi ! Why did you close it?


Handlebars gzip/base64 encoding support (to create proper chaise link to recordset)

Currently data modelers can use filter syntax for generating link to different pages in chaise. But our supported filter syntax is very simple and we require more. An improvement would be writing facet in the mustache/handlebars environment but since we're encoding the facet object that is not possible right now.  We have to define a new helper function in mustache/handlebars that given an object will return an encoded string which can be appended to the url.
As an improvement we can later add a name attribute to the current defined facet in the table. This way instead of spelling out the whole path, they can just refer to the existing facet and define a new filter for it.

A new handlebar helper block has been added.


Trying to run self-contained application on Ubuntu 22 (Linux-x64), error regarding libdl.so

Describe the bug
I'm getting this error when attempting to run an application I built with .NET 7, Terminal.Gui 1.10.1 targeting Ubuntu 22:
Unhandled exception. System.Exception: Curses failed to initialize, the exception is: Unable to load shared library 'libdl.so' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable.
   at Terminal.Gui.CursesDriver.Init(Action)
   at Terminal.Gui.Application.InternalInit(Func`1, ConsoleDriver , IMainLoopDriver , Boolean )
   at Terminal.Gui.Application.Init(ConsoleDriver , IMainLoopDriver )
   at Program.<Main>$(String[])
Aborted

After doing some research, I found this:
https://stackoverflow.com/a/75855054
I also know that v2 is being worked on, so I tried searching on Discussions and Issues for anything about libdl.so but didn't find anything so my apologies if this is already a known issue.
To Reproduce
Steps to reproduce the behavior:

Create a simple application using .NET 7 and Terminal.Gui 1.10.1
Publish as a single file, self-contained application targeting linux-x64
chmod +x, attempt to run the application on Ubuntu 22

Expected behavior
The application should run, displaying the simple application
Desktop (please complete the following information):

OS: Ubuntu 22.04.2 LTS

Hi thanks for reaching out for support on this.  Please can you try running the following:
dotnet new --install Terminal.Gui.templates
dotnet new tui -n myproj
cd myproj
sed -i 's/net6.0/net7.0/g' ./myproj.csproj
dotnet publish -r linux-x64 --self-contained
cd ./bin/Debug/net7.0/linux-x64/publish/
./myproj

Interesting! Ok that seemed to work (I did the commands you suggested on my Ubuntu box, had to install .NET 7 first).
I tried running my application again (which was built on Windows 11 btw, but trying to run on Ubuntu) and I got the same error. Do I need to run that sed command on my project and/or build it on Ubuntu instead of Windows?

Running an assembly compiled on Windows should work on Linux.

Running an assembly compiled on Windows should work on Linux.

That is true for dll but I don't think the same applies when compiling self contained executable.

Running an assembly compiled on Windows should work on Linux.

Yes you are right, but we need to change the directive #if NET7_0 every time the project version is changed. Since this is at compile time, I don't know if this can be made programmatically when the project version is changed.

@HoofedEar with the change in the PR #2600 you can now compile in Windows and run in the Linux.

Ok so I did some testing:

Publishing on Windows, targeting linux-x64 (self-contained, produce single-file) and moving it to Ubuntu: running produces the libdl.so exception
Publishing on Ubuntu like this dotnet publish -r linux-x64 -p:PublishSingleFile=true --self-contained also produces the error

So I think the single-file setting is the problem? I'd really like to be able to build my application as a single-file executable, but if that's not possible that's alright

Did you used the PR branch?

Confirmed that #2607 fixed it 👍
Just tested by building on Windows, targeting Linux-x64 (single file, self contained)
(I used my local repo of Terminal.Gui as a reference instead of the Nuget package)
Thanks for your help with this everyone :grin:

I know that the issue above was closed long time ago, but I struggled over something that is directly releated to this change. I've built a self-contained linux application with Terminal-Gui 1.17.0. My application was using .NET 8 framework.
In my logs I've seen the "Unable to load shared library 'libdl.so' or one of its dependencies." message.
After some redings here I set the .NET framework down to .NET 7. Then everything worked as expected.
Is it possble that the fix for self contained applications on Linux is only applied in .NET 7 version (#if NET7_0)? Why is this not required for .NET6 and .NET8?

@AdrianEggenberger I cannot repro this. Can you give more information, please? I created a self-contained project with ne80 and I haven't this issue.

I've created a simple .NET8 console project with exactly the demo code from the "Getting Started" page.

Open project in configuration Release
Build the project
Select Publish and create the standalone application for linux-arm64:

Configuration: Release|Any CPU
Target framework: net8.0
Deployment mode: Self-contained
Target runtime: linux-arm64

Copy the built application to a Raspberry Pi 5 with latest Ubuntu
Configure the application as executable
Run the application

In my case it ends in the following error:
raspberry@raspberrypi:~/terminal-gui $ ./TerminalGuiApp
Unhandled exception. System.Exception: Curses failed to initialize, the exception is: Unable to load shared library 'libdl.so' or one of its dependencies. In order to help diagnose loading problems, consider using a tool like strace. If you're using glibc, consider setting the LD_DEBUG environment variable:
/home/raspberry/terminal-gui/libdl.so: cannot open shared object file: No such file or directory
/home/raspberry/terminal-gui/liblibdl.so: cannot open shared object file: No such file or directory
/home/raspberry/terminal-gui/libdl.so.so: cannot open shared object file: No such file or directory
/home/raspberry/terminal-gui/liblibdl.so.so: cannot open shared object file: No such file or directory
at Terminal.Gui.CursesDriver.Init(Action terminalResized)
at Terminal.Gui.Application.InternalInit(Func1 topLevelFactory, ConsoleDriver driver, IMainLoopDriver mainLoopDriver, Boolean calledViaRunT)    at Terminal.Gui.Application.Run[T](Func2 errorHandler, ConsoleDriver driver, IMainLoopDriver mainLoopDriver)
at Program.$(String[] args) in C:\TerminalGuiApp\Program.cs:line 5
Aborted
TerminalGuiApp.zip

V1 is not trim-friendly, which will cause problems with single-file deployments, for sure.
V2 is not trim-friendly, yet, but it is a goal, currently, for release.
Note that self-contained applications, single-file or not, do not automatically pull in runtime dependencies for PInvoke, and rely on the platform to figure it out.
Using the workaround in the exception is not something that should be done on a production system, since it is globally impacting for the whole system and can present a security problem if done improperly.
Just to check if it's a loader issue, can you grab a copy of those libs from /lib and place them in the directory the self-contained app is being published to? If that's all it is (likely), we can address it on the TG side.

I don't have a raspberry. Does exist another way to test it?

Ok, I was able to reproduce it. I was using debug instead of release, sorry. The solution is to add current versions and eliminate previous versions.

@AdrianEggenberger please test with the PR #3562 and check if that fixes the issue. Thanks.

Also, @BDisp, replacing DllImports with LibraryImports may help, as well as makes the PInvokes trim-friendly.
However, the conditional compile symbols in the PR don't fix it for people unless they build Terminal.Gui from source. Pre-built code, such as the nuget package, only get the effect of how it compiles on the system it is built on.

I checked with the change from PR 3562 and it fixes the issues with target framework "net8.0" In my opinion using "NET6_0_OR_GREATER" would be the right way.
While the above fixes the issue for ,NET8 it is still an issue for .NET6. As the library is not provided for "net6.0" it falls back on the .NET standard variant that doesn't have the fix from above as there NET6_0_OR_GREATER is not set.

Well yes - whichever moniker has the necessary changes. My note was just following from the code already there, as a safe mention without having to load it up and test others with material changes like that. 😅
While I think the decision was made at some point not to support .net 6 any more, at least explicitly, using that preprocessor symbol there seems like a harmless bit of compatibility, to me, so long as we're clear we're not condoning the unsupported use - just not being hostile to it.
I kinda want to clean up some of the v1 PInvoke code anyway, more than just band-aids like this, even though we're just "maintaining" it now. Some pretty good changes wouldn't even require that much work and bring multiple benefits. And with a polyfill generator for the OS platform support stuff that didn't come til after netstandard2.0, even more cleanup is possible with very little work performed by humans.

And that sort of thing is a good place to drop a [ComponentGuarantees(ComponentGuaranteesOptions.None)], too, in the old version at least.

I checked with the change from PR 3562 and it fixes the issues with target framework "net8.0" In my opinion using "NET6_0_OR_GREATER" would be the right way.
While the above fixes the issue for ,NET8 it is still an issue for .NET6. As the library is not provided for "net6.0" it falls back on the .NET standard variant that doesn't have the fix from above as there NET6_0_OR_GREATER is not set.

To support net6.0 Terminal.Gui will also have to target net6.0, otherwise it will not work. My opinion is to actually add net6.0 to Terminal.Gui.csproj because it is a version that is still supported (LTS) unlike net7.0 which is already out of support (STS), as you can see in the image below.

That shouldn't usually be the case. netstandard2.0 ensures compatibility with .net framework 4.6.2 and up, as well as all versions of .net (core).
The fallback behavior if an exact SDK match can't be made (like .net6.0 target for the consumer's build, but net6.0 not defined in the TG TFMs) depends on the project configuration and the requirements of the whole build, including other dependencies' transient requirements. The default fallback is to use the lowest common framework (which can be changed in the project file and nuget config). In the case of someone trying to build against .net6.0, if something they use targets .net framework 4.8, netstandard 1.3, and netstandard2.0, they should get the lowest declared netstandard TFM of that dependency, unless they override it either in the PackageReference or the nuget config.
It's kind of a mess, honestly, and largely out of our hands.
But so long as consumers understand V1 is maintenance mode and V2 requires .net8.0, it's IMO harmless for us to add specific targets that don't require code changes and that don't alter package version resolution for existing cases....which is kind of a pain to try to test. 😞

Hey - this gave me an idea just now...
Ok, so, this is meant for after V2 stable release is out there.
What if we put in an [Obsolete("Terminal.Gui V1 is deprecated. For applications targeting .net8.0 and up, please consider migrating to Terminal.Gui V2.")] or something like that on the Application class and its members, in the V1 code?

Oops. Forgot to mention.
Inside a conditional for the NET8_0_OR_GREATER symbol, so it only shows up to people trying to use .net8 and up.

On the V1 self-contained is working fine with net60 or greater. Only on the V2 it isn't.

There's so much that changed between 5 and 6 in so many places of .net it's crazy.
And from 6 to 7.
And from 7 to 8.
😅
The defaults changes like the trim being opt-out now instead of opt-in are the ones that usually bite me, and sometimes more than once, since it's usually to something that only affects like...2 projects, in one specific configuration for each one, that is only ever used like twice a year. 😆
Ah well... Progress...

Good point! 😆


Search input box placeholder is hardwired to "cell type search"

The placeholder text always says "cell type search", regardless of the ontology being displayed.
Perhaps it should say "search ontology" or something like that?

Closed in #81


Add support for Azure Cosmos DB

Terraform resources: azurerm_cosmosdb* (there are around 12 resources) but they all have the same pricing model mentioned in https://azure.microsoft.com/en-us/pricing/details/cosmos-db/#pricing so we can probably use the same logic between those resources

@alikhajeh1, Hey, I want to work on it

@alikhajeh1, Hey, I want to work on it!

@ekifel the master branch test logs are showing this, can you please check?
time="2021-05-26T17:14:14Z" level=warning msg="Multiple products found for azurerm_cosmosdb_cassandra_keyspace.serverless Provisioned throughput (serverless), using the first product"


Feature/documentation foundation

First part of implementation of the documentation foundation. Contains documention and repository classes.  And a number of interfaces required for the documentgroups.

Absolutely nothing exciting found during the code review; only a few DocBlock comments and one instance where I think that a more specific Exception would be nice.
In other words: excellent work!

@jaapio I just noticed: composer install fails to function on wercker; is there an issue with the dependencies?

All done, ready for merge

:+1: No further comments!