Run Knex migration agains ATP instance

Environment
Knex version: 0.16.3
OS:  oraclelinux ( docker Image )
Database + version: Oracle ATP - Oracle Database 19c Enterprise Edition Release <IP_ADDRESS>.0 - Production
Issue
I am working on a container based application. And I want to launch migration scripts against my Oracle ATP.
I used to use this configuration to target a local Oracle Db container

knex.js

var knex = {
  development: {
    client: 'oracledb',
    connection: {
      user: process.env.user,
      password: process.env.password,
      database: process.env.database,
      host: process.env.host
    },
    pool: {
      min: 2,
      max: 6,
      createTimeoutMillis: 3000,
      acquireTimeoutMillis: 30000,
      idleTimeoutMillis: 30000,
      reapIntervalMillis: 1000,
      createRetryIntervalMillis: 100,
      propagateCreateError: false // <- default is true, set to false
    },
    debug: false,
    migrations: {
      directory: 'migrations'
    }
  }
};

module.exports = knex;

package.json

{
    "name": "oracle-migration",
    "version": "1.0.0",
    "description": "",
    "main": "knex.js",
    "scripts": {
      "test": "echo \"Error: no test specified\" && exit 1"
    },
    "dependencies": {
      "knex": "0.16.3",
      "oracledb": "3.1.1",
      "sails-migrations": "^2.1.0"
    },
    "author": "",
    "license": "ISC"
}

And I want to modify knex.js file to fit the Oracle ATP as well.
Any ideas ? FYI @atiertant , thanks in advance

Can you explain your need with more details? The way this script works, you are simply loading all connection details from environment variables. If you put credentials for your Oracle ATP in env variables, if ATP is API-compatible with Oracle database, that should just work.

Actually I want to target ATP and install schema using knex-js.
I found in the documentation , that I shall use the Easy Connect string, something like :

knex.js

connection = await oracledb.getConnection({
  user: "scott",
  password: mypw,  // mypw contains the scott schema password
  connectString: "cjdb1_high"
});

in which connectString is equal to :
protocol://host:port/service_name?wallet_location=/my/dir&retry_count=N&retry_delay=N
The issue that I have is that connectString is not a knexjs attribute so I won't  be able to use it.

ps: the application is internal and my ATP instance is in private network

propagateCreateError: false // <- default is true, set to false !! THIS IS WRONG !!

Where did you get this tip? Would be great to know the source, since this should not be done. Knex is designed to work when that is set true.
I've tried to comment everywhere in internet, where people is doing this, but it still pops out regularly 😢


perf(solc): enable sha2 asm for checksum speed

this pr might've broke the WASM build.
error: failed to run custom build command for `sha2-asm v0.6.2`

Caused by:
  process didn't exit successfully: `/ethers-rs/examples/ethers-wasm/target/release/build/sha2-asm-5c8d503edc62a6d4/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'Unsupported target architecture', /.cargo/registry/src/github.com-1ecc6299db9ec823/sha2-asm-0.6.2/build.rs:19:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

You're right, but I wonder why does https://github.com/gakonst/ethers-rs/pull/626 not fix it?


Feature: Bundled custom jinja filters and tests

Would be nice to have an option to provide custom filters and tests to templates (see docs) and better yet to bundle them with report and be able to use them even with zipreport debug.
Right now I don't see a way to provide filters/tests other than subclassing zipreport.template.JinjaRender and overriding get_env(), which is not what I can do with a wrapper around cli tool, or updating jinja2.filters.FILTERS/jinja2.tests.TESTS by reference, which seems hacky to me.
I've seen docs mentioning way to provide filters through jinja_options, but I don't see how that can work given that jinja2.Environment does not accept filters on init and requires to change Environment.filters afterwards. This also will not work for zipreport debug, which is an important flaw IMO.
Ideally I would like to put filters into a file like filters.py, tests to tests.py, maybe reference them in the manifest. Have them loaded with importlib & inspect and added to jinja's Environment.filters before report compilation. Additionally, it would be nice to provide jinja extensions to zipreport debug somehow, maybe mention them in manifest too.
Proposed approach opens up a way for ACE, but I don't think running untrusted templates is a good idea anyway. Maybe this could also help with issues preventing dynamic image loading.

You can easily register your own filters by registering them in the dict jinja2.defaults.DEFAULT_FILTERS, which is the global filter registry. This is the way zipreport registers its own image rendering filters.
I don't really see any advantage on using environments, as filters are often application-specific and the templates are (or should be) trusted "code". Environment filters in jinja2 start by being  a deepcopy of DEFAULT_FILTERS, so any system-wide filters will be available to your specific template. I think the most common usage scenario for environments is to provide module-specific functionality within a global web template, not when you''re creating on demand rendering contexts. Obviously my stance comes from my use cases, so yours may be different :) Can you please give me a bit more context on your specific use case? I can evaluate adding optional environment support to the rendering pipeline.
One thing to note is that there is nothing python-specific within the pdf generation engine. You can easily run python code inside a template if you really want (last case scenario, a filter function can run arbitrary python code), but that is often frowned upon, even in python :)

My usecase is stateless FastAPI that serves different reports on demand: it accepts a template name and corresponding report data, then prints that specific parametrized report. I have not yet dabbled with async calls to zipreport, but relying on jinja2 global default will surely force me to separate zipreport to a different process, or otherwise I will have cross-contamination of filters.

You can easily register your own filters by registering them in the dict jinja2.defaults.DEFAULT_FILTERS, which is the global filter registry. This is the way zipreport registers its own image rendering filters.

My biggest problem with this is I don't really see a clean way to use filters with "zipreport debug", without subclassing original code and having to rely on implementation details since I have to keep the same python interpreter running.

My usecase is stateless FastAPI that serves different reports on demand: it accepts a template name and corresponding report data, then prints that specific parametrized report. I have not yet dabbled with async calls to zipreport (...)

zipreport is not thread-safe, but if you are instancing per call this shouldn't be a problem. But I get your problem, you want a way to pack filters with the templates, so you can use them "on-demand".

My biggest problem with this is I don't really see a clean way to use filters with "zipreport debug", without subclassing original code and having to rely on implementation details since I have to keep the same python interpreter running.

true, and you are right, it is an oversight. Let me ponder possible solutions and get back to you :)

Hi,
Just built a new zipreport version, 2.2.0, that implements support for a custom wrapper class for Jinja2 Environment(). It allows for complete customization of the Environment object before rendering a report. The documentation isn't updated yet, but please have a look at the following examples:
https://github.com/zipreport/zipreport/blob/master/examples/code/custom_filter_example/main.py
https://github.com/zipreport/zipreport/tree/master/examples/reports/env_wrapper
They also include a zipreport debug example using a custom wrapper file. Please let me know of any problems you may find, and if this alleviates some of the mentioned problems.

Closing issue, if further help required on this topic, please create a new issue :)


HBASE-26703 Allow configuration of IPC queue balancer

Since RandomQueueBalancer is now just the default option of a new config, I thought it might make sense to split it and QueueBalancer out into top-level classes. Let me know if anyone disagrees with the IA/IS chosen here.
This change is covered by tests in TestSimpleRpcScheduler, but I also added an explicit test for the slicing of lists done in RWQueueRpcExecutor.
I want to pass in the actual queues to the balancer factory because some balancers may want to introspect the queues in determining how to balance. For example, a load-based balancer might want to check the size() to determine the least-loaded queue.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 28s
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 _

+1 :green_heart:
mvninstall
4m 13s
master passed

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

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

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

_ Patch Compile Tests _

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

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

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

-1 :x:
shadedjars
6m 37s
patch has 10 errors when building our shaded downstream artifacts.

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

_ Other Tests _

-1 :x:
unit
8m 19s
hbase-server in the patch failed.

37m 27s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 9c52789fd431 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 46a59e519e

Default Java
AdoptOpenJDK-1.8.0_282-b08

shadedjars
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-4063/1/artifact/yetus-jdk8-hadoop3-check/output/patch-shadedjars.txt

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

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.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 28s
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 _

+1 :green_heart:
mvninstall
5m 54s
master passed

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

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

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

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
5m 24s
the patch passed

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

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

-1 :x:
shadedjars
8m  8s
patch has 10 errors when building our shaded downstream artifacts.

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

_ Other Tests _

-1 :x:
unit
10m 59s
hbase-server in the patch failed.

46m 42s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 722f6a84d2fb 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 46a59e519e

Default Java
AdoptOpenJDK-11.0.10+9

shadedjars
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-4063/1/artifact/yetus-jdk11-hadoop3-check/output/patch-shadedjars.txt

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

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.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
9m 43s
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 _

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

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

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

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

_ Patch Compile Tests _

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

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

+1 :green_heart:
javac
3m 49s
the patch passed

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

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

+1 :green_heart:
hadoopcheck
25m 47s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

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

_ Other Tests _

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

63m 16s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 95a1126492d6 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 46a59e519e

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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
1m  9s
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 _

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

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

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

+1 :green_heart:
spotbugs
1m 13s
master passed

_ Patch Compile Tests _

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

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

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

-0 :warning:
checkstyle
0m 33s
hbase-server: The patch generated 7 new + 13 unchanged - 6 fixed = 20 total (was 19)

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

+1 :green_heart:
hadoopcheck
11m 37s
Patch does not cause any errors with Hadoop 3.1.2 3.2.2 3.3.1.

+1 :green_heart:
spotbugs
1m 16s
the patch passed

_ Other Tests _

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

29m 45s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux a81c800d33b3 5.4.0-1025-aws #25~18.04.1-Ubuntu SMP Fri Sep 11 12:03:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8dec499181

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

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
1m 14s
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 _

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

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

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

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

_ Patch Compile Tests _

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

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

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

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

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

_ Other Tests _

-1 :x:
unit
348m 18s
hbase-server in the patch failed.

370m  0s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 3fca8b590833 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 8dec499181

Default Java
AdoptOpenJDK-1.8.0_282-b08

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4063/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-4063/1/testReport/

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

modules
C: hbase-server U: hbase-server

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

versions
git=2.17.1 maven=3.6.3

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

This message was automatically generated.

The test failure here looks like a flakey test timeout. I can try a force push to kick it off again, but probably safe to merge?

It seems fine. Let's try master and branch-2 for now.


Add CallOrCreateInfo to ValidatedTransaction apply result.

Closes #1097

Please rebase.

Finished. Please have a look.


rospack: 2.5.1-0 in 'lunar/distribution.yaml' [bloom]

Increasing version of package(s) in repository rospack to 2.5.1-0:

upstream repository: https://github.com/ros/rospack.git
release repository: https://github.com/ros-gbp/rospack-release.git
distro file: lunar/distribution.yaml
bloom version: 0.6.6
previous version for package: 2.5.0-0

rospack
* add run_depend on ros_environment (#88 <https://github.com/ros/rospack/issues/88>)

holding for synchronized release..


EfsCsiDriverAddOn: When using a namespace it fails with "Error from server (NotFound): error when creating "/tmp/manifest.yaml": namespaces "XXXX" not found\n'

Describe the bug
When trying to add a namespace to EfsCsiDriverAddOn({namespace: nameSpace}) it fails with the following error:
from custom resource. Message returned: Error: b'Error from server (NotFound):
error when creating "/tmp/manifest.yaml": namespaces "XXXX" not found\n'

To try to fix this I added a Team with the namespace "XXXX"
const teamUepe = new blueprints.PlatformTeam({ name: nameSpace });
Then add the team before addons:
            .teams(teamUepe)
            .addOns(...addOns)

Still getting the same error.
Expected Behavior
EfsCsiDriverAddOn should be created after the namespace is created or add support for createNamespace: true
Current Behavior
Fails with error message as seen above
Reproduction Steps
        const teamUepe = new blueprints.PlatformTeam({ name: nameSpace });
...
       const addOns: Array<blueprints.ClusterAddOn> = [
            new blueprints.addons.SSMAgentAddOn,
            new blueprints.addons.ClusterAutoScalerAddOn,
            new blueprints.addons.EfsCsiDriverAddOn({ namespace: nameSpace, kmsKeys: [kmsEfsKey] }),
            new blueprints.addons.AwsLoadBalancerControllerAddOn({
                namespace: nameSpace,
            }),
            new blueprints.addons.ExternalDnsAddOn({
                namespace: nameSpace,
                hostedZoneResources: [blueprints.GlobalResources.HostedZone]
            }),
            new blueprints.addons.CertManagerAddOn({ installCRDs: true }),
            new blueprints.addons.ExternalsSecretsAddOn(),
            new blueprints.addons.SecretsStoreAddOn(),
            new blueprints.addons.IngressNginxAddOn(ingressNginxProps),
        ];
const stack = blueprints.EksBlueprint.builder()
            .version(KubernetesVersion.V1_30)
            .account(this.account)
            .region(this.region)
            .clusterProvider(clusterProvider)
            .resourceProvider(blueprints.GlobalResources.Vpc, new blueprints.VpcProvider(undefined, { primaryCidr: envContext.vpcCidr }))
            .resourceProvider(blueprints.GlobalResources.HostedZone, new blueprints.ImportHostedZoneProvider(hostedZone.hostedZoneId, hostedZoneName))
            .resourceProvider(blueprints.GlobalResources.Certificate, new blueprints.CreateCertificateProvider('secure-ingress-cert', `*.${hostedZone.zoneName}`, blueprints.GlobalResources.HostedZone))
            .resourceProvider(kmsEfsKeyName, new blueprints.CreateKmsKeyProvider(kmsEfsKeyName))
            .resourceProvider('uepe-efs', new blueprints.CreateEfsFileSystemProvider({
                name: envContext.efsName,
                kmsKeyResourceName: kmsEfsKeyName,
                efsProps: {
                    encrypted: true,
                    lifecyclePolicy: efs.LifecyclePolicy.AFTER_7_DAYS,
                    removalPolicy: RemovalPolicy.DESTROY,
                    throughputMode: efs.ThroughputMode.BURSTING,
                    fileSystemPolicy: eksFileSystemPolicy,
                },
            }))
            .teams(teamUepe)
            .addOns(...addOns)
            .build(this, 'eks-blueprints');

Possible Solution
EfsCsiDriverAddOn should be created after the namespace is created in or add support for createNamespace: true
Additional Information/Context
No response
CDK CLI Version
2.156.0 ("aws-cdk-lib": "2.147.3")
EKS Blueprints Version
1.15.1
Node.js Version
v22.8.0
Environment details (OS name and version, etc.)
MacOs Sequoia 15.0
Other information
No response

When digging in the Lambda logs I did find this create request that is related to the error:

{
    "RequestType": "Create",
    "ServiceToken": "arn:aws:lambda:us-east-1:xxx:function:EksUepeStackuepeeks1FE415-ProviderframeworkonEvent-0BukR7bjwpgv",
    "ResponseURL": "...",
    "StackId": "arn:aws:cloudformation:us-east-1:xxx:stack/EksUepeStackuepeeks1FE4154B/185aea00-764f-11ef-b109-0e04891abfad",
    "RequestId": "bd2952a9-043a-4155-8161-48e55b06ffb3",
    "LogicalResourceId": "uepeeksefscsicontrollersamanifestefscsicontrollersaServiceAccountResourceF3B501C0",
    "ResourceType": "Custom::AWSCDK-EKS-KubernetesResource",
    "ResourceProperties": {
        "ServiceToken": "arn:aws:lambda:us-east-1:xxx:function:EksUepeStackuepeeks1FE415-ProviderframeworkonEvent-0BukR7bjwpgv",
        "PruneLabel": "aws.cdk.eks/prune-c8f7f1aa13d9beee65d83d39aea548228bf9faadef",
        "ClusterName": "uepe-eks",
        "Manifest": "[{\"apiVersion\":\"v1\",\"kind\":\"ServiceAccount\",\"metadata\":{\"name\":\"efs-csi-controller-sa\",\"namespace\":\"XXX\",\"labels\":{\"aws.cdk.eks/prune-c8f7f1aa13d9beee65d83d39aea548228bf9faadef\":\"\",\"app.kubernetes.io/name\":\"efs-csi-controller-sa\"},\"annotations\":{\"eks.amazonaws.com/role-arn\":\"arn:aws:iam::xxx:role/EksUepeStackuepeeks1FE415-uepeeksefscsicontrollersa-1Lp0t66HvgLq\"}}}]",
        "RoleArn": "arn:aws:iam::xxx:role/EksUepeStackuepeeks1FE415-uepeeksCreationRole088278-GOyKG17AEzI0"
    }
}

I think this is some timing issue. Seemingly randomly I get this error when trying to use another namespace than the default one for several add-ons.
I have got the issue here:
AwsLoadBalancerControllerAddOn({namespace: nameSpace})

This seems to be a timing issue. When I run the cdk deploy again it usually works.
What can be done to wait or guarantee that the namespace is created before it is used by Addon?

@jesperalmstrom
You used a team construct to create namespace, then you used addon with that namespace.
The current architecture is such that dependency graph is going unidirectionally from teams to addons, not the other way around.
To create a separate namespace for the efs addon you will need to create a separate tiny addon to just create the namespace. The addon needs to be annotated with @Reflect.metadata("ordered", true) and be registered before the efscsi driver addon.
Pseudo code:
@Reflect.metadata("ordered", true)
@supportsX86
export class MyNamespaceAddOn implements ClusterAddOn {

  deploy(clusterInfo: ClusterInfo): Promise<Construct> {
        const cluster = clusterInfo.cluster;
        return createNamespace(myNamespaceName, cluster);
   }
}

I would still keep this open as efs driver should be able to support createNamespace flag like we do elsewhere.

I will try this, i have my doubts since the reason that i added teams() in the first place was because my interpretation of the error i got was that create NS was not supported.

I have tested now without the .teams(nameSpace) and still get the same issue (just before the error in CW log):
...
"ResourceProperties": {
        "ServiceToken": "arn:aws:lambda:us-east-1:211125531019:function:testEksStack-ProviderframeworkonEvent-uYCAE3ipZRup",
        "PruneLabel": "aws.cdk.eks/prune-c8deef32ebxxxx",
        "ClusterName": "test",
        "Manifest": "[{\"apiVersion\":\"v1\",\"kind\":\"ServiceAccount\",\"metadata\":{\"name\":\"efs-csi-controller-sa\",\"namespace\":\"XXXX\",\"labels\":{\"aws.cdk.eks/prune-xxxx\":\"\",\"app.kubernetes.io/name\":\"efs-csi-controller-sa\"},\"annotations\":{\"eks.amazonaws.com/role-arn\":\"arn:aws:iam::211125531019:role/testEksStack-B9y\"}}}]",
...

Error message:
[ERROR] Exception: b'Error from server (NotFound): error when creating "/tmp/manifest.yaml": namespaces "XXX" not found\n'
Traceback (most recent call last):
  File "/var/task/index.py", line 14, in handler
    return apply_handler(event, context)
  File "/var/task/apply/__init__.py", line 64, in apply_handler
    kubectl('create', manifest_file, *kubectl_opts)
  File "/var/task/apply/__init__.py", line 91, in kubectl
    raise Exception(output)

After adding the NameServerAddOn() suggested by you @shapirov103 (thanks again) I managed to deploy the stack.
My conclusion is that EFS Driver AddOn does not have a working logic for createNamespace

@jesperalmstrom You are correct, the createNamespace logic is missing from the EFS addon as by default the addon is installed in kube-system. Let's keep it open to address the issue.

@shapirov103 i have my suspicions that the AwsLoadBalancerControllerAddOn() could have the same issue.


Cwe 158192 jenkins operations plugin ispw/ git   sync failure messages cleanupmessagefromcliandjenkins

Make a mssage change

wrong pull request. original project has been fored into jenkinsci.


schedule: add options to disable replica checker features

What have you changed? (required)
Add 5 new options to turn on/off features of replicaChecker:

disable-remove-down-replica
disable-make-up-offline-replica
disable-make-up-replica
disable-remove-extra-replica
disable-location-replacement

What are the type of the changes (required)?

Improvement (non-breaking change which is an improvement to an existing feature)

How has this PR been tested (required)?

unit tests
make sure it works on a local cluster

Does this PR affect documentation (docs/docs-cn) update? (optional)
https://github.com/pingcap/docs-cn/pull/796
Refer to a related PR or issue link (optional)
Benchmark result if necessary (optional)
Add a few positive/negative examples (optional)

why need to do this change?

PTAL @nolouch


Update create-upload-centos.md

Removed additionally spaces in CentOS 7 repository configuration. The additionally space was getting copied into the repository file and prevent it from working

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

@Ajithkumar2018 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Verified the updates; merging.
@Ajithkumar2018 Thanks for your contribution.


Removed react-css-themr from the components

We decided to remove react-css-themr, because we don't need it (our designers promised us) and it was only adding extra complexity.

Yes indeed, this will be bumped to a different minor version. But I will do this in a separate PR, once we will actually publish. It's not really a part of this PR imo.


Ability to display complicated markers on the map

Hi team,
Can you suggest me ways to apply markers ReactNodes or complicated svg elements? I attached the image below as an example. Thank you so much!

If you would like to upvote the priority of this issue, please comment below or react on the original post above with :+1: so we can see what is popular when we triage.
@pieliedie Thank you for opening this issue. 🙏
Please check out these other resources that might help you get to a resolution in the meantime:

Check the issue tracker - bugs and feature requests for Google Maps Platform APIs and SDKs
Open a support case - Get 1:1 support in Cloud Console.
Discord - chat with other developers
StackOverflow - use the google-maps tag

This is an automated message, feel free to ignore.

This sort off marker can be created using the AdvancedMarkerElement (See also: https://developers.google.com/maps/documentation/javascript/advanced-markers/overview) or using a custom OverlayView (this looks like it might work for you: https://dawchihliou.github.io/articles/building-custom-google-maps-marker-react-component-like-airbnb-in-nextjs).
Closing this as it has nothing to do with the react-wrapper library or it's functionality.


Ruby version bundler sees is not the version rvm and Gemfile recognizes so bundle install fails

What is happening when I run bundle install:  Error Message when trying to run bundle install under the application user account:
     Your Ruby version is 1.9.3, but your Gemfile specified 2.1.3

What I expect: Bundler will recognize that my version number that was set by RVM is 2.1.3 and continue installing my gems.
I do not have version 1.9.3 installed on my system.  When I run $ruby -v it does show 2.1.3p242.  Also when I run $rvm info it shows that only 2.1.3 is the only version installed.  In trying to track this down I found an issue with versioning of bundler first.  On my admin account where I did my first installed bundler it downloaded and recognizes that I have version 1.10.6.  However when I type $bundler -v on my user account it shows that an old version (1.7.3) is there (wondering if it was installed at the same time the OS was, which is Ubuntu 14.04 server).  I ran gem install bundler under the application user account it successfully installed version 1.10.6 again.  However it still only recognizes 1.7.3 when I type bundler -v again.  I tried to uninstall the 1.7.3 version but I am getting the message that it is not installed.
Here is my Gemfile content:
source 'http://rubygems.org'
ruby '2.1.3'

#ruby-gemset=pfinder

gem 'rails', '4.2.0.beta2'
gem 'arel', '6.0.0.beta2'
gem 'sass-rails', '5.0.0.beta1'
gem 'bootstrap-sass', '<IP_ADDRESS>'
gem 'sprockets', '2.12.2'
gem 'bcrypt', '3.1.7'
gem 'faker', '1.4.2'
gem 'will_paginate', '3.0.7'
gem 'bootstrap-will_paginate', '0.0.10'
gem 'mini_portile', '0.6.0'
gem 'uglifier', '2.5.3'
gem 'coffee-rails', '4.0.1'
gem 'jquery-rails', '3.1.2'
gem 'turbolinks', '2.3.0'
gem 'jbuilder', '2.1.3'
gem 'rails-html-sanitizer', '1.0.1'
gem 'sdoc', '0.4.0', group: :doc
gem 'yaml_db'
gem 'json'
gem 'elasticsearch-model', git: 'git://github.com/elasticsearch/elasticsearch-rails.git'
gem 'elasticsearch-rails', git: 'git://github.com/elasticsearch/elasticsearch-rails.git'
gem 'mysql2', '0.3.18'
gem 'passenger', '5.0.16'

group :development do
        gem 'mysql2', '0.3.18'
        gem 'byebug', '3.4.0'
        gem 'web-console', '2.0.0.beta3'
        gem 'spring', '1.1.3'
end

group :test do
        gem 'minitest-reporters', '1.0.5'
        gem 'mini_backtrace', '0.1.3'
        gem 'guard-minitest', '2.3.1'
end

Thanks,
Kris

Hi, sorry for the late reply. You seem to have issues with RVM, which is a Ruby version manager completely separate from "rbenv". It would seem that you've opened the issue in the wrong project.
With rbenv, you would have to ensure that your project is configured locally to use a Ruby version that matches the one specified in your Gemfile. To do that, you would use:
$ rbenv local 2.1.3

That writes out a .ruby-version file in your project that configures the version manager to always use Ruby 2.1.3 for your project.


Print readable error message when check critical cfg

Em, I prefer returning error ASAP and then panic plus the message remove last_tikv.toml.

I prefer print all changed critical configration at one time. Otherwise if user only fix the first and remove last_tikv.toml, we can't check any more critical changes.

LGTM

Any updates?

/bench


Allow users to rename Zones

Resolves #194
Review along with #196 which resolves #195
TODO:

[x] Don't allow a user to rename a Zone to "Screen"

Feedback on whether this is intuitive enough would be appreciated

That's a reasonable suggestion. Would you have the name still double-clickable when not explicitly editing the Zone?

I don't think that's necessary. Having to press the pencil to edit the zone makes sense to me.

Deleting a zone still causes a visual artifact:

@velovix should we make the dark theme pencil icon consistent in this PR before merge, or in another PR?

Issue with duplicated Alarm widgets should be resolved now

@BryceBeagle Yeah I'll give it a little bit of a fix

Okay, the "shine" of the pencil should now be transparent instead of white.


Login id types

connect #1150
TODO and WIP:

refactor password provider to have store layer, so we can mock the store and add test to the provider
detect confusing homoglyphs for username

All comments should be addressed, please take a look when you have time. Thanks @louischan-oursky


YETUS-755. bundler is breaking dockerfile building

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/yetus-github-multibranch/job/PR-36/1/console in case of problems.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/yetus-github-multibranch/job/PR-36/2/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
82
Docker mode activated.

_ Prechecks _

+1
@author
0
The patch does not contain any @author tags.

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

_ master Compile Tests _

+1
mvninstall
76
master passed

+1
javadoc
10
master passed

_ Patch Compile Tests _

+1
mvninstall
8
the patch passed

+1
hadolint
2
There were no new hadolint issues.

+1
shellcheck
0
There were no new shellcheck issues.

+1
shelldocs
2
There were no new shelldocs issues.

+1
whitespace
0
The patch has no whitespace issues.

+1
javadoc
8
the patch passed

_ Other Tests _

+1
unit
8
precommit in the patch passed.

+1
asflicense
7
The patch does not generate ASF License warnings.

222

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/yetus-github-multibranch/job/PR-36/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/yetus/pull/36

Optional Tests
dupname  asflicense  javac  javadoc  unit  hadolint  shellcheck  shelldocs

uname
Linux cd9c1d533e47 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
precommit/src/main/shell/personality/yetus.sh

git revision
master / 8c3c818

maven
version: Apache Maven 3.3.9

Default Java
1.8.0_191

shellcheck
v0.4.6

Test Results
https://builds.apache.org/job/yetus-github-multibranch/job/PR-36/2/testReport/

Max. process+thread count
90 (vs. ulimit of 2000)

modules
C: precommit U: precommit

Console output
https://builds.apache.org/job/yetus-github-multibranch/job/PR-36/2/console

Powered by
Apache Yetus 0.9.0-SNAPSHOT http://yetus.apache.org

This message was automatically generated.


add tailwindcss-motion

name: "feat: add tailwindcss-motion"
about: "A new simple syntax animation library. Batteries included. Infinitely configurable."
labels:

Animation

I didn't see any reference about shadcn in this lib

i think this is still considerable because shadcn-ui also uses tailwindcss as main css framework and i also think that it is great to introduce this new method of animation for front-end developers instead of sticking to the framer motion


fix malformed connectivity models

Some connectivity browser cannot be properly serialized.
issue tracked: https://github.com/FZJ-INM1-BDA/siibra-python/issues/162
Currently, if the model cannot be serialized, it be replaced with an instance of SerializationErrorModel

(superceded by https://github.com/FZJ-INM1-BDA/siibra-api/pull/76)


Gradle doesn't resolve JAR dependencies when only POM is in local maven repository

Expected Behavior
Gradle should resolve the JAR even if there's already a POM in the local maven repository
Current Behavior
Gradle doesn't resolve the jar and it's missing from the build artifacts
Context
A runtime JAR was missing in production which led to issues
Steps to Reproduce (for bugs)
See https://github.com/kutzi/gradle-pom-jar-bug
Your Environment
gradle 2.13 or 3.5
Linux CentOS 7

The reason is that packaging is pom instead of more reasonable jar in zookeeper's pom.xml:
...
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<packaging>pom</packaging>
<version>3.4.6</version>
...

According to maven lifecycles, for lifecycles with pom packaging, there's no goals to generate jars, but it's still possible to generate jars from projects whose packaging is pom. So it seems that the if block here is unnecessary. I would submit a PR to do this.

I've put there 'pom' to illustrate the issue when you have a Maven project which needs the POM only - which is a valid use case, but then a Gradle project needing the JAR.
In that case the Gradle project cannot resolve the JAR.
This may seem like a constructed use case to you, but in fact this was something hitting us in our CI environment.

Okay, I understand. In my investigation, this issue only happens when the dependency artifact's packaging is pom, for example, zookeeper 3.4.6:
...
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<packaging>pom</packaging>
<version>3.4.6</version>
...

Gradle found its packaging is pom, and .m2 is managed by Maven, so if Maven decides not to download jar into .m2, Gradle will "respect" Maven's decison. For pom packaging, the absence of jar is totally legal.

I don't know about the specs for dep-mgmt/packaging in Maven to say if it's legit to declare 'pom' but then delivering a jar, anyway. So: yes, it's maybe Zookeeper's 'fault' for declaring the wrong packaging type.
But still from an end users perspective, it would be nice if Gradle could handle this scenario gracefully - i.e. downloading the JAR anyway.

This issue is a combination of 2 features that Gradle uses to handle Maven POM files:
For a POM with packaging == 'pom', Gradle will check if a jar file exists, and use it if it's found. In this way, a jar artifact is optional for a module with packaging == 'pom'.
It looks like mvn install is downloading the POM file for zookeeper without downloading the jar file. So when Gradle finds a POM file with packaging == 'pom' and no associated artifact. So it assumes the optional jar file is missing.
This is an issue with using mavenLocal as an artifact repository. Sometimes Maven will leave it in an inconsistent state, and Gradle will suffer from this.
To fix this problem, I suggest you put mavenCentral() ahead of mavenLocal() in your repositories list. In case you're wondering, there's very little performance benefit to putting mavenLocal() first.


qb_hand: 2.2.2-1 in 'noetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository qb_hand to 2.2.2-1:

upstream repository: https://bitbucket.org/qbrobotics/qbhand-ros.git
release repository: https://bitbucket.org/qbrobotics/qbhand-ros-release.git
distro file: noetic/distribution.yaml
bloom version: 0.10.7
previous version for package: null

qb_hand

No changes

qb_hand_control

No changes

qb_hand_description

No changes

qb_hand_hardware_interface

No changes

@umbertofontana93 Could you resolve conflicts?

Holding for Noetic sync

This also conflicts with #30601 I recommend rebasing it on top of #30603 so we can merge that one and then this one as I suspect they will conflict too.

I have opened another PR #30766. You can close this one


not all K95 Platinum macro keys illuminating after iCue update

Expected Behaviour
G1, G2, G4, and G5 keys light up
Actual Behaviour
The described macro keys don't light up.
Reproduction steps
Set up a fill layer on desktop.
Update iCue to latest version, 3.17.94
G1, G2, G4, and G5 keys no longer light up.
Close aurora and they turn back on.
Frequency

100%
Aurora Version:

V0.6.4B-129
Previously an Issue?

Unknown. Didn't occur until today's icue update.

This seems like iCue only issue as reported by other members in discord as well. I suggest you to wait for Corsair to release update. If it works with iCue but only have issues with Aurora then let me know and I will reopen this.

I have exactly the same setup as ShizCalev (Corsair K95 RGB Platinum, iCUE v3.17.94, Aurora v0.6.4b), and exatcly the same problem, and as he said ("Close aurora and they turn back on"), those 4 keys work normally if managed by iCUE itself, but don't light up at all if managed by Aurora.
In fact the very moment you close the Aurora exe, they light up immediately, and can be managed normally through iCUE.
Also for me the problem started when I updated iCUE to the latest version, never experienced that before.

Seems like issue with SDK. Reopening it.

got exactly the same issue.

Same issue here, Only G3 and G6 lights up in Aurora, in icue it's all normal

It seems to be a remapping issue. (Aurora V0.6.4b)
M1 refers to M3 in the ICUE software V3.18.77
and M2 to M6

Any News on this? Can we help somehow?

I have the exact same issue except only G3 and G6 light up. The other macro keys stay turned off but as soon as I exit Aurora, the rest of the lights turned on to work fine with iCue.

For everyone that has this problem, does iCue v3.17.94 have this issue, or is it limited to v3.18.77?

For everyone that has this problem, does iCue v3.17.94 have this issue, or is it limited to v3.18.77?

Just installed ICUE v3.17.94 and has the same issue for me atleast. I set M1 to a colour and M3 lighted up. Got the same with M2 to M6.
K95 RGB Platinum (US North America), Firmware v3.21.7168. ICUE v3.17.94. Aurora v0.6.4b (Key layout, United States) = Bug Present
K95 RGB Platinum (US North America), Firmware v3.21.7168. ICUE v3.18.77. Aurora v0.6.4b (Key layout, United States) = Bug Present
When you need more info, I'll be glade to help.

Please test #1670 and let me know if it works

Please test #1670 and let me know if it works

Thx for the easy FIX. It works great again!


Make variable editor right click menu hidden by default

The RightClick menu showed up in the top left of the editor each time the editor was started because visible was set to true. This fixes that so the menu doesn't show up by default.

Thank you very much!


Dependency constraint for commons-codec

Triggered by https://sbom.lift.sonatype.com/report/T1-a0368c8f29fdaa555824-1976de725d346b-1657450379-c52141ae274c4a54b0e774090498e1b9

To be fixed without constraints to propagate the change to the POM


Port Mail as s-c-s source

As a developer, I'd like to move mail module from XD to s-c-s-m repo, so I can use it as source to build streaming pipeline.
Acceptance:

mail as source module is available in spring-cloud-stream-modules repo
maven repo includes mail module with respective group/artifact/version detail

There's a PR for this already.


Add test/validation stage to CI

To add some more details to this: What we need is a kind of smoke test. We do extensive user acceptance testing before deploying, so this test does not need to go over every single acceptance case again. Especially as some of them would depend on a specific state (such as an import schema and imported fixtures).
This test should verify that the deployment was successful (beyond a passed health check) and that a representative business transaction (comparable to a "Synthetic Transaction") can successfully be completed after the rolling update.


Fixed typo in text area descriptions

Fixed a typo causing confusion in the streamlit_sql_sandbox application. The 'violation' and 'inspection' tables were inaccurately labeled as 'Business table description'.
business_table_descrp = st.text_area(
    "Business table description", value=DEFAULT_BUSINESS_TABLE_DESCRP
)
violations_table_descrp = st.text_area(
    "Business table description", value=DEFAULT_VIOLATIONS_TABLE_DESCRP
)
inspections_table_descrp = st.text_area(
    "Business table description", value=DEFAULT_INSPECTIONS_TABLE_DESCRP
)

Good catch, thanks!


Sample for using JDBC.NET with Dapper

Curious if you would have a sample of how to use JDBC.NET with say something like Dapper.
Currently running into trouble when binding parameters using their sample.
public class Dog
        {
            public int Age { get; set; }
            public string Id { get; set; }
        }

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = 7, Id = "Mr. Dog" });

Would give the error:
The given key was not present in the dictionary.
at JDBC.NET.Data.JdbcParameterCollection.Contains(String parameterName)
at Dapper.DbString.AddParameter(IDbCommand command, String name) in //Dapper/DbString.cs:line 65
at ParamInfo9e274bac-0a53-4256-bf31-c91b703ba22c(IDbCommand, Object)
at Dapper.CommandDefinition.SetupCommand(IDbConnection cnn, Action2 paramReader) in /_/Dapper/CommandDefinition.cs:line 128    at Dapper.SqlMapper.QueryImpl[T](IDbConnection cnn, CommandDefinition command, Type effectiveType)+MoveNext() in /_/Dapper/SqlMapper.cs:line 1091    at System.Collections.Generic.List1..ctor(IEnumerable1 collection)    at System.Linq.Enumerable.ToList[TSource](IEnumerable1 source)
at Dapper.SqlMapper.Query[T](IDbConnection cnn, String sql, Object param, IDbTransaction transaction, Boolean buffered, Nullable1 commandTimeout, Nullable1 commandType) in //Dapper/SqlMapper.cs:line 734

JDBC does not support named parameters.
https://docs.oracle.com/javase/6/docs/api/java/sql/PreparedStatement.html
It accepts prepared statements with positional arguments.
Use:
var dog = connection.Query<Dog>("select Age = ?, Id = ?", new { Age = 7, Id = "Mr. Dog" });
I just tested that, and it works.


Action message support

This implements action support in rosidl_generator_rs and rosidl_runtime_rs. It's a selective rebase of the original changes made in #295 and #410, applying only changes to the two rosidl packages, without any modification to rclrs. The intention here is to merge these changes sooner so that we can split the message support packages into a separate repo and add them to the ROS buildfarm.
The general approach follows the same pattern as the existing message and service generation. However, the additional message wrapping and introspection done on actions means that we need generic access to certain message internals. In rclcpp, this is done using duck typing on the Action and Action::Impl template parameters. However, Rust is stricter about this and requires trait bounds to ensure that generic type parameters can be accessed in a given way. As a result, a series of trait methods are defined in ActionImpl that enable a client library like rclrs to generically create and access the various message types.
Certain of these methods involve accessing timestamps and UUIDs in messages. To avoid adding a dependency in rosidl_runtime_rs on builtin_interfaces and unique_identifier_msgs, these are represented in a more primitive form as (i32, u32) and [u8; 16] in the signatures, respectively. This is rather ugly, so ideas are welcome.
The existing srv.rs.em file is split into separate "idiomatic" and "RMW" implementations, similarly to how messages are already handled. This makes embedding the service template into the action.rs.em easier.

I think one of the difficulties of deriving traits for message types is that we have very little information about the individual messages before compile time. We cannot be sure that any of these traits are derivable before the generators create the code.
Additionally, these messages are interacted with through the FFI boundary, which can potentially cause some weirdness at the best of times. I would be cautious about the automatic derivation of any traits unless we are 100% certain that we aren't going to have a problem introduced due to the FFI interactions. Admittedly this is a rare issue, but I feel it's best to be cautious when dealing with FFI.
Is there a specific reason that you would like to see these traits automatically derived?

I think one of the difficulties of deriving traits for message types is that we have very little information about the individual messages before compile time. We cannot be sure that any of these traits are derivable before the generators create the code.

I'm not so sure this is true. We know three important things:

Every message definition is a struct composed of some combination of other messages or of ROS message primitives (e.g. f32, f64, u32, i32, [T], ...).
Every ROS message primitive can implement Clone, Debug, Default, PartialEq, Eq, PartialOrd, Ord, and Hash (the only one missing is Copy).
Every struct composed of things that implement those traits can also derive those traits

So I believe we could trivially derive all the popular traits besides Copy automatically for all message definitions.

Is there a specific reason that you would like to see these traits automatically derived?

I'm strongly in favor of providing the implementations for the sake of developer quality of life.
For better or worse, ROS message data structures play a big role in the internal mechanics of most ROS nodes.

Being able to easily clone when needed can be vital to writing reasonable control flows.
Debug would help people inspect their nodes and write useful log messages
Hash and Eq help with caching and recognizing redundant messages
PartialOrd and Ord can help with organizing or sorting data, but these are probably the least important of the traits, so I wouldn't feel strongly about including this or not.

All that said, I might suggest we save traits for a follow up PR.

Certain of these methods involve accessing timestamps and UUIDs in messages. To avoid adding a dependency in rosidl_runtime_rs on builtin_interfaces and unique_identifier_msgs, these are represented in a more primitive form as (i32, u32) and [u8; 16] in the signatures, respectively. This is rather ugly, so ideas are welcome.

It would definitely be nice if we can clean up that situation a bit. I don't love what I'm about to suggest, but here's a stab at having something a bit more pleasant:

Define newtype structs in the rosidl_runtime_rs such as Timestamp and Uuid to wrap this data
Add a special condition to rosidl_generator_rs to check if we are generating bindings for builtin_interfaces::Time or unique_identifier_msgs::Uuid
If we are generating one of the special cases, then include an impl From<Newtype> for Message for each. Perhaps also give each message struct a method to convert it into the relevant rosidl_runtime_rs newtype.

Let me know if anyone has thoughts on that. I can take a stab at drafting it if there are no strong objections.

I think one of the difficulties of deriving traits for message types is that we have very little information about the individual messages before compile time. We cannot be sure that any of these traits are derivable before the generators create the code.
Additionally, these messages are interacted with through the FFI boundary, which can potentially cause some weirdness at the best of times. I would be cautious about the automatic derivation of any traits unless we are 100% certain that we aren't going to have a problem introduced due to the FFI interactions. Admittedly this is a rare issue, but I feel it's best to be cautious when dealing with FFI.
Is there a specific reason that you would like to see these traits automatically derived?

In my opinion, this makes handling the structs feel more idiomatic. When I program other things with rust, I expect these standard traits from the imported structs. It also makes the handling of the structs simpler, as certain things like comparisons or the output of the structs in the standard output then already work. You get a better feel for what the struct is doing. It's also a bit awkward every time you have to implement it yourself. In many cases it works with the newtype pattern. In some cases you have to dig deeper into the material. It doesn't matter if it doesn't work. I thought it would be a nice idea.
On the other hand: Ros messages are defined by design so that they can only consist of primitive data types. This goes so far that it is basically not possible to transmit enum symbols with Ros. As far as I know, strings in Ros are equivalent to rusts String.

@Guelakais I assume we're only talking about the message types, since the top-level action type is an empty struct that's only useful as a generic type parameter. It's not useful to create an actual instance of this type, so I don't see a need for any trait derivations there.
For the message types, I agree that it's useful to have certain common traits implemented on them. Regarding the list you gave:

Clone, Debug, PartialEq, and PartialOrd are already derived for today's message types.
Default is manually implemented for message types, using the *__init() functions generated by rosidl_generator_c.
Copy is not universally possible since some messages may contain non-Copy fields like strings and sequences. Since we can't always determine whether a non-primitive field is Copy or not, we would only be able to implement this for messages containing only primitive Copy fields.
Eq, Ord, and Hash are not universally applicable since the primitives f32 and f64 don't implement these traits. This could be worked around using something like ordered-float to wrap the fields in the implementations, but I'm not sure if that is always correct.

So the traits that are trivially derivable are already done.
In any case, I'd say this should be discussed in a separate issue since the message generation isn't actually touched in this PR.

@mxgrey

Certain of these methods involve accessing timestamps and UUIDs in messages. To avoid adding a dependency in rosidl_runtime_rs on builtin_interfaces and unique_identifier_msgs, these are represented in a more primitive form as (i32, u32) and [u8; 16] in the signatures, respectively. This is rather ugly, so ideas are welcome.

It would definitely be nice if we can clean up that situation a bit. I don't love what I'm about to suggest, but here's a stab at having something a bit more pleasant:
* Define newtype structs in the `rosidl_runtime_rs` such as `Timestamp` and `Uuid` to wrap this data

* Add a special condition to `rosidl_generator_rs` to check if we are generating bindings for `builtin_interfaces::Time` or `unique_identifier_msgs::Uuid`

* If we are generating one of the special cases, then include an `impl From<Newtype> for Message` for each. Perhaps also give each message struct a method to convert it into the relevant `rosidl_runtime_rs` newtype.

Let me know if anyone has thoughts on that. I can take a stab at drafting it if there are no strong objections.

An alternative we could consider would be this:

Redefine ActionImpl as rosidl_runtime_rs::ActionImpl<TimeMsg, UuidMsg>, taking two generic type parameters that it uses in all the relevant spots in its method signatures.
In rosidl_generator_rs, where the generated code already depends on the concrete builtin_interfaces and unique_identifier_msgs packages, have the action struct impl rosidl_runtime_rs::ActionImpl<builtin_interfaces::msg::rmw::Time, unique_identifier_msgs::msg::rmw::UUID>. The method implementations would then use the concrete message types.
In rclrs, use rosidl_runtime_rs::ActionImpl<builtin_interfaces::msg::rmw::Time, unique_identifier_msgs::msg::rmw::UUID> as a trait bound on actions so that we can access the concrete methods.

Without trait aliases, this might be a bit cumbersome to work with on the rclrs side, but it avoids special casing in the generator.

@Guelakais I assume we're only talking about the message types, since the top-level action type is an empty struct that's only useful as a generic type parameter. It's not useful to create an actual instance of this type, so I don't see a need for any trait derivations there.
For the message types, I agree that it's useful to have certain common traits implemented on them. Regarding the list you gave:
* `Clone`, `Debug`, `PartialEq`, and `PartialOrd` are already derived for today's message types.

* `Default` is manually implemented for message types, using the `*__init()` functions generated by `rosidl_generator_c`.

* `Copy` is not universally possible since some messages may contain non-`Copy` fields like strings and sequences. Since we can't always determine whether a non-primitive field is `Copy` or not, we would only be able to implement this for messages containing only primitive `Copy` fields.

* `Eq`, `Ord`, and `Hash` are not universally applicable since the primitives `f32` and `f64` don't implement these traits. This could be worked around using something like [ordered-float](https://docs.rs/ordered-float/latest/ordered_float/struct.OrderedFloat.html) to wrap the fields in the implementations, but I'm not sure if that is always correct.

So the traits that are trivially derivable are already done.
In any case, I'd say this should be discussed in a separate issue since the message generation isn't actually touched in this PR.

OH, I didn't know that. If I didn't know that - I should make a pull request to improve the documentation of the codegenerator. :)
I didn't want to cause so much confusion. all in all, the integration of actions is great.
A small note: The communication system of ros2 has strong dependencies on the DDS interface. Depending on which DDS is used here, this can lead to strange effects. How does the rust api handle this?

In rclrs, use rosidl_runtime_rs::ActionImpl<builtin_interfaces::msg::rmw::Time, unique_identifier_msgs::msg::rmw::UUID> as a trait bound on actions so that we can access the concrete methods.

This is a very interesting idea for how to break the circular dependency. One nitpick I might have is that if a trait has generic parameters, that implies that users should expect it to be possible for the same data structure to implement the same trait with different generic arguments. I think a slightly better arrangement might be to use associated types:
pub trait ActionImpl {
    type GoalUuid;
    type Timestamp;
    ...
}

then if rosidl_generator_rs can just always use
impl ActionTrait for <T> {
    type GoalUuid = unique_identifier_msgs::msg::rmw::UUID;
    type Timestamp = builtin_interfaces::msg::rmw::Time;
}

Then rclrs can use
Action: ActionImpl<GoalUuid = unique_identifier_msgs::msg::rmw::UUID, Timestamp = builtin_interfaces::msg::rmw::Time>

as a trait bound when needed.
That being said, I don't see anything wrong with special-casing builtin_interfaces and unique_identifier_msgs since those are foundational message packages that play a special role in the internal mechanics of actions. I suspect that having these two special cases in the message generation would be a small price to pay to avoid juggling lots of generics that aren't otherwise necessary.

I know this may be asking a lot for such complex message generation, but can you add some high level docs?

@maspe36 I've added a short doc page under docs/message-generation.md. Let me know what you think.

@esteve & @jhdcs, I think this is ready to merge, in case you would like to take a look.

This LGTM, we can address anything more in follow up PRs. Thanks @nwn!


Correct Arduino's Color

Change arduino's purple color representation to it's signature blue.

The color I took for 3D max was taken from a color picker of their logo. I don't see how that isn't representative. The net change of the repo is more accurate. Arduino becomes represented correctly, as opposed to 100% inaccurate representation. 3D Max goes from slightly misrepresented to slighly more misrepresented (with a color that is on it's logo).

In all fairness, the minimum required difference between colours should really be dropped. It's doing more harm than good (as PRs like this have repeatedly evidenced), and colours that are too similar are unlikely to be featured side-by-side in the same codebases anyway.
/cc @lildude Is there anything we can do about this? Many colours misrepresent their languages this way... 😕

@MarcianoPreciado Randomly selecting a pixel isn't a good way of selecting a colour, FYI. The particular shade of teal used by 3DS Max is #00aaaa, which can be seen on its Autodesk product page.
When possible, try to consult an official styleguide before resorting to the eyedropper. 😉

In all fairness, the minimum required difference between colours should really be dropped. It's doing more harm than good (as PRs like this have repeatedly evidenced), and colours that are too similar are unlikely to be featured side-by-side in the same codebases anyway.

I'm convinced that, if we could see the available colors on a color panel, we'd find that there are plenty of options remaining... (before we start looking into the likeliness of languages to be featured side-by-side)


Hintmanager  databaseShardingOnly problem

Bug Report
Please answer these questions before submitting your issue. Thanks!
Which version of ShardingSphere did you use?
4.0.0
Which project did you use? Sharding-JDBC or Sharding-Proxy?
Sharding-JDBC
Expected behavior
i can hint databases with sth outside my database, for example , i want to get the hint key from my http header ,then route by the key.
Actual behavior
it route to all my datasources
Reason analyze (If you can)
maybe the hintmanager has wrong code
this code is in hintmanager,i use setDatabaseShardingValue method to config my shardkey,
here, it put an empty key for the sharding values.

public void setDatabaseShardingValue(final Comparable<?> value) {
    databaseShardingValues.clear();
    tableShardingValues.clear();
    databaseShardingValues.put("", value);
    databaseShardingOnly = true;
}

but when i followed it in the getDatabaseShardingValues method, it gets the shardingValues
by the logicTable, so I can not get the shardingvalues which i configed.

public static Collection<Comparable<?>> getDatabaseShardingValues(final String logicTable) {
    return null == HINT_MANAGER_HOLDER.get() ? Collections.<Comparable<?>>emptyList() : HINT_MANAGER_HOLDER.get().databaseShardingValues.get(logicTable);
}

then  in the routeDataSources method of  StandardRoutingEngine

private Collection<String> routeDataSources(final TableRule tableRule, final List<RouteValue> databaseShardingValues) {
    if (databaseShardingValues.isEmpty()) {
        return tableRule.getActualDatasourceNames();
    }
    Collection<String> result = new LinkedHashSet<>(shardingRule.getDatabaseShardingStrategy(tableRule).doSharding(tableRule.getActualDatasourceNames(), databaseShardingValues));
    Preconditions.checkState(!result.isEmpty(), "no database route info");
    Preconditions.checkState(tableRule.getActualDatasourceNames().containsAll(result),
            "Some routed data sources do not belong to configured data sources. routed data sources: `%s`, configured data sources: `%s`", result, tableRule.getActualDatasourceNames());
    return result;
}

the databaseShardingValues is empty , so it returns all the actualDatasources, not only the datasource i conifged.
could you please provide an example for this situation?

@tmjGitAccount @darcydai
Can you provide your SQL and algorithm class?

@KomachiSion
spring:
  shardingsphere:
    props:
      sql:
        show: true
    sharding:
      default-database-strategy:
        hint:
          algorithm-class-name: com.a.b.c.OrderShardingAlgorithm
    datasource:
      names: dsa,dsb
      dsa:
        pool-name: dsa
        type: com.zaxxer.hikari.HikariDataSource
        driverClassName: com.mysql.jdbc.Driver
        jdbcUrl: xxx
        username: xxx
        password: xxx
      dsb:
        pool-name: dsb
        type: com.zaxxer.hikari.HikariDataSource
        driverClassName: com.mysql.jdbc.Driver
        jdbcUrl: xxx
        username: xxx
        password: xxx

@tmjGitAccount @darcydai
I try to reproduce problem by configuration you provided, and I found that there are no tableRule so that ShardingSphere use unicast routing instead of hint routing. May you provide more information makes me reproduce problem?
If no more response, I will close this issue and think this is a usage issue

@tmjGitAccount @darcydai
I try to reproduce problem by configuration you provided, and I found that there are no tableRule so that ShardingSphere use unicast routing instead of hint routing. May you provide more information makes me reproduce problem?
If no more response, I will close this issue and think this is a usage issue

add this config may reproduce ?
default-table-strategy:
hint:
algorithm-class-name: com.a.b.c.OrderShardingAlgorithm

I have added, but I don't know your SQLs. I try my SQL, and it still is unicast routing.
So I need your SQLs and OrderShardingAlgorithm

I have added, but I don't know your SQLs. I try my SQL, and it still is unicast routing.
So I need your SQLs and OrderShardingAlgorithm

Here is my OrderShardingAlorithm.java，the sql is just a very normal select * from table
All I want is to route to different datasource by different header
for example

if the httpheader  agency: a
i want this sql be excuted in datasource dsa
if the httpheader agency: b
i want this sql be excuted in datasource dsb

maybe could you please  provide me an example config for the purpose i want ?
import lombok.NoArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.apache.shardingsphere.api.sharding.hint.HintShardingAlgorithm;
import org.apache.shardingsphere.api.sharding.hint.HintShardingValue;
import org.springframework.stereotype.Component;
import org.springframework.web.context.request.RequestAttributes;
import org.springframework.web.context.request.RequestContextHolder;
import org.springframework.web.context.request.ServletRequestAttributes;

import javax.servlet.http.HttpServletRequest;
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
import java.util.Optional;
import java.util.stream.Collectors;

@Slf4j
@NoArgsConstructor
@Component("orderShardingAlgorithm")
public class OrderShardingAlgorithm implements HintShardingAlgorithm<String> {

    @Override
    public List<String> doSharding(final Collection<String> availableTargetNames, final HintShardingValue<String> shardingValue) {
        RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes();
        HttpServletRequest request = ((ServletRequestAttributes) requestAttributes).getRequest();
        return Optional.ofNullable(request.getHeader("agency"))
                .map(value -> availableTargetNames.stream().filter(v -> v.equals(value)).collect(Collectors.toList()))
                .filter(value -> !value.isEmpty())
                .orElse(new ArrayList<>(availableTargetNames));

    }
}

@tmjGitAccount I will try again.


Help Setting Up The Environment Properly to Contribute

💬 Questions and Help
@martijn00 I'd like to help contribute as I've got a couple solutions to some things I see missing on the iOS side, but I'm unable to build this project successfully on Windows or Mac, making it kind of hard to test. Since all the platform code isn't in specific projects, I don't think I can just exclude platforms I can't build due to environment. What is the process to properly build and test on a mac or windows OS?
Chiefly, I'd like to take a stab at adding:

Audio interruption resuming on iOS
More granular hooks for turning off and on notification features
iOS control center scrubber support

Would be great to get some contributions! To start developing you need to install the very latest Visual studio versions, that were released only yesterday. Before that you had to run a preview version. On windows you need to have the UWP SDK installed, and on both you need the latest .net core 3.0. Also you need to have the Android SDK 9.0.
It is possible to switch to only building one target: https://github.com/martijn00/XamarinMediaManager/blob/develop/Directory.build.props#L61
But i don't think that helps much in your case. You just need the right software installed.
The things you mention sound like great areas to work on. If there is no issue open for them, please open one so we can track status per issue. If you have questions during development or about architecture, send me a DM.


Improve Filter Box Control to accept Conditional Filters

Is your feature request related to a problem? Please describe.
Currently, Dashboard filters accept a list of dimensions and you can filter on values. But , for a few reports, I also want to filter based on some conditions. Let's take the example of the Sample Dashboard World Bank's Data. I wanted to see Life Expectency for Asia without the Country India.
Describe the solution you'd like
Currently, i can only select filters where value is in [some value] . I would like the filters to be more dynamic and one can build upon those instead of selecting a value.

Instead of this, i would like a representation that has the following

You can build filter controls with a specified set of dimensions but while rendering the dashboard, you can pick and select them just like filter controls.
Describe alternatives you've considered
I have considered adding a filter to the chart itself. But there are times when i just want to filter out on some values from the dashboard / just do a quick compare with different filter conditions.
Additional context
Add any other context or screenshots about the feature request here.
I saw a similar request here but it's been closed now.
https://github.com/apache/incubator-superset/issues/8194

You can create a filter based on a query in SQL-Lab, and then use it in the Dashboard.


Unknown data format for file renamed.json

Error: "ValueError: Unknown data format for file renamed.json"
I checked the data in https://jsonlint.com for JSON validation. It's showing valid JSON but not working.
Here configuration
language: "en"
pipeline:

name: "nlp_mitie"
model: "MITIE-models/english/total_word_feature_extractor.dat"
name: "tokenizer_mitie"
name: "ner_mitie"
name: "ner_synonyms"
name: "intent_entity_featurizer_regex"
name: "intent_classifier_mitie"

Rasa version: 0.15

Thanks for raising this issue, @erohmensing  will get back to you about it soon.

@vinaykumarpns hm, is your training data correctly formatted for rasa format? Should look something like
{
    "rasa_nlu_data": {
        "common_examples": [],
        "regex_features" : [],
        "lookup_tables"  : [],
        "entity_synonyms": []
    }
}

https://rasa.com/docs/nlu/dataformat/#json-format

@erohmensing Yeah, My data format is same as you mentioned. actually, this data working for this configuration :
language: en
pipeline: spacy_sklearn
but not working for the above-mentioned configuration
Here I've attached a link for file(renamed.json) for your reference.
Thank you for your time :)
Link: https://drive.google.com/open?id=1CPuZz0U9P2F2NllyVjt_x4oUXdbqKTzm

Hey, Magic happened it's working now. I just changed import rasa.nlu to rasa_nlu :)
Thanks for your time and sorry for the inconvenience happened by me.

Ahh thats no problem, I'm glad you got it figured out! I'm surprised that import worked -- you probably have the rasa pypi package installed when you don't need it if you have rasa_nlu and rasa_core, it can cause issues if it's lying around.

Yeah, I forgot that I cloned library. @erohmensing Can you help me out. Still, I'm not getting the result(It's not detecting Entities). I think this is not the right platform. I will post in Rasa Forum. Thank you :)


TS2322 not rendered correctly

Describe the bug
ts(2322) is rendererd partly wrong at the end.
These are the relevant properties
#overlaps!: OverlapConfigurationParameters[];
private async download(file: File<string | MpcdiZip>): Promise<void>

Expected behavior
each property listed gets its own bullet point
Original error
Type 'Ref<{ name: string; readonly type: "json"; mm: <T extends Convertible = Convertible>(px: T) => T; px: <T extends Convertible = Convertible>(mm: T) => T; ... 18 more ...; toJson: () => string; }>' is not assignable to type 'Ref<MpcdiConfiguration>'.
  Type '{ name: string; readonly type: "json"; mm: <T extends Convertible = Convertible>(px: T) => T; px: <T extends Convertible = Convertible>(mm: T) => T; ... 18 more ...; toJson: () => string; }' is missing the following properties from type 'MpcdiConfiguration': ratio, #overlaps, download

Screenshots

is missing the following properties from type MpcdiConfiguration:

ratio,
#overlaps, download

Issue is the private property prefix character #, I submitted a PR #106

Thank you, the fix will be there in the next version


feat(controller): unix timestamp support on creationTimestamp var

fixes #2637
Support Unix Time format in workflow.creationTimestamp variable.
Checklist:

[ ] My organization is added to USERS.md.

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

LGTM


bring back kafka as a dev dependency

actually, as I understood https://github.com/testcontainers/testcontainers-python/issues/351 we want to actively not make it a dependency because then people can choose between python-kafka and confluent-kafka for themselves.
I think we can close this and move on with the original PR :pray:

Yes, the dependency is only there initially to implement the waiting logic, as far as i can see.

I did another round, actually you do need it for running the tests too.
So the simplest thing to do for right now is to add python-kafka as a dev dependency.
@alexanderankin added it as an optional dependency too, maybe no need for the latter, just the former.
@gudjonragnar would you please make this change for us on your original PR? Just to make the tests pass. :pray:

I have added it back as a dev dependency on the original PR 👍 . Will close this one.


feat: mapping lua callback

This PR allows users to map given keybinding with lua callback
Currently, users can achieve setting callback with:
    ...
  ["n|fp"] = map_cu("lua require('telescope').extensions.projects.projects{}"):with_noremap():with_silent(),
    ...

This PR allows the following:
local map_callback = require("keybind").map_callback

    ...
  ["n|fp"] = map_callback(
    function()
        require('telescope').extensions.projects.projects{}
    end
  ):with_noremap():with_silent(),
    ...

This makes writing keymap feel more natural and programmatically than parsing string.
Signed-off-by: Aaron Pham<EMAIL_ADDRESS>

Approve it. But maybe map_lua more intuitive?


snapshot: move testsuite to sub-package

Prevents importers of snapshot to require importing test packages.

Codecov Report

Merging #610 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #610   +/-   ##
=======================================
  Coverage   63.63%   63.63%
=======================================
  Files           3        3
  Lines         440      440
=======================================
  Hits          280      280
  Misses         96       96
  Partials       64       64

Continue to review full report at Codecov.

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

LGTM


Lens Prometheus install not providing metrics

On a fresh, vanilla cluster I have connected with Lens, all is well.  After using the Lens "Install" button for metrics in cluster settings install completes with no errors.  Everything seems to be setup correctly and running, but no metrics are being provided.  I have waited a full 24hrs just to make sure it wasn't a data collection issue.  The only reporting I see in Lens is: "Metrics are not available due to missing or invalid Prometheus configuration."  The installation method listed in cluster settings after installation is "Auto detect".
Environment (please complete the following information):

Lens Version: 3.6.4
OS: Windows 10

Logs:
info: [IPC]: setup channel "cluster:activate"
info: [IPC]: setup channel "cluster:refresh"
info: [IPC]: setup channel "cluster:disconnect"
info: [IPC]: setup channel "cluster:install-feature"
info: [IPC]: setup channel "cluster:uninstall-feature"
info: [IPC]: setup channel "cluster:upgrade-feature"
info: ≡ƒÜÇ Starting Lens from "C:\Users\trgibson\AppData\Roaming\Lens"
info: Checking for update
info: [STORE]: LOADED from C:\Users\trgibson\AppData\Roaming\Lens\config.json
info: [STORE]: LOADED from C:\Users\trgibson\AppData\Roaming\Lens\lens-cluster-store.json
info: [STORE]: LOADED from C:\Users\trgibson\AppData\Roaming\Lens\lens-workspace-store.json
info: [CLUSTER-MANAGER]: init cluster {"id":"ba67aa2c-542c-4a3d-a1ce-a1c79092f279","name":"kubernetes-admin@kubernetes","initialized":false}
info: [CLUSTER]: "kubernetes-admin@kubernetes" init success {"id":"ba67aa2c-542c-4a3d-a1ce-a1c79092f279","context":"kubernetes-admin@kubernetes","apiUrl":"https://<IP_ADDRESS>:6443"}
info: LensProxy server has started at http://localhost:53402
error: ENOENT: no such file or directory, open 'C:\Users\trgibson\.kube\config' {"errno":-4058,"code":"ENOENT","syscall":"open","path":"C:\\Users\\trgibson\\.kube\\config"}
info: [KUBE-AUTH]: out-channel "kube-auth:ba67aa2c-542c-4a3d-a1ce-a1c79092f279" {"data":"Authentication proxy started\n","meta":{"id":"ba67aa2c-542c-4a3d-a1ce-a1c79092f279","name":"kubernetes-admin@kubernetes","initialized":true}}
info: Update for version 3.6.4 is not available (latest version: 3.6.4, downgrade is disallowed).
info: [CLUSTER]: activate {"id":"ba67aa2c-542c-4a3d-a1ce-a1c79092f279","name":"kubernetes-admin@kubernetes","initialized":true}
info: [CLUSTER]: bind events {"id":"ba67aa2c-542c-4a3d-a1ce-a1c79092f279","name":"kubernetes-admin@kubernetes","initialized":true}
info: [CLUSTER]: refresh {"id":"ba67aa2c-542c-4a3d-a1ce-a1c79092f279","name":"kubernetes-admin@kubernetes","initialized":true,"ready":true,"online":true,"accessible":true}
info: [KUBE-AUTH]: out-channel "kube-auth:ba67aa2c-542c-4a3d-a1ce-a1c79092f279" {"data":"2020/09/23 10:34:41 http: proxy error: context canceled\n2020/09/23 10:34:41 http: proxy error: context canceled\n2020/09/23 10:34:41 http: proxy error: context canceled\n","error":true,"meta":{"id":"ba67aa2c-542c-4a3d-a1ce-a1c79092f279","name":"kubernetes-admin@kubernetes","initialized":true,"ready":true,"online":true,"accessible":true}}

Further digging showed that the node-exporter service type is "ClusterIP", but the IP shown is "None".  Isn't this service supposed to have an IP listed for communications?  Again, this was installed using the default deployment inside of Lens.

I had a custom value in the Helm type selection for metrics. I eventually uninstalled the custom Prometheus, and tried the integrated solution and was seeing the same thing. When I switched the type back to helm (from Lens) and removed the custom value for Prometheus address, then switched Prometheus type back again to Lens, it worked after restart. 🤷

Is this still an issue with 4.1.4?

I can still see this even with 4.2.2 version.
I have k8s cluster, 1 master node, 3 worker nodes. OS is RedHat, Docker used as container runtime, k8s version 1.21.0
I used  the install button for Metric Stack from Lens and there is no other metric server installed in the cluster.
First I had issue with node exporter, that was giving errors such as msg="ERROR: timex collector failed after 0.000015s: failed to retrieve adjtimex stats: operation not permitted". I could fix that by setting SYS_TIME capability for container:
   securityContext:
      capabilities:
        add: ["SYS_TIME"]

Then I realized this is not needed anymore as this was fixed by using node-exporter:v1.1.2 instead of node-exporter:v1.0.1. This should be changed to be installed by Lens as well by default! But even now I do not see metrics at all, only message:
Metrics are not available due to missing or invalid Prometheus configuration.

Right click cluster icon to open cluster settings.

Not sure what else to try. I installed with "Auto detect" as well as "Lens option, but so far I had not luck to see metrics in Lens at all. Otherwise it is nice tool.

@petermicuch I've faced this issue too. Try to change Prometheus installation method to Helm and use lens-metrics/prometheus:80 as service address, then restart Lens app. It worked for me.

@xvonabur thank you for your suggestion. I tried exactly as you wrote, but I still do not see any metrics, the message is the same:
Metrics are not available due to missing or invalid Prometheus configuration.
Right click cluster icon to open cluster settings.

Strange thing is, that even tough I selected Helm as installation method, I do not see any helm release in the lens-metric namespace, so it does not look like it was actually installed by Helm. Are you able to confirm this on your side?

@petermicuch Lens only installs metrics for its own stack. The other options are for telling lens about a previously installed Prometheus stack.

Yes it is working for me, though I mostly have been using minikube and kind for testing. I have noticed that sometimes it takes and while (maybe 10-30 minutes) for the metrics to work.

@Nokel81 I just tried with Docker Desktop cluster and it indeed works there. The other clusters that I have are in the corporate network and behind proxy. Might there by any communication that goes unintentionally outside of the cluster due to missing entry in the NO_PROXY variable used by the cluster?

So Lens proxies everything itself. I assume you have set the HTTP Proxy settings in Cluster Settings.

@Nokel81 Thank you for your hint.
I am running Lens on my dev PC. On the same machine I am running k8s cluster via Docker Dekstop. In that one, I can see metrics. And I am from the same PC connected to another cluster (running on bare metal RedHat). That cluster is behind different proxy server, than my developer PC. All Prometheus related pods are running fine (node exporter, kube-state-metrics and prometheus itself).
I tried setting the proxy in the cluster configuration of Lens as per your suggestion, but there are still no metrics, and I would not even expect any change, because description says HTTP Proxy server. Used for communicating with Kubernetes API.. And to talk to kubernetes API of that cluster from my PC, I actually do not need any proxy server, it works directly.
Or have I missed anything? If Lens running on one machine is able to see metrics in one cluster, but not the other one, could this rule out proxy issue?

same in lens 5.0.2 , why official docs not tell us what we should do?
Metrics are not available due to missing or invalid Prometheus configuration.

Right click cluster icon to open cluster settings.

[root@k8s-master1 ~]# kubectl get pods -A | grep metri
kube-system                    metrics-server-57bcd9bccd-xgkzh                                   1/1     Running     0          15h
kubesphere-monitoring-system   kube-state-metrics-687c7c4d86-m49ct                               3/3     Running     0          14h
[root@k8s-master1 ~]# kubectl top pods
NAME                                 CPU(cores)   MEMORY(bytes)
dnsutils                             0m           0Mi
nginx-deployment-66b6c48dd5-f9v2j    0m           1Mi
nginx-deployment1-6947dd7485-hbxfp   0m           1Mi
[root@k8s-master1 ~]#

[root@k8s-master1 ~]# kubectl get pods -A |grep prome
kubesphere-monitoring-system   prometheus-k8s-0                                                  3/3     Running     1          47m
kubesphere-monitoring-system   prometheus-k8s-1                                                  3/3     Running     1          47m
kubesphere-monitoring-system   prometheus-operator-d7fdfccbf-brvhx                               2/2     Running     0          15h
[root@k8s-master1 ~]#

I have prometheus installed via prometheus-operator and noticed that it requires some additional components to enable metrics. Prometheus by itself just provides the time series database. At least, you'll need

node-exporter for node and cluster metrics
kube-state-metrics for pod, pvc and ingress metrics
some scrape configs to retrieve the metrics into prometheus

You can see the promql queries that lens uses in /src/main/prometheus/. If you copy&paste them into the prometheus console, you can check that they actually return some values.
I was able to get the pod and pvc metrics work. However, I still don't get cluster and node metrics, although I can manually retrieve the data from prometheus. Is there any way to see what lens is missing from prometheus?
Ingress metrics seem to be hard coded to nginx. If you use another ingress controller, it won't work.

@sgmia - I can see metrics when not behind proxy and using stack that Lens provides. So Prometheus stack provided by Lens is fine in my opinion. The problem at least for me is, when the cluster is behind corporate proxy - then Lens have issue to connect.
@Nokel81 I might have a clue. Today one of the colleagues contacted me, that there is a lot of rejected HTTP calls in the proxy logs.  Example call looked like this:
Blocked: http://<IP_ADDRESS>/api/v1/query_range?query=su.......

The <IP_ADDRESS> is the IP of the master node of the k8s cluster that we have behind corporate proxy and which I observe with Lens. I also used Lens to install Prometheus stack there. The URL is Prometheus query.  The question is, why would Lens try to create web request to exactly this URL? Is it not missing the whole /api/v1/namespaces/${prometheusPath}/proxy${prometheusPrefix} part?

@Nokel81 - shall I open separate issue just for metrics not working with proxy server involved?
I checked logs of Lens and it indeed is getting response from our proxy (403 message below).
info: [WORKSPACE-STORE] starting to listen state events
info: [APP]: Init dashboard, clusterId=cc555c5a-4fc9-436a-84fb-ad56926914d8, frameId=5
info: [EXTENSION]: enabled<EMAIL_ADDRESS>info: [EXTENSION]: enabled<EMAIL_ADDRESS>info: [EXTENSION]: enabled<EMAIL_ADDRESS>info: [EXTENSION]: enabled<EMAIL_ADDRESS>info: [EXTENSION]: enabled<EMAIL_ADDRESS>info: [STORE]: LOADED from C:\Users\aipcazureagent\AppData\Roaming\Lens\extension-store\lens-telemetry\preferences-store.json
info: [EXTENSION]: enabled<EMAIL_ADDRESS>error: [Metrics]: metrics not available {"error":{"name":"StatusCodeError","statusCode":403.....

There is no proxy server set in file lens-cluster-store.json for communication with API server. There is only proxy server set in lens-user-store.json to be able to download kubectl.exe in required cluster version. From my point of view, everything is setup correctly. To be sure, I even switched off any proxy settings on Windows machine where Lens is running (so there is no HTTP or HTTPS_PROXY set anywhere neither in the windows configuration) and I even removed proxy from lens-user-store.json file. Still the call is routed to proxy and I can see error as in above log output. Could you please help me understand, how exactly is the call to Prometheus formed? If all other calls to API server are proxied correctly, I do not get it why for Prometheus it would be different, unless the call is also done differently. Thank you.

The reason why Lens cannot access metrics may be due to the networkpolicy configuration.
If strict internal security configurations are not needed, you can test removing it by running:
kubectl delete -f manifests/prometheus-networkPolicy.yaml

or
kubectl delete networkpolicy prometheus-k8s -n monitoring

I'm also looking for a way to individually configure the ingress policy for lensapp.


📝  New Collection CSS Frameworks

Thank you for contributing! Please confirm this pull request meets the following requirements:

[x] I followed the contributing guidelines: https://github.com/github/explore/blob/master/CONTRIBUTING.md
[x] I have no affiliation with the project I am suggesting (as a maintainer, creator, contractor, or employee).

Which change are you proposing?

[ ] Suggesting edits to an existing topic or collection
[x] Curating a new topic or collection
[ ] Something that does not neatly fit into the binary options above

Curating a new topic or collection

[x] I've formatted my changes as a new folder directory, named for the topic or collection as it appears in the URL on GitHub (e.g. https://github.com/topics/[NAME] or https://github.com/collections/[NAME])
[x] My folder contains a *.png image (if applicable) and index.md
[x] All required fields in my index.md conform to the Style Guide and API docs: https://github.com/github/explore/tree/master/docs

A CSS framework is a set of tools that help you build websites. And People Spend Long Time Finding The Perfect One For Them

Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.

Hi @gallexi I amde the changes you were asking for. Please review the changes and let me know for some issues or modifications

Perfect. Thanks for contributing! 🙌🏻

Thanks For Accepting My Contribution @smashwilson and @gallexi

Okay thank you 😊


pgcluu -o report generation

When generating reports, if the directory has existing HTML reports, displays output directory is not empty.    Is there command line switches to overwrite the older HTML reports?

No, in this mode you have to remove the directory content by hand before running pgcluu again but if you want to preserve all your report you can use the incremental mode.
Run pgcluu_collectd with the --rotate-daily this will enable the incremental mode and pgcluu will create a tree of subdirectory per day. Then run pgcluu as usual.
Is that what you was looking for?

I would like to run pgcluu_collectd to collect statistics every 15 minutes or so.  Once new statistics are collected, I would like to generate the new reports to publish the HTML.
pgcluu_collectd will overwrite the older statistics files (csv), but when using pgcluu -o {output_report} {input_dir} when the {output_report} directory contains HTML files.

error message stating output directory is not empty.

Yes this is a limitation of the current implementation. But what you can try is running pgcluu_collectd in daemon mode and keep it running all the day. Running it each 15 minutes seems to me to have no interest. Try the following, run pgcluu_collectd in daemon and incremental mode:
/usr/local/bin/pgcluu_collectd -D --rotate-daily /var/lib/pgcluu_data/

it will run all the time until you reboot the machine or there is not enough space in the /var/lib/pgcluu_data/ output directory or you kill it using: /usr/local/bin/pgcluu_collectd -k
Then run pgcluu each 15 minutes by cron as follow:
*/15 * * * * /bin/rm -rf /var/www/pgcluu/*; /usr/local/bin/pgcluu -o /var/www/pgcluu/ /var/lib/pgcluu_data/`date +%Y/%m/%d`

This will rebuild the report of the current day each 15 minutes. This is not really optimum but this is the only way you can use it with the static HTML output. If you have an httpd server on the host where pgcluu is used you can use the CGI mode which allow you to have a full dynamic web interface to look at statistics over the time. This is a work in progress but it works so if you want to try I can help you to setup  your installation.
Regards,

In next major release it will be possible to received alert when some warning and critical threshold will be reached. This is on my todo list.

Thanks again, but for now if you implement as you directed above, this will provide information/details on the progress cluster every 'xx' minutes

correction, if 'we' implement as your directed above...

Yes you will have the information/details on the progress cluster every 'xx' minutes with graphs showing the  full day statistics history. This is mandatory to understand how issues appears. If you just run it each 'xx' minutes without incremental mode you will have only the statistics at the time you've ran it.


⚠ SkipTheCommericals has degraded performance

In 3b81522, SkipTheCommericals ($STC) experienced degraded performance:

HTTP code: 200
Response time: 2774 ms

Resolved: SkipTheCommericals performance has improved in e24173b.


Unable to create only listener with 443 ( its creating both 80 and 443)

Describe the bug
We are trying to create a ingress with only 443 enabled but its creating listeners with both 80 and 443. According to our security team, we are not allowed to create listeners with 80 port.
To Reproduce
deploying simple ingress will happen.

Would be great if we develop any annotations that can create only mentioned listener like 80 or 443

Are you using ssl-redirect annotation in your ingress ? That would open port 80 for redirection to 443.


Migrate from the webidl crate to weedle

This commit migrates the wasm-bindgen-webidl crate from the webidl parser to
weedle. The main rationale for doing this is that webidl depends on
lalrpop, which is quite a large dependency and takes a good deal of time to
compile. The weedle crate, however, depends on nom and is much faster to
compile.
Almost all translations were pretty straightforward. Some abstractions changed
and/or were introduced in this commit when moving to weedle like the
ToSynType trait, but otherwise the generated bindings should be the same. It's
been verified that the weedle-generated bindings are exactly the same as the
webidl-generated bindings, with the one exception of weedle generates one
more method, WebGpuCommandEncoder::transition_buffer. It's not clear currently
why webidl didn't generate this method, as its idl is pretty straightforward!
This commit is using a fork of weedle currently which has a number of fixes
for parsing our WebIDL, although all the fixes are quite minor!
Closes #620

cc @ohanar, curious to get your take on this!

@csharad would you still be up for transferring the weedle crate to us?

@alexcrichton Absolutely, I would be happy to. To whom should I transfer it to?

@csharad ok great! You can transfer it to me and I'll transfer it to the rustwasm organization.

@alexcrichton You already have a weedle repo, I could not transfer.

oops, deleted now!

@alexcrichton What about the crate ownership?

Thanks @csharad! I've transferred the repository to https://github.com/rustwasm/weedle, set up @rustwasm/weedle as a team, and have added you, me, fitzgen, and @ohanar on the team!
@csharad also, mind adding me as an owner on crates.io?

@alexcrichton Sent you the request.

@csharad ah I don't see it on crates.io :(

Ok great, got it now! And the team is also added as an owner -- https://crates.io/crates/weedle

You probably also want to update links the repository and the homepage.