Add high quality glow mode

Fixes: https://github.com/godotengine/godot/issues/32030
Previously, during downsample, every second row was ignored. Now, when high-quality is used, we sample two rows at once to ensure that no pixel is missed. It is slower, but looks much better and has a much high stability while moving.
High quality also takes an additional horizontal sample the width of the horizontal blur matches the height of the vertical blur.
The scene below contains a sphere and the axis gizmos. Note that the glow from the sphere is no longer elongated and the glow from the single pixel line is smooth.
Regular:

High quality:

20:58 <reduz> Akien: I think it should be technically possible to do with less reads by using texture filter, but i doubt performance will be very affected anyway
20:58 <reduz> Akien: so I would merge I guess for now

Thanks!


fix: NW-4074 changed CA from "rds-ca-2019" to "rds-ca-rsa2048-g1"

Description

Changed CA from "rds-ca-2019" to "rds-ca-rsa2048-g1"
Motivation and Context

It creates inconsistence in the deployment of new RDS and breaks the jenkins pipeline of infrastructure

NW-4074
Breaking Changes

How Has This Been Tested?

[ ] I have updated at least one of the examples/* to demonstrate and validate my change(s)
[x] I have tested and validated these changes using one or more of the provided examples/* projects

#tested manually with terragrunt
➜  test git:(main) ✗ terragrunt plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.
data.terraform_remote_state.base_infrastructure: Refreshing state...
data.aws_ssm_parameter.db_password: Refreshing state...
module.rds_db.module.db_instance.data.aws_iam_policy_document.enhanced_monitoring: Refreshing state...
module.rds_db.module.db_parameter_group.aws_db_parameter_group.this_no_prefix[0]: Refreshing state... [id=squirrel-db-test]
data.aws_security_group.default[0]: Refreshing state...
data.aws_security_group.default[1]: Refreshing state...
module.rds_db.module.db_subnet_group.aws_db_subnet_group.this_no_prefix[0]: Refreshing state... [id=squirrel-db-test]
aws_security_group.this[0]: Refreshing state... [id=sg-05025d0e0d5432ad3]
module.rds_db.module.db_instance.aws_db_instance.this[0]: Refreshing state... [id=squirrel-db-test]

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement
Terraform will perform the following actions:
module.rds_db.module.db_instance.aws_db_instance.this[0] is tainted, so must be replaced
-/+ resource "aws_db_instance" "this" {
~ address                               = "squirrel-db-test.cojrrbnlokhb.eu-central-1.rds.amazonaws.com" -> (known after apply)
allocated_storage                     = 50
allow_major_version_upgrade           = false
apply_immediately                     = true
~ arn                                   = "arn:aws:rds:eu-central-1:256612512925:db:squirrel-db-test" -> (known after apply)
auto_minor_version_upgrade            = false
~ availability_zone                     = "eu-central-1c" -> (known after apply)
backup_retention_period               = 7
backup_window                         = "02:00-02:30"
ca_cert_identifier                    = "rds-ca-rsa2048-g1"
+ character_set_name                    = (known after apply)
copy_tags_to_snapshot                 = false
db_subnet_group_name                  = "squirrel-db-test"
delete_automated_backups              = true
deletion_protection                   = true
enabled_cloudwatch_logs_exports       = [
"postgresql",
"upgrade",
]
~ endpoint                              = "squirrel-db-test.cojrrbnlokhb.eu-central-1.rds.amazonaws.com:5432" -> (known after apply)
engine                                = "postgres"
engine_version                        = "15.6"
~ hosted_zone_id                        = "Z1RLNUO7B9Q6NB" -> (known after apply)
iam_database_authentication_enabled   = false
~ id                                    = "squirrel-db-test" -> (known after apply)
identifier                            = "squirrel-db-test"
+ identifier_prefix                     = (known after apply)
instance_class                        = "db.t3.small"
~ iops                                  = 3000 -> 0
+ kms_key_id                            = (known after apply)
~ license_model                         = "postgresql-license" -> (known after apply)
maintenance_window                    = "sat:02:30-sat:03:00"
max_allocated_storage                 = 0
monitoring_interval                   = 0
+ monitoring_role_arn                   = (known after apply)
multi_az                              = false
+ name                                  = (known after apply)
~ option_group_name                     = "default:postgres-15" -> (known after apply)
parameter_group_name                  = "squirrel-db-test"
password                              = (sensitive value)
performance_insights_enabled          = false
+ performance_insights_kms_key_id       = (known after apply)
~ performance_insights_retention_period = 0 -> (known after apply)
port                                  = 5432
publicly_accessible                   = false
~ replicas                              = [] -> (known after apply)
~ resource_id                           = "db-FH563T6VEHOV53F5JQEANL5VRA" -> (known after apply)
- security_group_names                  = [] -> null
skip_final_snapshot                   = true
~ status                                = "available" -> (known after apply)
storage_encrypted                     = false
storage_type                          = "gp3"
tags                                  = {
"Application"       = "squirrel"
"Environment"       = "test"
"KubernetesCluster" = "eks-t0003"
"Name"              = "squirrel-db-test"
"Owner"             = "crossdomain"
"Resource"          = "db"
"Service"           = "squirrel"
"Team"              = "backend"
}
+ timezone                              = (known after apply)
username                              = "postgres"
vpc_security_group_ids                = [
"sg-05025d0e0d5432ad3",
]
    timeouts {
        create = "40m"
        delete = "40m"
        update = "80m"
    }
}

Plan: 1 to add, 0 to change, 1 to destroy.

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
Releasing state lock. This may take a few moments...

[ ] I have executed pre-commit run -a on my pull request

This PR was an error


[admin]: rename source/server/http to source/server/admin

As part of the refactoring work for #5505, we decided to rename the source/server/http dir to source/server/admin.

@jmarantz the CI failure doesn't seem related to my changes: the failing integration test completes successfully when I execute it locally. Could you maybe re-trigger the build pipeline?

/retest


Date-picker keyboard navigation is broken when NVDA is on and in Browse Mode

Start NVDA Screen reader in Browse mode
Try to navigate the calendar using the arrow keys

Left/Right do not function properly and screen reader reads not relevant text
Up/Down can be used to navigate left or right instead of up/down.

This can be seen in the examples in the clarity documentations page with NVDA screen reader turned on: https://clarity.design/documentation/datepicker
Simple adjustment of element roles might fix the issue.

@chlane do we target this and are there any known related issues about the datepicker?
Thanks

Hi @itaneva, It appears to be working correctly with the browsers we recommend for using Clarity.  I'm not sure what browser you were using with NVDA, but for Clarity we recommend using Firefox/NVDA or Safari/VoiceOver.
This is documented at vmware-clarity-design-system-vpat-2.2.pdf and pasted below.
Clarity Design System is best experienced on:
• Safari and VoiceOver running on the macOS operating system
• Firefox and NVDA running on the Windows operating system

I recommend adding this information in a prominent location when the new website is created.
Regarding the expected behavior.  When using either of of these combinations you should find that dates are accessible with either standard cursor navigation i.e,  up or down arrows with NVDA and  Ctrl + Option + left/right arrow keys for VoiceOver. You can also use table navigation commands with NVDA i.e. Ctrl + Alt + arrow keys.

Closing based on the comment by Chris above


FAQ

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.

[ x] Successful preview build.

 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.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663151c334aa69266e62dc31--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663156739a01dd1f37e98384--harness-developer.netlify.app

Due to the volume of FAQ prs moving today and merge conflicts happening, I am going to quickly review the CD FAQs and then merge this. We have too many open FAQ PRs and conflicts happening.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6631626134aa69345262dc73--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://663163400f3c583027fc0bff--harness-developer.netlify.app

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6631687ea8a5f234051172d2--harness-developer.netlify.app


matplotlib: missing types

Do I understand correctly that Pylance bundles type stub files for popular libraries like matplotlib?
I get type errors for some things and I wonder if they are just missing from the bundled stub files.
For example, it doesn't recognize that Axes objects have a clear method and this import gives an error:
import matplotlib.animation as animation

Can I add my own versions of these stub files in the typings subdirectory of my project to override them?
If so, what file names do they need to have?

Yes, it does, and the matplotlib stubs aren't fully complete yet.
You can override them by adding typings/matplotlib, and the folder structure in there, or install a package that overrides them. The bundled stubs are read last overall (typings, installed stubs, original code).

Oops! @jakebailey I guess you didn't want to close this yet. I reopened it.

Yes, I need to find some time to fix the matplotlib stubs.

@jakebailey   can you response  my issue #301, i think this issue is a big problem.

This issue has been fixed in version 2021.3.0, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202130-3-march-2021


ConnectionResetError(54, 'Connection reset by peer') when ping works completely fine

Hi,
I'm trying to connect to a sonos speaker (obviously lol) using the soco library.
I'm trying to run this, and I get an error requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionResetError(54, 'Connection reset by peer'))
from soco import SoCo

speaker = SoCo("<local_ip>")
print(speaker.player_name)

running ping <local_ip> works completely fine
here's the complete stacktrace:
Stacktrace

Traceback (most recent call last):
  File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/urllib3/connectionpool.py", line 789, in urlopen
    response = self._make_request(
               ^^^^^^^^^^^^^^^^^^^
  File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/urllib3/connectionpool.py", line 536, in _make_request
    response = conn.getresponse()
               ^^^^^^^^^^^^^^^^^^
  File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/urllib3/connection.py", line 464, in getresponse
    httplib_response = super().getresponse()
                       ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/rohangodha/.local/share/uv/python/cpython-3.12.5-macos-aarch64-none/lib/python3.12/http/client.py", line 1428, in getresponse
    response.begin()
  File "/Users/rohangodha/.local/share/uv/python/cpython-3.12.5-macos-aarch64-none/lib/python3.12/http/client.py", line 331, in begin
    version, status, reason = self._read_status()
                              ^^^^^^^^^^^^^^^^^^^
  File "/Users/rohangodha/.local/share/uv/python/cpython-3.12.5-macos-aarch64-none/lib/python3.12/http/client.py", line 300, in _read_status
    raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/requests/adapters.py", line 667, in send
resp = conn.urlopen(
^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/urllib3/connectionpool.py", line 843, in urlopen
retries = retries.increment(
^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/urllib3/util/retry.py", line 474, in increment
raise reraise(type(error), error, _stacktrace)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/urllib3/util/util.py", line 38, in reraise
raise value.with_traceback(tb)
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/urllib3/connectionpool.py", line 789, in urlopen
response = self._make_request(
^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/urllib3/connectionpool.py", line 536, in _make_request
response = conn.getresponse()
^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/urllib3/connection.py", line 464, in getresponse
httplib_response = super().getresponse()
^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/.local/share/uv/python/cpython-3.12.5-macos-aarch64-none/lib/python3.12/http/client.py", line 1428, in getresponse
response.begin()
File "/Users/rohangodha/.local/share/uv/python/cpython-3.12.5-macos-aarch64-none/lib/python3.12/http/client.py", line 331, in begin
version, status, reason = self._read_status()
^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/.local/share/uv/python/cpython-3.12.5-macos-aarch64-none/lib/python3.12/http/client.py", line 300, in _read_status
raise RemoteDisconnected("Remote end closed connection without"
urllib3.exceptions.ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/rohangodha/Coding/sonos/script.py", line 14, in
print(speaker.player_name)
^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/soco/core.py", line 392, in player_name
self.zone_group_state.poll(self)
^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/soco/core.py", line 1613, in zone_group_state
zgs = self.zone_group_states.get(self.household_id)
^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/soco/core.py", line 442, in household_id
self._household_id = self.deviceProperties.GetHouseholdID()[
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/soco/services.py", line 207, in _dispatcher
return self.send_command(action, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/soco/services.py", line 474, in send_command
args = self.compose_args(action, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/soco/services.py", line 334, in compose_args
for action in self.actions:
^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/soco/services.py", line 682, in actions
self._actions = list(self.iter_actions())
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/soco/services.py", line 708, in iter_actions
scpd_body = requests.get(self.base_url + self.scpd_url, timeout=10).content
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/requests/api.py", line 73, in get
return request("get", url, params=params, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/requests/api.py", line 59, in request
return session.request(method=method, url=url, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/requests/sessions.py", line 589, in request
resp = self.send(prep, **send_kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/requests/sessions.py", line 703, in send
r = adapter.send(request, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/rohangodha/Library/Caches/uv/archive-v0/OqGyAg4weCpbpk7kS6Mt7/lib/python3.12/site-packages/requests/adapters.py", line 682, in send
raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))

python 3.12.5, OpenSSL 3.0.14 4 Jun 2024, and I've tried installing "requests[security]" already.
I've also tried python 3.8-3.12 and none have worked. I'm on macos 14.3
any ideas on what the issue could be?

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

Hi:
SoCo calls are generally HTTP, not HTTPS. Could you confirm HTTP connectivity to the speaker, e.g.:
curl http://<IP_ADDRESS>:1400/xml/device_description.xml

Replace the IP address with that of your speaker.

I can't connect to port 80 (with curl) -- I'm just going to put this issue up to my university network having weird firewall settings. Thanks for your help!


Raspberry Pi 2?

Is there anyway that this can work on the Raspberry Pi 2B?
Could I run it on qemu?

@RustiRabbit you can run the OS on qemu, check this issue for details. You can also check answers to the exercises for some working samples link
You can't run the OS on Raspberry Pi 2

Thanks for letting me know 😊
From: Sergey Matyukevich<EMAIL_ADDRESS>Sent: Sunday, 10 February 2019 4:48 AM
To: s-matyukevich/raspberry-pi-os<EMAIL_ADDRESS>Cc: Oscar Stickland<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [s-matyukevich/raspberry-pi-os] Raspberry Pi 2? (#117)
@RustiRabbithttps://github.com/RustiRabbit you can run the OS on qemu, check thishttps://github.com/s-matyukevich/raspberry-pi-os/issues/8 issue for details. You can also check answers to the exercises for some working samples linkhttps://github.com/s-matyukevich/raspberry-pi-os/tree/master/exercises/lesson01/4
You can't run the OS on Raspberry Pi 2
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/s-matyukevich/raspberry-pi-os/issues/117#issuecomment-462064457, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AS9iNN-pXJnCKejvDbjvmhopmtueuw5yks5vLwnMgaJpZM4axwKe.


Razor Components - onclick handler not called if href is set in  tag

Describe the bug
Href attributes take precedence over click handlers in razor components for  tags
To Reproduce
Steps to reproduce the behavior:

Create a new blazor app (server or client side - happens on both)
Edit the Pages/Counter.razor file's button
from

<button class="btn btn-primary" onclick="@IncrementCount">Click me</button>

to
Click me

Instead of incrementing the counter, it will now jump to the "#" url, navigating to the home page

Expected behavior
Increment the counter as it did before
Additional context
Installed dotnet version:
dotnet 3.0.100-preview4-011223

I believe this is the default behavior of opening a new page, and, since you've got no such url, the default behavior of the Blazor routing system is to navigate to the home page.
Try to return false from your click event.
Try either of these:
Click me
 IncrementCount());return false">Click me
Hope this works...

Unfortunately, it fails because it doesn't call the handler at all.
You could test this by writing a Console.WriteLine() in the handler and preserving the log: the handler is never called

According to this https://github.com/aspnet/Blazor/pull/937 pull request, .preventDefault() is no longer called when you click on a link.

So it looks like we can fix #803 and all related issues trivially just be removing the event.preventDefault call. It doesn't appear to affect anything else negatively (...)

It is something you will be able to do in 3.0.0-preview6 according to this https://github.com/aspnet/AspNetCore/issues/5545 issue.
In the meantime, if it is possible in your situation, you can remove the href="#" from your tag and the event works again.

Thanks @rjmr97, I'll close this ticket now as that one clearly covers this


Cannot install v3.24.1 Operator via Helm on 1.25 on Bare Metal - PodSecurityPolicy Error

Tigera Operator only partially installs on bare metal cluster running K8S 1.25
Expected Behavior
Calico starts and Pods have networking
Current Behavior
The Tigera Operator partially initializes, but fails due to a PodSecurityPolicy error.

I0912 17:06:02.583526       1 leaderelection.go:258] successfully acquired lease tigera-operator/operator-lock
{"level":"info","ts":1663002362.5837798,"logger":"controller.apiserver-controller","msg":"Starting EventSource","source":"kind source: /, Kind="}
{"level":"info","ts":1663002362.5838342,"logger":"controller.apiserver-controller","msg":"Starting EventSource","source":"kind source: /, Kind="}
...
{"level":"info","ts":1663002364.8686397,"logger":"controller_installation","msg":"adding active configmap"}
{"level":"info","ts":1663002364.8734193,"logger":"status_manager.apiserver","msg":"Status manager is not ready to report component statuses."}
{"level":"info","ts":1663002364.8735664,"logger":"status_manager.calico","msg":"Status manager is not ready to report component statuses."}
{"level":"error","ts":1663002366.273236,"logger":"controller_installation","msg":"ResourceUpdateError","Request.Namespace":"","Request.Name":"calico","ResourceUpdateError":"Error creating / updating resource","error":"no matches for kind \"PodSecurityPolicy\" in version \"policy/v1beta1\"","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:253\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:214"}
{"level":"error","ts":1663002366.2733328,"logger":"controller.tigera-installation-controller","msg":"Reconciler error","name":"calico","namespace":"","error":"no matches for kind \"PodSecurityPolicy\" in version \"policy/v1beta1\"","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.9.7/pkg/internal/controller/controller.go:214"}

➜  fleet-infra git:(main) ✗ kubectl -n tigera-operator get all
NAME                                   READY   STATUS    RESTARTS   AGE
pod/tigera-operator-6bb888d6fc-h8wc2   1/1     Running   0          9m16s

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/tigera-operator   1/1     1            1           9m17s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/tigera-operator-6bb888d6fc   1         1         1       9m17s
➜  fleet-infra git:(main) ✗ kubectl -n calico-system get all
NAME                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/calico-typha   ClusterIP   <IP_ADDRESS>   <none>        5473/TCP   8m56s

Your Environment

Bare Metal nodes
CentOS 8 Stream

I think there may have been user error here. I've rebuilt my cluster and I'm working on a fresh install of the Tigera Operator via Helm. I still don't have it working, but I'll file a new bug if I get to that point. I don't think I could reproduce this at this point.


20 generate docker image

Fixes #20 .
This pull request creates a .Dockerfile plus updates the documentation.
I have created #47 to investigate creation of official package.
This pull request is created from 12-generate-pip-package branch.

It is ready for review. @PiotrAniola82 @tjanasiewicz can you review it?
There are changes only in the following files:
Created Dockerfile
Added some documentation to Contributing.md and README.md

Automated tests pass on this branch, however, I don't know how to perform functional tests. You wrote you added some documentation to Contributing.md and README.md, but I did not find any mention of Docker in either of these files.

Automated tests pass on this branch, however, I don't know how to perform functional tests. You wrote you added some documentation to Contributing.md and README.md, but I did not find any mention of Docker in either of these files.

Search for "container" word instead: "Build container localy" or "Running container image".
I used Podman in my examples, however Docker commands will be the same


Trait 'Slim\CallableResolverAwareTrait' not found

Hey guys,
I have just downloaded Stable version of Slim3.0.0 available on git, And tried to configure it.
Source Code:
require '../Slim/App.php';
\Slim\Slim::registerAutoloader();
$app = new Slim\App();
$app->get('/', function ($request, $response, $args) {
$response->write("Welcome to Slim!");
return $response;
});
$app->get('/hello[/{name}]', function ($request, $response, $args) {
$response->write("Hello, " . $args['name']);
return $response;
})->setArgument('name', 'World!');
$app->run();
When i tried to run it. it's giving  "PHP Fatal error:  Trait 'Slim\CallableResolverAwareTrait' not found in ............../app/services/Slim/App.php on line 49".
Please Help.

Use composer.

Hi akrabat,
Thanks for your quick response,
I am unable to use SSH in my server because i am using shared hosting, So they will not provide me SSH access,
Is there any other way to make it work? I have used your previous release on the same server without using composer. So i am sure there would be another way.
Please help me with it.
Thanks,
Ajay Kumar

You don't need SSH to use Composer. You use Composer locally and FTP the files to your server.

Thanks :+1:

@akrabat What if I don't want to use composer?

@TrySound: Download all the dependencies and put them in your project & then write your own autoloader.

Serious? Well, it's not a good point in v3 release. :(

Composer is the PHP dependency manager. Slim v3 has dependencies and so it uses Composer to manage them. I'm unsure why this could ever be a problem.

Because of community misconception that you need to actual run composer command on your production server (which is not possible for shared servers). Take a look at @akrabat's article if you want to use Slim 3 on shared server https://akrabat.com/using-composer-with-shared-hosting/


simple: add Disease, SequenceVariant mappings

I think it shouldn't need much discussion / can merge quickly…

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.831%

Totals

Change from base Build 972320854:
0.0%

Covered Lines:
439

Relevant Lines:
444

💛  - Coveralls


Uncaught Error: ENOENT: no such file or directory, lstat '/atom:'

Really just saved an edited file after updating to the latest version of the plugin.

Atom Version: 1.6.0
System: Mac OS X 10.11.3
Thrown From: go-config package, v1.1.2
Stack Trace
Uncaught Error: ENOENT: no such file or directory, lstat '/atom:'
At /Applications/Atom.app/Contents/Resources/app.asar/src/pane.js:896

Error: ENOENT: no such file or directory, lstat '/atom:'
    at Error (native)
    at fs.lstatSync (fs.js:844:18)
    at Object.fs.lstatSync (ATOM_SHELL_ASAR.js:189:16)
    at Object.realpathSync (fs.js:1454:21)
    at Object.fs.realpathSync (ATOM_SHELL_ASAR.js:262:29)
    at Executor.execSync (/Users/afisk/.atom/packages/go-config/lib/executor.js:37:24)
    at Formatter.format (/Users/afisk/.atom/packages/gofmt/lib/formatter.js:289:29)
    at /Users/afisk/.atom/packages/gofmt/lib/formatter.js:99:14
    at Function.module.exports.Emitter.simpleDispatch (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:25:14)
    at Emitter.module.exports.Emitter.emit (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:125:28)
    at TextBuffer.module.exports.TextBuffer.saveAs (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1051:20)
    at TextBuffer.module.exports.TextBuffer.save (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/text-buffer/lib/text-buffer.js:1043:19)
    at TextEditor.module.exports.TextEditor.save (/Applications/Atom.app/Contents/Resources/app.asar/src/text-editor.js:629:26)
    at Pane.module.exports.Pane.saveItem (/Applications/Atom.app/Contents/Resources/app.asar/src/pane.js:613:18)
    at Pane.module.exports.Pane.saveActiveItem (/Applications/Atom.app/Contents/Resources/app.asar/src/pane.js:596:19)
    at Workspace.module.exports.Workspace.saveActivePaneItem (/Applications/Atom.app/Contents/Resources/app.asar/src/workspace.js:673:35)
    at atom-workspace.commandRegistry.add.core:save (/Applications/Atom.app/Contents/Resources/app.asar/src/register-default-commands.js:205:32)
    at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/Applications/Atom.app/Contents/Resources/app.asar/src/command-registry.js:260:29)
    at /Applications/Atom.app/Contents/Resources/app.asar/src/command-registry.js:3:61
    at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:570:16)
    at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/atom-keymap/lib/keymap-manager.js:378:22)
    at WindowEventHandler.module.exports.WindowEventHandler.handleDocumentKeydown (/Applications/Atom.app/Contents/Resources/app.asar/src/window-event-handler.js:97:36)
    at HTMLDocument.<anonymous> (/Applications/Atom.app/Contents/Resources/app.asar/src/window-event-handler.js:3:61)

Commands
     -2:20.3.0 find-and-replace:show (atom-text-editor.editor.is-focused)
  2x -2:18.7.0 core:confirm (atom-text-editor.editor.mini.is-focused)
  2x -2:12.3.0 core:copy (atom-text-editor.editor.is-focused)
     -1:00.7.0 core:paste (atom-text-editor.editor.is-focused)
     -0:52.7.0 editor:newline (atom-text-editor.editor.is-focused)
  3x -0:47.2.0 core:move-down (atom-text-editor.editor.is-focused.autocomplete-active)
     -0:44.8.0 autocomplete-plus:confirm (atom-text-editor.editor.is-focused.autocomplete-active)
  2x -0:40.1.0 core:save (atom-text-editor.editor.is-focused)

Config
{
  "core": {}
}

Installed Packages
# User
autocomplete-go, v1.0.4
environment, v1.1.1
go-config, v1.1.2
go-get, v1.0.1
go-plus, v4.0.1
gofmt, v1.0.3
gometalinter-linter, v1.0.3
gorename, v1.0.0
linter, v1.11.3
navigator-godef, v1.0.2
tester-go, v1.0.1

# Dev
No dev packages

+1

What is the contents of your PATH? Could you type ⌘-option-i, go to the "console" tab, type process.env.PATH, and copy the resulting text into the issue?

Uncaught TypeError: Cannot read property 'PATH' of undefined
at :2:12
at Object.InjectedScript._evaluateOn (:904:140)
at Object.InjectedScript._evaluateAndWrap (:837:34)
at Object.InjectedScript.evaluate (:693:21)

I added your package and did NOT restart Atom.

Running in a git environment, where git may be modifying files out from under me.

Is anyone open to doing a screensharing session? I would love to see this with my own eyes, as I have been unable to replicate the issue. If so, head over to #go-plus on either Slack team, and DM me your email address.

OK, with the help of @jmrobison we've identified root cause. The issue occurs when you have atom://config added as a project folder. atom://config is better known as the settings dialog; and this occurs when you open the settings dialog via the Atom > Preferences link and then close Atom; Atom will then open up with a config project folder.
gofmt is caching the location of gofmt for each project folder, and obviously atom://config is not a valid path. A fix is forthcoming.


License?

What license is this code provided under? May I humbly suggest MIT/public domain? I have a project I'd love to consider using this as a base for, but should ideally know the license first.

MIT license works for me, just added!


ci: Skip public key check when run by dependabot.

Dependabot does not have access to secrets unless explicitly set in the secrets configuration.
As it will never touch the public key, we skip this job rather than giving unneeded access.
Fixes: 7c004217391a ("Add Inspektor Gadget public key to source.")

Dependabot does not have access to secrets unless explicitly set in the secrets configuration.

What's happens with external contributions, isn't it the same case?

I guess it does not occur with them, as we (maintainers) decide to run the pipeline, so it should be able to access secrets like us.

It won't work as stated in https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow :

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

I tried it out on https://github.com/inspektor-gadget/inspektor-gadget/actions/runs/7277762855/job/19830526937?pr=2321 and it fails. So I think we need to restrict it to only runs on PRs from this repository.


Tracing does not work well in Cloud Run with TimedBuffer

I have a Cloud Run service behind Cloud Load Balancer. The service is a .NET Core API, utilizing this library to log traces.
If I send 5 concurrent requests, only one gets traced. This is confirmed by checking the Trace List in the Cloud Console, and also the HTTP responses - only the first response has a X-Cloud-Trace-Context header. If I send the 5 requests, but wait for the previous one to complete before sending the next, all 5 get traced. I looked through the options and I tried specifying BufferOptions.NoBuffer() in UseGoogleDiagnostics, but that didn't seem to make a difference. Am I missing something, or could this be a bug?

We'll look at this on Tuesday - Monday is a public holiday in the UK.

@EatonZ Can you provide a minimum but full application that reproduces the problem for you? We do have some tests around concurrent tracing and logging and they seem to work.

@amanda-tarafa Here you go. It's a lot (sorry!), but it does reproduce the problem.
Please make sure you have gcloud installed and authenticated. You should also have the latest PowerShell. The built-in Windows version may not work. Finally, make sure Docker Desktop is installed and running.

Download pack and copy beside the .sln file.
Create a new GCP project so you can easily dispose of everything when done. Enable the Run and Compute APIs, and create an Artifact Registry repo named ez-sample.
Open GoogleBuild.ps1 in Notepad, put in your project ID at the top, and create/put in a service account (give it the Cloud Trace Agent role).
In GoogleCreateLoadBalancer.ps1, put in your project ID at the top.
Create an IP here. Premium, IPv4, Global, named ez-sample-ip.
Run these 2 commands:
gcloud auth configure-docker "us-docker.pkg.dev"
gcloud auth print-access-token | docker login --username "oauth2accesstoken" --password-stdin "https://us-docker.pkg.dev"
Run GoogleCreateLoadBalancer.ps1 and GoogleBuild.ps1. It may get stuck on Adding label 'io.buildpacks.project.metadata' for a while the first time - just wait it out. Once both finish successfully, wait a few minutes for the load balancer to fully set up.
Use Fiddler, Postman, or whatever to send 5 HTTP (not HTTPS) requests concurrently to https://[ez-sample-ip]/hello. There are 2 problems you should see. First, when you send the first batch of 5 requests to wake the Cloud Run service, all the responses have a X-Cloud-Trace-Context header, but nothing shows in Trace List. When you send a second batch of 5 requests, only the first one will have a X-Cloud-Trace-Context header, and it will show in Trace List.

If you look at the project, I am using a third-party REST framework. I couldn't use FromServicesAttribute per your example, so they gave me a solution and it works, just not concurrently. Not sure if the bug is with your library or theirs.
Thank you in advance for taking a look!
SampleApp.zip

@EatonZ this is far from a simple project and what's really a problem for me tu use it to help you diagnose is the several external dependencies, we don't have control over what those do, don't have the code, don't have experience with those, etc. So, let's try to simplify this so I can actually try and use it to confirm or not whether there's a problem with the Diagnostics libraries.
We have many integration tests that either rely on or explicitly test concurrent tracing and all of those are passing as expected. You can see one of those here. Mind you, I'm not saying there's no problem, I'm just saying that I'm pretty certain that concurrent tracing works well for most cases.
It would be good if you started from a stripped down ASP.NET Core 3 project, with just the Diagnostics dependency, no docker, etc. and build from there. Test with each of the individual pieces separately and if all keeps working, then start mixing dependencies in pairs, etc. I understand this is cumbersome, but it's really the only way to get the minimum application that reproduces the problem which is really what we need to properly diagnose.
Also, a couple of things you can try inmediately:

Configure tracing as described in Troubleshooting Tracing. You create the trace options in the same way as described there and pass them to the UseGoogleDiagnostics() call.

It's possible that you are not seing all the traces because the buffer hasn't flushed when you look.
It's possible that there's an exception being thrown by tracing, by default we don't propagate exceptions because we believe we shouldn't break an application if tracing fails.

In the same trace options set the qps to double.PositiveInfinity to make sure that all requests are traced. It's possible that you are not seing all the traces because of the default qps value.

My gut feeling is that this has to do with the custom framework you are using. We support and depend on ASP.NET Core 3, if that custom framework is in any way modifying or intercepting the standard ASP.NET Core 3 pipeline, then I wouldn't be surprised if tracing doesn't work properly. The fact that you can't use ASP.NET Core 3 standard dependency injection mechanism makes think that they are, indeed, intercepting the standard pipeline.

@amanda-tarafa Thanks for your in-depth reply!
I have done some testing today and have uncovered interesting results.
I solved the problem where the trace header wasn't being added to my 5 responses. I needed to set qpsSampleRate to double.PositiveInfinity. I thought the default, 1.0, meant trace everything like it does in other GCP configurations, but that was not the case here. Oops.
The second problem is where the traces do not appear in the Trace List. This one is a bit harder to pin down. It seems that on Cloud Run container start, the trace method calls cause the sandbox to crash, and each HTTP request ends up taking 3-4 seconds longer than usual (due to the sandbox restarting after crashing, I presume). Due to the crash, the traces are not recorded in Trace List. The crash log is shown in Cloud Run logs:

I am still experimenting and may have more to add later.

It appears that simply adding UseGoogleDiagnostics is the minimum to make the sandbox start crashing, and it's not limited to container start, but that's when it happens most frequently.

Alright, I can confirm the problem is reproducible in a standard ASP.NET Core web app, not using any third party libraries besides yours.
Here is the download
To reproduce:

Build/deploy to Cloud Run. Use GCP buildpacks to make it easy.
Initiate 5 requests to /hello in quick succession.
Each response will have a trace header, but will not show in your project's Trace List.
Cloud Run logs will mention the membarrier issue.
At this point, send 1 more request, and this one will go through just fine and be traced.

Please note that this reproduces most of the time, but not all of the time. If the 5 requests are traced successfully, redeploy the container to make the service cold again, and then retry.

That's definitely something I can work with. I'll take a look on Monday and report here as soon as I know more.

@amanda-tarafa Great! One more thing for you, here is a video showing the exact behavior. This is using the sample app I uploaded for you.

I initiate 5 HTTPS requests to my domain (which maps to the Cloud Load Balancer, and then to the Cloud Run service).
Each of those 5 requests takes a long time (note the TTFB column). This appears to be due to the membarrier crash, which you see on the left that I click on. None of these 5 are put into the Trace List. I suppose the crash occurs before your buffer has time to flush.
I send 1 more request after the dust has settled, and it goes through timely, and is properly traced pretty much instantly.

Just a heads up, a couple other things have come up, but this is still on my TODO for this week. I won't be looking at it today though.

So, I've been trying to reproduce this issue for a lot of the afternoon and I haven't been able to.

I used the buildpacks to build my image from your source code, with no changes: pack build --builder=gcr.io/buildpacks/builder web-hello
I tagged and uploaded the web-hello image to my GCP project:docker tag web-hello gcr.io/<my-gcp-project>/web-hello
docker push gcr.io/<my-gcp-project>/web-hello

On the Cloud Run home page I clicked on Create Service and left everything on default execpt for:

The region: I used europe-west1.
I entered a service name of course.
I used the image created and pushed on the previous steps.
I allowed unauthenticated invocations.

For retrying, I redeployed a new revision with no changes every time I needed.
I wrote a small app that sends 5, 10, 15, 20 requests to the endpoint and each time attempts to obtain the traces it expects. I ran the app 10 times right after the service was deployed.

All requests were successfull and took at most a 1300ms, which is not that much given that you are waiting for 900ms in your code.
All traces were written as expected.

I then ran my app again, 10 times again, but this time I didn't wait for the service to finished deploying.

In this scenario the only difference is that the requests took longer overal, around 2.5 seconds, which is normal because they had to wait for the service to finish deploying. All the requests were succesfull all the time and all the traces were correctly written.

I did encounter the membarrier error in the logs, but it leterally says:

"Container Sandbox: Unsupported syscall membarrier(0x0,0x0,0x1b,0x0,0x0,0x1). It is very likely that you can safely ignore this message and that this is not the cause of any error you might be troubleshooting. Please, refer to https://gvisor.dev/c/linux/amd64/membarrier for more information."

So, a few questions for you:

Are you doing anything different? If so, which step from above and what is the difference?
In your last comment you mention that you have a Cloud Load Balancer, can you try without it?
Does the membarrier error message is the same as mine, or is it something less harmless?

I wrote a small app that sends 5, 10, 15, 20 requests to the endpoint and each time attempts to obtain the traces it expects. I ran the app 10 times right after the service was deployed.

Are you sending them all at once, like seen in my example video?

Are you doing anything different? If so, which step from above and what is the difference?

You are pushing the Docker image different (I use pack's --publish), but that should not matter.

In your last comment you mention that you have a Cloud Load Balancer, can you try without it?

Just did, still happens.

Does the membarrier error message is the same as mine, or is it something less harmless?

It's the same.

All requests were successfull and took at most a 1300ms

This is what sticks out to me. It seems like your service could already be warm before you send requests to it? After you deploy the new service, don't send any requests to it until you send the test requests.

I wrote a small app that sends 5, 10, 15, 20 requests to the endpoint and each time attempts to obtain the traces it expects. I ran the app 10 times right after the service was deployed.

Are you sending them all at once, like seen in my example video?

As much as the computer allows me to ;). But yes, separate tasks. And in any case I also tried with fiddler, sending several at a time and with Chrome, hitting F5 :). All worked.

Are you doing anything different? If so, which step from above and what is the difference?

You are pushing the Docker image different (I use pack's --publish), but that should not matter.

I agree it shouldn't matter, I'll still try pack's publish tomorrow, just in case.

All requests were successfull and took at most a 1300ms

This is what sticks out to me. It seems like your service could already be warm before you send requests to it? After you deploy the new service, don't send any requests to it until you send the test requests.

I'm not sending anything before the test requests. On step 5 I just wait for the service to finish deploying. On step 6 I don't even wait for it to be deployed and although requests take longer (as expected), they still go through successfully and the traces are there.

I'm not quite sure why you can't reproduce, but I would like to try a different approach.
I would like to log the result of the call to the GCP PatchTraces API you are doing internally in the library. I don't see any errors in my Cloud Console, so this is really just logging to make sure the API call actually went through. Since 1 API call can have multiple traces, logging the trace IDs would be good too. This way, I can confirm whether this library is actually sending the trace data, or not.
Two questions before I try that:

Is there any internal logging functionality anywhere that would output that information?
If #1 is no, where would be the best spot to insert such logging code?

You can enable gRPC logging and see whether the calls go through or not.

A couple other things you can look at:

To check whether your application is crashing before the diagnostics buffer is flushed, configure tracing to have no buffer and to propagate exceptions as well as shown here Troubleshooting Tracing. If the problem is that it crashes before the buffer is flushed then at least some of the traces should get through. And if the problem is that we are silently catching some exception, then by propagating it the application should really crash and it should show on logs.

When you don't see the traces, do you at least see log entries representing the requests (when you click on the Logs tab on the Service Details page and then click on the top right icon to see the logs on the Logs Viewer). Something like this:

If you expand any of those, they should have a trace property, and the last part of the value is the trace ID. If you copy that ID and paste it on the Trace List page where you can select a trace by ID, does the trace show even if it doesn't show on the list? Wait for an hour or two and try again. If I remember correctly, 90% of trace entries are guarateed to be available in seconds, 95% in minutes, and the rest at some point.

Also, about the application crashing, do you see any evidence of that in the Cloud Run logs. I believe that should be there somehow.

I am still testing, but I wanted to share some results now.
I tried BufferOptions.NoBuffer(). It works so much better. All traces logged consistently, and they show up pretty much instantly in Trace list.
BufferOptions.TimedBuffer just does not seem to work well. Either I see no traces, or they trickle in Trace list very slowly, and I often do not see all of them.
So far, I see no exceptions when ExceptionHandling.Propagate is used in any case.

To answer your questions:

If you expand any of those, they should have a trace property, and the last part of the value is the trace ID. If you copy that ID and paste it on the Trace List page where you can select a trace by ID, does the trace show even if it doesn't show on the list? Wait for an hour or two and try again

Logs always show up fine. I plugged in some trace IDs in the logs from yesterday (almost 24 hours ago) and Trace list says they still do not exist. Out of 7 logs from a batch I sent yesterday, only 1 trace ID actually exists. Very strange.

Also, about the application crashing, do you see any evidence of that in the Cloud Run logs. I believe that should be there somehow.

Nothing more than the membarrier issue. However, I figured out the reason I saw a lot of them. It's the cloud run max instances. If I set that to 1, I will only see 1 log. At this point I am not sure if that is related to the problem.
Looking into gRPC logging now and will provide another comment in a bit.

Thank you for the gRPC logging link. I set the following Cloud Run environment variables:
GRPC_TRACE=http
GRPC_VERBOSITY=DEBUG

It looks like we are on the right track. Here's a portion of the logs that seem interesting:

OK, that's progress, my thoughts:

The Diagnostics library is sending all traces, but we are getting a transport timeout.
The timeout happens on gRPC requests to the Trace API from your CloudRun app, not from mine.
It only seems to happen when a buffer is involved, it works well without a buffer, in which each trace is sent individually.

Conclusions from this:

The problem has nothing to do with concurrent tracing.
The problem is related to the size of the request, when traces are buffered and flushed, they are all sent at the same time.
The problem is in the environment, which is supported by the fact that I never could reproduce.

My environment can handle at least 20 buffered requests, yours can't, for some unknown reason.

Things to try:

With timed buffers, tweaking the wait time, send 2 request only, then 3, etc. See what gets throught  and what doesn't. This is just mostly to confirm. You seem to want to trace everything and if your environment is slow in getting through to the Trace API, you won't be able to use a timed buffer. Maybe a sized buffer with a maz size set to what you confirm gets through will work.
Figure out why your CloudRun environment is having trouble reaching the Trace API with "big" requests. This one is tricky. I can help here by telling you how mine is set up so you can compare, but not much else.

It might be related to region.
It might be related to how you have set up your CloudRun and services, with load balancers, etc.
It might be related to some of your project's settings.
If you can start with a project from scratch and just run the clean code that you sent me, using the buildpacks as they are etc., that might help you figure out what the problem might be.
Also, consider creating an issue on the Trace Public Issue tracker.

I will revisit the code and tests for the buffers, just to make extra certain that everything is fine, but I don't expect to find anything there to be honest. We haven't made any changes to that code in a long time, tests has been passing and there hasn't been any issue reported around it.
Let me know if you think there's something else we can do on our side.

The problem is in the environment, which is supported by the fact that I never could reproduce.

If you enable gRPC logging, do you see the same errors in your logs? In my tests the traces eventually went through, but were significantly delayed.

With timed buffers, tweaking the wait time, send 2 request only, then 3, etc. See what gets throught and what doesn't.

I will play around with it...

I can help here by telling you how mine is set up so you can compare, but not much else.

Could the Linux distribution that is being used by buildpacks cause a problem like this in gRPC?
Also, is there a way to force the library to send non-gRPC requests?

The problem is in the environment, which is supported by the fact that I never could reproduce.

If you enable gRPC logging, do you see the same errors in your logs? In my tests the traces eventually went through, but were significantly delayed.

No, nothing in the logs. And also, my traces show almost inmediately, the default wait time for the timed buffer is 5s, so that's fine.

I can help here by telling you how mine is set up so you can compare, but not much else.

Could the Linux distribution that is being used by buildpacks cause a problem like this in gRPC?

Yes, I suppose it could, but then why didn't I see it? There's a known issue with Alpine and gRPC, but it's a proper crash, nothing like this.

Also, is there a way to force the library to send non-gRPC requests?

Not at the moment, no.

No, nothing in the logs. And also, my traces show almost inmediately, the default wait time for the timed buffer is 5s, so that's fine.

I just tried setting TimedBuffer all the way down to 1 second. Surprisingly, it didn't help at all.
Would you mind giving us-east1 a try on your end? That is what I am using. Perhaps you can reproduce there.

There's a known issue with Alpine and gRPC, but it's a proper crash, nothing like this.

That bug doesn't seem to apply here, I see gRPC native library loaded successfully.

Figure out why your CloudRun environment is having trouble reaching the Trace API with "big" requests.

Let me give you a new observation.
Using the default TimedBuffer - sending just 1 request. Waited several minutes and nothing in Trace list. Deadline Exceeded error observed in logs, and here is the important part: There is a 40 second difference between the autogenerated Cloud Run request log and the first gRPC debug log.
Using NoBuffer - sending just 1 request. Trace appears practically instantly in Trace list. There is a less than 1 second difference between the autogenerated Cloud Run request log and the first gRPC debug log. The gRPC debug log entry is the same one as seen when using TimedBuffer.
This is important for 2 reasons:

TimedBuffer struggles just sending 1 trace. It doesn't have to be a big request with multiple traces.
For some reason, TimedBuffer starts attempting to log the trace at a time that is much later than what is configured.

A good place to start looking for a bug seems to be the code that kicks off the TimedBuffer gRPC request. I don't think it should be taking 40 seconds to start.

No, nothing in the logs. And also, my traces show almost inmediately, the default wait time for the timed buffer is 5s, so that's fine.

I just tried setting TimedBuffer all the way down to 1 second. Surprisingly, it didn't help at all.
Would you mind giving us-east1 a try on your end? That is what I am using. Perhaps you can reproduce there.

I tried us-east1, as soon as I send the requests I switch to the trace tabs, and there they are, all of them, a couple of the requests take a little over 1s just because the service is really warming up:

I am using your code, which except for tracing every request, sets everything by default, which means that I'm using the TimedBuffer with a wait time of 5 seconds. I'm using the same image I built with the buildpacks as I described in one of my earliest comments, and I'm not changing any of the default values when creating the Cloud Run service. I send requests with the service still being deployed and also after, everything works just fine.

Figure out why your CloudRun environment is having trouble reaching the Trace API with "big" requests.

Let me give you a new observation.
Using the default TimedBuffer - sending just 1 request. Waited several minutes and nothing in Trace list. Deadline Exceeded error observed in logs, and here is the important part: There is a 40 second difference between the autogenerated Cloud Run request log and the first gRPC debug log.
Using NoBuffer - sending just 1 request. Trace appears practically instantly in Trace list. There is a less than 1 second difference between the autogenerated Cloud Run request log and the first gRPC debug log. The gRPC debug log entry is the same one as seen when using TimedBuffer.

What is the exact gRPC log entry?

This is important for 2 reasons:

TimedBuffer struggles just sending 1 trace. It doesn't have to be a big request with multiple traces.
For some reason, TimedBuffer starts attempting to log the trace at a time that is much later than what is configured.

A good place to start looking for a bug seems to be the code that kicks off the TimedBuffer gRPC request. I don't think it should be taking 40 seconds to start.

The TimedBuffer depends on System.Threading.Timer if that's not triggering at the right time, there's something else going on almost certainly.
The gRPC deadline is also happening, and the gRPC call is no different if it comes from the TimedBuffer or from no buffer (or at least it shouldn't be) so, also, there seems to be something else happening.
My point is, the TimedBuffer might be the cause of the problem, or just sensitive to whatever else is happening.
A few questions/other things to try. Sorry for passing this on to you, but I can't reproduce.

I suppose there are no differences between the apps and environments that use the TimedBuffer and no buffer. Just double check please. Also I suppose that you are sending the no buffer traces with a cold app.
The app with the TimedBuffer, when it warms up, are there still issues, either with the traces not showing or in the gRPC logs?
Can you try with a SizedBuffer as well? Set the buffer size "small" so only one trace gets in.

I will revisit the buffers and tests next week and see if there's something there. I will probably end up writing some more tests at least.

To rule out some things, I created a new project and re-tested.
I deployed the sample app to Cloud Run (us-east1). I may not have mentioned it before, but I use these additional flags:
--cpu=2 --memory="4Gi" --timeout=30
You may want to use those settings too so we're on the same page.

Calling /hello results in the following:

A nearly 40 second delay between the request log and the first gRPC debug log.
Many Deadline Exceeded errors.

My suggestion for your next test:

Deploy using updated flags mentioned above.
Set gRPC debug vars: GRPC_TRACE=http, GRPC_VERBOSITY=DEBUG
Check for log time difference between last request log and the first gRPC debug log.

Answers to questions in your post coming in my next reply...

What is the exact gRPC log entry?

See below. You can see the time difference too. Note that some numeric values in the string may change, so it may not match what you see 100%.

My point is, the TimedBuffer might be the cause of the problem, or just sensitive to whatever else is happening.

I think a good way to proceed is to learn why the TimedBuffer starts so late. You should be able to see that easily in the logs when you have the gRPC debug vars set.

I suppose there are no differences between the apps and environments that use the TimedBuffer and no buffer. Just double check please. Also I suppose that you are sending the no buffer traces with a cold app.

I am using the sample app I uploaded. I outlined potential differences in my previous reply. The cold start is important. You may not be seeing what I am because you aren't getting cold starts. If the requests take less than 2 seconds, it isn't a cold start. It's unclear how to force a cold start (a redeploy may not work for some reason😕).

The app with the TimedBuffer, when it warms up, are there still issues, either with the traces not showing or in the gRPC logs?

Once warm (sending requests a few minutes after the first batch):

Traces show up instantly.
There is no ~40 second delay. All the gRPC debug logs after the last request log happen within the next 1-2 seconds.

I may have found something else. After the request is done, the CPU is throttled. Could explain the problems with TimedBuffer.

Official Cloud Run docs state that you should not do anything after the request has finished. Since TimedBuffer is clearly designed to process after the request, it makes total sense why it can really chug along and take up to 40 seconds to actually start processing, only to run into errors due to extremely limited CPU.
Relevant StackOverflow question.

OK, this explains everything, (and makes total sense btw), including the gRPC timeouts and the fact that I couldn't reproduce (probably because I wasn't scaling down my CPUs).

It makes sense now why NoBuffer works great. Unfortunately, it adds time to my request since it's no longer a background task...

Is the added time relevant? That of course depends on your context, but just check, it might be that it just adds .1% to the total time of the request and that's acceptable for you.

With all that in mind, I think we can rule out any bugs in google-cloud-dotnet. However, since TimedBuffer is the default, I think something needs to be done for Cloud Run users - TimedBuffer should not be used in this environment at all.

I will ad a note in the docs linking to proper documentation and advising not to use TimedBuffer when running in CloudRun or similar environments. We can't change the default now and risk breaking everyone else, and I feel that configuring one or the other type of buffer is straightforward.

The solution I am thinking of (at least for me) is to use a SizedBuffer of int.MaxValue to prevent sending right away.

That means that if the buffer gets full, you'd be looking at a little over 2Gb of memory. I would really advise you to use a smaller value, even if it means adding some overhead to a few requests to flush along the way. I'm pretty sure requests will get really slow way before you are buffering that many traces anyway. And also notice that gRPC has limits on message received size, and the wire itself might complain as well.

Then, in AssemblyLoadContext.Default.Unloading (SIGTERM), flush the buffer. What is the proper way to flush a SizedBuffer?

You don't need to flush the buffer explicitly, it will be flushed on Dispose which will happen before SIGTERM.

Unfortunately, this solution will not be perfect. It isn't possible to determine when SIGTERM will happen. It could happen in minutes, or more than 24 hours, so this can cause a significant delay in sending traces, and also potential problems in sending if the buffer ends up being huge.

You still won't know when Dispose will be called so you can still see delays on traces. Or problems depending on the size of the buffer. But again I would encourage you to pick a smaller buffer size, because by the time you are seeing problems sending traces on Dispose because of the buffer size, your latest requests were already, almost certainly, very slow if responsive at all.

There is also a chance the SizedBuffer size may also be reached

If the buffer size is reached, it will be flushed, will affect the particular request that made it go over.

so maybe a better solution would be to add a new buffer type... maybe "CloudRunBuffer", which could have special handling for Cloud Run environments.

We almost certainly won't do that, our implementation would run into the same or similar issues as you are describing because it needs to be CloudRun who supports some sort of background work, which probably goes against CloudRun "spirit" in any case.
My advice would be to use no buffer or SizedBuffer and play around with the numbers until the overhead you see is acceptable. Maybe also consider just sampling traces instead of tracing everything, etc. I understand this is not ideal but I believe it's the best that can be done in environments that, by definition, won't properly handle background work, which is not restricted to CloudRun by the way.

Is the added time relevant? That of course depends on your context, but just check, it might be that it just adds .1% to the total time of the request and that's acceptable for you.

Very much. It can add a lot of latency to request handling, but most importantly, there will be gaps in the trace report.
I think I have some up with a solution, but I need to know how to manually flush the trace buffer. Can you tell me how?
I will make a Cloud Scheduler task to hit a request URL dedicated to flushing traces.
I will also add SIGTERM handling to do a final flush of the traces.
The flushing needs to be done in the request, where the CPU is most available, and this seems to be the only way to do that without affecting the real requests.

There's no way that you can manually flush the buffer right now. I could expose something via standard dependency injection that would allow you to, from a request. I don't think it will available on SIGTERM handling though and I wouldn't do any explicit work for that to be available on SIGTERM. I really really think you don't need to handle SIGTERM and at that point we won't guarantee that the Diagnostics library works, some of our dependencies or even our own objects might have been disposed off at that point, etc. All the buffers will flush on Dispose, and Dispose will happen before the application is shut down.
About your solution though, I think it won't solve your problems, you don't know which of the Cloud Run instances your special request will hit, there's no guarantee on the distribution of those hits across your instances, etc. So, you will almost certainly will see delays in tracing, will run into the same problems re the buffer being very big and getting very full if for some reason one of the instances is never hit, etc.
The problem here is that you really want to do something that it's not supported by the environment you are running in.

Hm, you are right, my workaround will not work.😫
There doesn't appear to be a good solution here. Just due to the nature of Cloud Run, NoBuffer needs to be used, but that will slow down the request a bit. I suppose that reducing the sample rate will be a compromise to stop it from making all requests slower.
Unless you have anything to add, I believe that NoBuffer with a reduced sample rate may be the most "correct" option.
Still, you should definitely add some extra documentation for Cloud Run so others do not run into the same situation I did.

I think you can also try SizedBuffer and play a little with the numbers until you find a sweet spot between the latency it adds to the request that makes the buffer go over, the amount of traces you want to sample and the amount of requests that remain unaffected. That is of course if you are fine with not getting traces immediately.
Also, have you tried not using the Diagnostics library and writing to stdout? I think that should be captured before the CPUs are spun down and send to Google Logging by Cloud Run without affecting the request. It won't be traces though, it'll be logs.
I will add some docs around this by the end of the week. I'll leave this issue open just for that.

I think you can also try SizedBuffer and play a little with the numbers until you find a sweet spot between the latency it adds to the request that makes the buffer go over, the amount of traces you want to sample and the amount of requests that remain unaffected. That is of course if you are fine with not getting traces immediately.

Also, have you tried not using the Diagnostics library and writing to stdout?

Yes, no problems there. I don't have any logging to do at the moment, though - just tracing.

I will add some docs around this by the end of the week. I'll leave this issue open just for that.

I agree - I don't think there is anything else that can be done right now. Maybe in the future Cloud Run will change something to open up more workarounds. I'll let you know if that ever happens.🙂

What I have decided to do is disable aspnetcore tracing and just keep logging and error reporting. In cases where that needs to happen, I will tolerate the small amount of added latency added by NoBuffer.
However, when logging, it doesn't set the trace ID in LogEntry now since tracing is no longer enabled. Is it possible to override that? The trace ID is there, and it comes from the load balancer.
Basically, I do not want the library to generate a trace span, so that is why I disabled it. However, I'd still like logs/errors to have the trace ID set, if possible (so they will be organized in the GCP console). Let me know if that makes sense.

Yes, there's a way to do that. If you don't activate Tracing we do assume that you don't want trace information in logs but it's easy to bring that back in.
You have to implement Google.Cloud.Diagnostics.AspNetCore.IExternalHeaderProvider, you can even user our own helper clases to extract the trace and span IDs from the header by using Google.Cloud.Diagnostics.Common.TraceHeaderContext.FromHeader.
You then add a dependency to your implementation on your startup class (or similar), like such, we look for this dependency when creating logs and using to fill in the trace information if any.
public virtual void ConfigureServices(IServiceCollection services)
{
    ...
    services.AddSingleton<IExternalTraceProvider>(new BringBackTheTraceTraceProvider());
}

Remember that the load balancer is only sampling (at least mine was only sampling) so you will still see logs without the tracing info, because in that case there's none.

Thanks for the tip. Got it working with this code. Had to search for a way to get the header value. Is there a simpler way or am I correct?
private sealed class AddTraceDetailsProvider : IExternalTraceProvider
{
    public TraceContextForLogEntry GetCurrentTraceContext(IServiceProvider serviceProvider)
    {
        if (serviceProvider.GetService<IHttpContextAccessor>().HttpContext.Request.Headers.TryGetValue(TraceHeaderContext.TraceHeader, out var traceHeaderValue))
        {
            var traceHeaderContext = TraceHeaderContext.FromHeader(traceHeaderValue);
            return new TraceContextForLogEntry(traceHeaderContext.TraceId, $"{traceHeaderContext.SpanId:x16}");
        }
        else return null;
    }
}

That's about right, except that the span format should be string.Format("0x{0:X}", spanId).
Actually, if you wait for a few days, I can add this into the library, seems reasonable.

Can trace/span IDs be attached to exception logs too or is that not how they work?
I don't inmediately see why not. I'll take a closer look and get back to you.

(I just saw #5355 on span ID format, commenting there).

Thanks for your work on all this. I am glad this discussion resulted in several improvements being made.😁
When will you publish a new version to NuGet?

Probably tomorrow. I want CI to run fully tonight before publishing, just in case. And it will be a beta for a couple of weeks until we've gotten some usage, at least from you ;), and confirm everything is as expected.
The couple of pending features, will still be one or two weeks away.


CrossBluetoothLE class not found in Xamarin.Forms project

It seems that CrossBluetoothLE can't be used in a .netstandard project anymore, the class it not found in the namespace. The only namespace found in Plugin.BLE is Plugin.BLE.Abstractions. Possibly this isn't an error but the case on how to use Plugin.BLE has changed from how I was using it in the 1.3 release. I can see from the samples that IAdapter is passed around everywhere but I don't see where that reference comes from.
Steps to reproduce

Create a new blank Xamarin.Forms application

Add Plugin.BLE Nuget package (as well as update all other nuget packages)

Try use Plugin.BLE.CrossBluetoothLE within the Xamarin.Forms project.

Expected behavior
You can use the sample code of:
var ble = CrossBluetoothLE.Current;
var adapter = CrossBluetoothLE.Current.Adapter;

Actual behavior
In the Xamarin.Forms project the CrossBluetoothLE class can not be found, even when referenced as Plugin.BLE.CrossBluetoothLE. However the Xamarin.iOS and Xamarin.Android projects can use that class fine.
Attached is a sample project which won't build due because the above reason.
XFBLETest.zip

Hi @beeradmoore,
I'm the friendly issue checker.
It seems like (62.50 %) you haven't used our issue template :cry: I think it is very frustrating for the repository owners, if you ignore them.
If you think it's fine to make an exception, just ignore this message.
But if you think it was a mistake to delete the template, please close the issue and create a new one.
Thanks!

The NuGet doesn't contain the Plugin.BLE.dll anymore

I have no real clue about the build tools, but isn't this
https://github.com/xabre/xamarin-bluetooth-le/blob/8a35f7bad8990cc5bb47c863bd9ba9ea15889802/.build/build.cake#L67-L69
essentially missing to build the project?


The tree display does not update when a variable is changed

Description
The tree display does not update when a variable is changed
The first one changes the value of the variable and 2 changes its values based on this variable.
The tree is updated in 2 cases: if you enter edit mode or when refreshing the page
We will be grateful if you correct this behavior.
Current Version
v1.4.2

Thank you for submitting the bug report. In order to better understand and reproduce the issue, we would appreciate it if you could provide more detailed information about the bug. Specifically, it would be helpful to know the steps to reproduce the issue, the expected behavior, and any additional information that could help us investigate the problem.
Thank you for your help in improving this plugin.

Test data (postgresql datasource):

CREATE TABLE public.time_period (

	"time" timestamp NOT NULL,
	"count_block" String NOT NULL,
	"parent" int4 NULL
);

INSERT INTO public.apdex ("time", "count_block", "data")
VALUES
('2024-03-18 07:01:17', '2024-03-18 07:01:17 (4)', NULL),
('2024-03-18 06:49:47', '2024-03-18 06:49:47 (2)', NULL);

CREATE TABLE public.blocks (

	time timestamp NOT NULL,
	"id" integer NOT NULL,
	"parrent_id" int 4 NULL,
	"session_id" String NOT NULL,
	"block_id" String NULL
);

INSERT INTO public.blocks ("id", "parrent_id", "session_id", block_id)
VALUES
('2024-03-18 06:49:47', 11044909, 11044916, '258', '528'),
('2024-03-18 06:49:47', 11044915, 11044916, '306', '528'),
('2024-03-18 06:49:47', 11044916, NULL, '528', NULL),
('2024-03-18 07:01:17', 11045942, 11045917, '511', '399'),
('2024-03-18 07:01:17', 11045931, 11045917, '422', '399'),
('2024-03-18 07:01:17', 11045922, 11045917, '450', '399'),
('2024-03-18 07:01:17', 11045938, 11045941, '520', '336'),
('2024-03-18 07:01:17', 11045941, NULL, '336', NULL),
('2024-03-18 07:01:17', 11045917, NULL, '399', NULL);

add to dashboard 2 intercative tree panel and dashboar veriable "select_time"

Query
Select * from time_period Where $__timeFilter(time)
Serrings :

Query
Select * from blocks
Where time between to_timestamp($select_time/1000)-interval '1' second and to_timestamp($select_time/1000)+interval '1' second
Settings :

Case 1 :
When the time changes, 1 panel is not updated.
Case 2:
When you select a value in 1 panel, the data in 2 panels is not updated

We tried to reproduce the issue based on the data you provided, but we were unable to reproduce it. Attached you find the database script we used to create the dataset and an export of the dashboard we used to reproduce the issue. Can you please check if you still experience the issue  with the attached dashboard JSON?
sample_dashboard.json
CREATE TABLE public.time_period (
	"time" timestamp NOT NULL,
	"count_block" text NOT NULL,
	"parent" int4 NULL
);

INSERT INTO public.time_period ("time", "count_block", "parent")
VALUES ('2024-03-18 07:01:17', '2024-03-18 07:01:17 (4)', NULL),
('2024-03-18 06:49:47', '2024-03-18 06:49:47 (2)', NULL);

CREATE TABLE public.blocks (
	time timestamp NOT NULL,
	"id" integer NOT NULL,
	"parrent_id" int4 NULL,
	"session_id" text NOT NULL,
	"block_id" text NULL
);

INSERT INTO public.blocks ("time", "id", "parrent_id", "session_id", block_id)
VALUES ('2024-03-18 06:49:47', 11044909, 11044916, '258', '528'),
('2024-03-18 06:49:47', 11044915, 11044916, '306', '528'),
('2024-03-18 06:49:47', 11044916, NULL, '528', NULL),
('2024-03-18 07:01:17', 11045942, 11045917, '511', '399'),
('2024-03-18 07:01:17', 11045931, 11045917, '422', '399'),
('2024-03-18 07:01:17', 11045922, 11045917, '450', '399'),
('2024-03-18 07:01:17', 11045938, 11045941, '520', '336'),
('2024-03-18 07:01:17', 11045941, NULL, '336', NULL),
('2024-03-18 07:01:17', 11045917, NULL, '399', NULL);


xarray-regrid blogpost

The latest xarray-regrid release is 🔥 !
https://github.com/xarray-contrib/xarray-regrid/releases/tag/v0.4.0
Can we get a short blogpost please?
cc @slevang @BSchilperoort

Happy to cross-post!


[DOCS] Redesigned the blog page with grid layout

Tips
What is the purpose of the pull request
As discussed with Kyle and Vinoth, redesigned the blog page with grid layout.
I don't want to block the development, hence split the work into two phases:

Redesigned the blog page in the grid layout. (this PR covers this work)
Add source text in the blog then merge the blog page with the talks and articles page.

I have added few images to the blog post, to add images, update each and every blog post with the image property in the header of the blog, for example, to add the image for this blog update this file with the following text:
website/blog/2021-08-18-improving-marker-mechanism.md
image: /assets/images/blog/marker-mechanism/timeline-server-based-marker-mechanism.png

Brief change log

Redesigned the blog page with grid layout

Verify this pull request
(Please pick either of the following options)
This pull request is a docs work without any test coverage.
Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[x] Commit message is descriptive of the change

[x] CI is green

[x] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

@vinothchandar @kywe665 Could you take another look before merging the PR?

Can we add more icons here ? The hoodie logo full of the page looks weird ;)

Can we add more icons here ? The hoodie logo full of the page looks weird ;)

@danny0405 - Yes I agree, these are default placeholder images, Kyle weller volunteered to update the images for all the blog posts, after we land this change, he will do that as a follow-up.

Can we add more icons here ? The hoodie logo full of the page looks weird ;)

@danny0405 - Yes I agree, these are default placeholder images, @kywe665 volunteered to update the images for all the blog posts, after we land this change, he will do that as a follow-up.

Thanks for your work ~

This looks good, lets merge and then I will update the images quickly


Cant select view.

Hi
I think I must be missing something. I can create and publish to Azure Devops nuget feed fine. But I'm trying to use this extension and under "release views" dropdown combo there are no options. I'd expect to see prerelease and release there.  Is this just me, or is it broken for others?
Thanks
Ken

same as #38


[WIP] Flow and job execution time metrics

Metrics to track duration of jobs and flows; Added tagging ability for DataDog by adding a default parameter.
@ajmssc @yevgenius Can you take a look.

LGTM.
Awesome!

@cmasekera are you still working on this?

@ajmssc Looked at it and looks fine... Won't be doing anything more on it.


More documentation for FileUpload component

I've tried using the imagePreviewHeight("100") and imagePreviewHeight("100px") but no changes to the height in component. Not sure how to use the method
Same for getPanelLayout($layout), not sure what $layout should be

did you try using integer instead of string?

Hey @zltn, did you try @yob-yob's suggestion?
These are passed directly to Filepond btw, might be worth documenting the options.

Yeah, tried integers as well. I did get imageResizeTargetHeight($height) to work with a number as string without px "200"

I've added a link to Filepond's website where the options are listed.


Replace entity spawning abstraction

Fixes https://github.com/TheBevyFlock/bevy_quickstart/issues/223.
Part of https://github.com/TheBevyFlock/bevy_quickstart/issues/203.
Will need to update the design doc as well.

@alice-i-cecile could you also take a look at this?

@alice-i-cecile I'm tending the same way. I feel a bit bad since we both gave a thumbs-up for it in https://github.com/TheBevyFlock/bevy_quickstart/issues/223, but seeing it in practice is just too "scary". I've been thinking about ways to improve the design and make it more approachable, but I'm really struggling with that.
It would be easier if

this was an upstreamed API, and so was able to be simplified due to no orphan rule, or
this was a library, and so a user is opting into it and ready to deal with the new concepts.

For the moment, I'd instead go for the simpler route of replacing observers with custom commands.

Custom commands means having to extract system parameters from World, which is even worse in that regard, no?

I don't like extracting stuff manually from World, but at least that is "standard Bevy", for better or worse.
Using an Entity as the first param is a good analogy to observers, agreed. I personally don't mind it, but I think the Bevy maintainers will disagree with introducing this as an abstraction.
My main issues are more:

Using the provided abstraction requires active learning, which I don't think is as bad for the other abstractions we use. You can take a single look at fn plugin or at commands.button and you know how to use it. The same cannot be said for things like the interplay / differences between spawn_with, spawn_fn, add_fn.
spawn.rs feels scary enough that for newcomers it might as well be a black box imo.

As for Commands vs Observers: I only recommend using commands because that was @alice-i-cecile's feedback. I personally would prefer an observer because of the ergonomics, even when that means a layer of indirection. My opinion on this is not strong however and I will accept either implementation. I can see both points.

For the record, custom commands still requires spawn_with and extension traits. It would only mean removing spawn_fn and add_fn and extracting everything from World instead of using system parameters.

@benfrankel I think that could work, in terms of not introducing too many new abstractions / concepts.
Worst case we can still use the crappy variant that does not return an Entity to the caller. It's suboptimal, but it's not our fault that this is fundamentally missing in Bevy and it might be fixed by BSN.

Done. Usability is much worse without system param support IMO but it's w/e.

I think this is an improvement, but I'm still not happy with the level of abstraction / ad-hoc tools here. I think this should be merged, but the linked bug / limitation should be fixed upstream (ping me for reviews!), and I'm still reluctant to officially recommend this template until this is substantially simpler.
If you feel that the limitations of just doing things the dumb way are unacceptable, I'm fine to hold off on endorsing this until the BSN work is shipped.

Closing this for now. Sorry again for the whole work that is not merged. Let's revisit this after some improvements have been implemented upstream.

All good, it was mostly copy/paste and some mechanical refactoring.


Update config_test.go and metricstest to support multiple Meters.

This is in preparation for #1392 ; it also cleans up some odd non-go-like test code in metricstest (though not all of it, because I didn't want to make a breaking change to the exposed interface).
/assign @yanweiguo

Fixed the build; not sure why it picked up the go 1.13 mod info.

/lgtm


Where is the analogue to FirebaseAuthUI ?

Where can I find code that performs the function that FirebaseAuthUI does for Java on Android?

@ErstwhileIII
The issue at https://github.com/flutter/flutter/issues/17706 has been closed and moved here. Future collaboration on this issue will be done here.

Great ... Now after over a year, has anyone been assigned this case? I hope we don't just move things around.

Firebase UI is out of scope currently. Closing however this may be picked up in the future.


Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=<IP_ADDRESS>

I have this error when using Scriban in a web application :
Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

The libraries used are the following:

Scriban.dll, version is <IP_ADDRESS>
System.Threading.Tasks.Extensions.dll, version is 4.6.27818.1
System.Runtime.CompilerServices.Unsafe.dll, version is 4.6.26929.02

This error does not occur on my local machine, only on the customer machine.
My local .NET framework is 4.8.03752
The customer's NET framework is 4.7.02558
The code is compiled for 4.7.1

Looks like an assembly redirect that you need to handle on your side. I don't think that there is anything we can do scriban side.

Merci Alexandre.


Not working

Describe the bug
Bot isn't starting.
To Reproduce
Start the bot, Download Here
Expected behavior
No

You don't have any event, so nothing can be executed.


Make BIGNUM rand functions available within the FIPS module

PR #9130 made the BIGNUM code available from within the FIPS provider, but had the RAND functions disabled because no RAND code was available from inside the provider at that time. When PR #9035 is approved, RAND will become available from within the provider.
This PR re-enables the BIGNUM RAND code. It depends on #9035 so is marked as WIP for now.

https://travis-ci.org/openssl/openssl/jobs/547758528#L2447 looks relevant...  https://ci.appveyor.com/project/openssl/openssl/builds/25392229/job/gvnaly2ws8q8u21c#L5014 says the same thing...

Now that #9035 has gone in I've rebased this and taken it out of WIP.
Needs a reviewer...

I've made the requested changes, and split the first commit into two as suggested. Due to the changes in the number of commits, I've force pushed this.

Rebased to resolve a conflict with master.
Ping?

Fixup commit pushed addressing nits.
@mspncp can you reconfirm?

Pushed. Thanks.


[cli_config] Fix coverage setup

The simple coverage setup from https://github.com/dart-lang/tools/pull/42 seems to not show up on https://coveralls.io/github/dart-lang/tools.
Either it's misconfigured, or we need to approve it somewhere.
Also, we need to configure it that it's for a sub-package here. As this is a mono-repo with multiple packages.

@mit-mit Do you happen to know if we need to enable it?
And, do you happen to know who might know the answer to coverage with a mono-repo?
package:jnigen has two sub-packages, but they upload coverage in one workflow: https://github.com/dart-lang/jnigen/blob/main/.github/workflows/test-package.yml This mono-repo has a GitHub workflow per package.

Possibly something you can configure from the coveralls.io UI? https://coveralls.io/better-monorepo-support

Possibly something you can configure from the coveralls.io UI? https://coveralls.io/better-monorepo-support

I have no configuring powers on coveralls.io for this GitHub repo.


[ERROR] yaml file not found

Please provide the following information:

OS: (e.g. Ubuntu 22.04)
ROS 2 Distro: (e.g. Humble)

Expected behaviour
I clone the git repository, built all the packages (which went well) and then tried to run the simulation launch file from clearpath_gz folder. Then it should start the simulation with a robot.
Actual behaviour
Actually, Gazebo runs well, I have the window with everything in it but the robot and I get this message in my terminal:
[ERROR] [launch]: Caught exception in launch (see debug for traceback): YAML file 'None' could not be found
I suppose it is related to the launch file not finding the robot.yaml file but I'm not quite sure about that.
To Reproduce
Provide the steps to reproduce:

clone the repository
colon build --symlink-install
ros2 launch learpath_gz simulation.launch.py

Did you create a robot.yaml?: https://docs.clearpathrobotics.com/docs/ros/config/yaml/system

No, but I have a husky.yaml file with the same kind of implementation in a clearpath folder. I was thinking of replacing robot.yaml by husky.yaml in my launch file but I don't know if it is correct

The generators look for robot.yaml to generate the needed launch files.  Could you copy this as your robot.yaml and try again?

I can try, where should I create the yaml file?

okay, i created the robot file in the same folder as my previous husky one. I get another error message: [ERROR] [launch]: Caught exception in launch (see debug for traceback): executed command failed. Command: /opt/ros/humble/bin/xacro /home/peenut/clearpath/robot.urdf.xacro is_sim:=true gazebo_controllers:=/home/peenut/clearpath/platform/config/control.yaml namespace:=a200_0000
Captured stderr output: error: No such file or directory: /.urdf.xacro [Errno 2] No such file or directory: '/.urdf.xacro'
when processing file: /home/peenut/clearpath/robot.urdf.xacro
and:
[ERROR] [ruby $(which ign) gazebo-1]: process[ruby $(which ign) gazebo-1] failed to terminate '5' seconds after receiving 'SIGINT', escalating to 'SIGTERM'
[ERROR] [ruby $(which ign) gazebo-1]: process has died [pid 7390, exit code -15, cmd 'ruby $(which ign) gazebo warehouse.sdf -v 4 --gui-config /media/peenut/programmes/ros_projects/cs8813/husky/clearpath_ws/install/clearpath_gz/share/clearpath_gz/config/gui.config --force-version 6'].

certainly, here is the file: serial_number: a200-0000
version: 0
system:
username: administrator
hosts:
self: cpr-a200-0000
platform:
cpr-a200-0000: <IP_ADDRESS>
onboard: {}
remote: {}
ros2:
namespace: a200_0000
domain_id: 0
rmw_implementation: rmw_fastrtps_cpp
workspaces: []
platform:
controller: ps4
battery:
model: ES20_12C
configuration: S2P1
attachments:
- name: front_bumper
type: bumper
parent: front_bumper_mount
- name: rear_bumper
type: bumper
parent: rear_bumper_mount
- name: top_plate
type: top_plate
- name: sensor_arch
type: sensor_arch
parent: default_mount
enabled: False
extras:
urdf: null
ros_parameters:
platform_velocity_controller:
linear.x.max_velocity": 1.0
linear.x.min_velocity": -1.0
linear.x.max_acceleration": 3.0
linear.x.min_acceleration": -3.0
angular.z.max_velocity": 2.0
angular.z.min_velocity": -2.0
angular.z.max_acceleration": 6.0
angular.z.min_acceleration": -6.0
links:
box: []
cylinder: []
frame: []
mesh: []
sphere: []
mounts:
bracket: []
fath_pivot: []
riser: []
disk: []
post: []
sensors:
camera: []
gps: []
imu: []
lidar2d: []
lidar3d: []

I did it, but still have the error messages

Hi @Peenut173, would you mind checking that you have the latest changes, i.e. git pull in clearpath_config.
Also, please attach the generated /home/peenut/clearpath/robot.urdf.xacro so we can take a look at where it is that the '/.urdf.xacro' is being referenced.

I just saw that robot.urdf.xacro is in /media/peenut/programmes/ros_projects/cs8813/husky/clearpath_ws/src/clearpath/. husky is the folder where we clone the repository. Here is what the file contains:

<xacro:include filename="$(find clearpath_platform_description)/urdf/common.urdf.xacro"/>

<xacro:include filename="$(find clearpath_platform_description)/urdf/a200/a200.urdf.xacro"/>
<xacro:a200 wheel="default"/>

<xacro:include filename="$(find clearpath_platform_description)/urdf/a200/attachments/bumper.urdf.xacro"/>
<xacro:bumper name="front_bumper" model="default" parent_link="front_bumper_mount" extension="0.0">

</xacro:bumper>
<xacro:include filename="$(find clearpath_platform_description)/urdf/a200/attachments/bumper.urdf.xacro"/>
<xacro:bumper name="rear_bumper" model="default" parent_link="rear_bumper_mount" extension="0.0">

</xacro:bumper>
<xacro:include filename="$(find clearpath_platform_description)/urdf/a200/attachments/top_plate.urdf.xacro"/>
<xacro:top_plate name="top_plate" model="default" parent_link="default_mount">

</xacro:top_plate>

<xacro:include filename="/.urdf.xacro"/>

Also I have no clearpath folder in /home/peenut, which is also something I have just noticed. I finally can not find any clearpath_config in my folder. I believe this is not normal but we just cloned the git in husky folder, so it should be there if I am not mistaken?

The clearpath_config should be under /media/peenut/programmes/ros_projects/cs8813/husky/clearpath_ws/src where you seem to have cloned and built it. That is where you should call git pull to get the latest changes.

Okay, I got the clearpath_config repository and now I see the robot on the simulation. I still have some error messages, for instance:
[ERROR] [1706049581.601866904] [a200_0000.joy_node]: Couldn't open joystick /dev/input/ps4. Will retry every second.
But I think this is due to something else, like a node that is not running and as soon as I'll run it the error message will disappear if I am correct?

Yeah, that is expected behaviour if you do not have a PS4 controller connected. It is the standard we use for our robots, so we use it on simulations too.
It seems that your issue is now resolved and you no longer have an issue launching the simulation.