Need a way to opt of out AutoInitialize logic

The AutoInitialize code runs at dll attach. This is fine for apps that are 100% winappsdk apps/winui3. However for apps that want to host islands of winappsdk/winui3 content (and they don't delayload winappsdk), this runs prematurely.
a) we should make it easy to delayload winappsdk until it is needed
b) or at least, to defer the initialization until it is needed (e.g. first winui3 dialog being shown)

There is a project property you can define to disable the autoinitialization logic, allowing your app to take responsibility:
WindowsAppSdkBootstrapInitialize
And here is an issue requesting documentation for this property:
https://github.com/MicrosoftDocs/windows-uwp/issues/3714


[ISSUE #1016] init loadBalance for grpc producer

Fixes ISSUE #1016 .
Motivation
java-sdk must be fixed service address
Expect to be able to get the service address automatically from the registry
Modifications
wrapper java-sdk of grpc producer to impl loadbalance
Documentation

Does this pull request introduce a new feature? (yes )
If yes, how is the feature documented? (not applicable)
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

I don't think it's time to do this change, we didn't register EventMesh runtime server in ZK.

I have previously submitted a PR support ZK registry #974 . My thinking is that the type of registry currently supported is not critical, it may be important to design the nameResolver and loadbalance of client well, subsequent registries can be expanded on this basis. This is just my personal opinion, can you give me some suggestions ?

You need to submit a mail to dev to discuss this, since this will make a great impact to EM. I agree we can add this feature, but you still need to send proposal(This is important), and we need to put the logic in your ZK registry, the client should only rely on registry to get/notify the change of server address.

I don't think it's time to do this change, we didn't register EventMesh runtime server in ZK.

I have previously submitted a PR support ZK registry #974 . My thinking is that the type of registry currently supported is not critical, it may be important to design the nameResolver and loadbalance of client well, subsequent registries can be expanded on this basis. This is just my personal opinion, can you give me some suggestions ?

You need to submit a mail to dev to discuss this, since this will make a great impact to EM. I agree we can add this feature, but you still need to send proposal(This is important), and we need to put the logic in your ZK registry, the client should only rely on registry to get/notify the change of server address.

Alright. Thanks♪(･ω･)ﾉ

I don't think it's time to do this change, we didn't register EventMesh runtime server in ZK.

I have previously submitted a PR support ZK registry #974 . My thinking is that the type of registry currently supported is not critical, it may be important to design the nameResolver and loadbalance of client well, subsequent registries can be expanded on this basis. This is just my personal opinion, can you give me some suggestions ?

You need to submit a mail to dev to discuss this, since this will make a great impact to EM. I agree we can add this feature, but you still need to send proposal(This is important), and we need to put the logic in your ZK registry, the client should only rely on registry to get/notify the change of server address.

Hi, I have sent the email some time ago. I wonder what is happening now.

Hi, if possible, could you please split your pr into separate part? Smaller pr with fewer changed file would help us review your code better and faster. Hope you could understand, thank you for your contribution!

First of all, thank you for your advice. The ISSUE corresponding to this PR is a big change to the existing Client SDK, so it is submitted more. One of the members suggested sending an email to discuss this feature, so this PR is just a draft.


REFACTOR-#3598: remove FutureWarnings in groupby tests

Signed-off-by: Anatoly Myachev<EMAIL_ADDRESS>
What do these changes do?

[x] first commit message and PR title follow format outlined here

NOTE:  If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

[ ] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] signed commit with git commit -s
[x] Resolves #3598
[ ] tests added and passing
[ ] module layout described at docs/development/architecture.rst is up-to-date

obsolete


Add support for CPU hot add/remove

For hot-add, we have to know what CPUs are available using
query-hotpluggable-cpus.
For hot-remove we only need to know the CPUs ids in order to avoid the
use of 1 query 1 cpu, hotplugAddCPUs and hotRemoveCPUs receive the
total amount of CPUs to hot add or hot remove.
depending of the container's state, pod's resources are updated.
for example, if the container has a CPU constraint of 4 vCPU and it is stopped,
then these 4 vCPUs are removed.
another example, if the container is ready to be started and it has a CPU
constraint of 3 vCPUs, 3 vCPUs are added and the constraint is sent to the
agent to limit CPU usage of the container.
With this patch the fractional part of the CPU constraint is also honoured,
for example, if the container has a CPU constraint of 5.5, then 6 vCPUs are
added to the POD and a constraint of 5.5 CPUs is applied to the container
fixes #511
Signed-off-by: Julio Montes<EMAIL_ADDRESS>

@devimc CI is not passing here. #589 has been solved, and I don't think #591 is the reason why tests are failing, right ?
Could you please make the tests passing on this PR ?

@sboeuf let me apply #591 and see if that fixes the CI

pssst hey @sboeuf  take a look to the CI

@devimc thx ! I'll do the review !

@devimc is that ready for a new review ?

@sboeuf changes applied, thanks

@sboeuf changes applied, thanks
depends on https://github.com/clearcontainers/packaging/pull/279

@sboeuf I think your design is different than mine, you want to share vCPUs between containers while I don't. Correct me if I''m wrong, but in your design if we have 1 container with a constraint of 2 vCPUs, the VM should have 2 vCPUs, but if a new container is created with a constrain of 3 vCPUs, then only 1 vCPUs will be added, the idea is good but is not the correct solution. In order to don't have containers fighting for the CPU usage, each container should have assigned the number of vCPUs that it needs, we can not exceed the maximum number of actual physical cores because docker and kubernetes validates that before starting the container, if quota/period is greater than the actual number of physical cores the container won't start, also in qemu.go I have a validation to do not exceed the maximum number of vCPUs, in that way when the container is destroyed only its resources are hot removed (if it has any), that means we will not remove CPUs used by other containers neither the runtime will try to remove cold plugged vCPUs.

@sboeuf

Do you realize that we're always going to end up with number_of_CPUs_on_the_VM = coldplugged_CPUs + (container_i * number_of_CPUs_for_container_i) ?

Yes, when a CPU constrain is not specified for a container, then it will use the CPUs cold plugged.

How are we going to handle the constraint of the container process inside the VM so that we won't end up using only the first CPUs (0,1,2 for instance for a second container that needs 3 CPUs, but the first container needed 2 CPUs) ?

Before creating a container, the runtime check if a CPU constraint was specified, if so, then N cpus are hot added and the agent places the container inside a CPU cgroup, containers without CPU constraint have less priority than containers with CPUs constraint. For example, if default_vcpus is 1 and this pod configuration is used:
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
  namespace: cpu
spec:
  containers:
  - name: container1
    image: vish/stress
    args:
    - -cpus
    - "4"
  - name: container2
    image: vish/stress
    resources:
      limits:
        cpu: "4"
    args:
    - -cpus
    - "4"

both containers container1 and container2 will try to consume 400% of CPU. When container1 is created the VM only have 1 vCPU, hence container1 uses 100% of CPU. When container2 is created, 4 vCPUs are hot added, container2 is placed inside a CPU cgroup, and it consumes 400% of CPU while container1 only 100%

@devimc Ok this is pretty clear, but I thought we had to specify which CPU (0, 1, 2, ..., N) we're gonna use for each container. If the kernel handles the workload on its own, then that's fine to only specify the number of CPU for each process and we don't have to bother with this. Is that right ?
Now, about the coldplugged CPU, I think we can do better here. In case all the containers running will have some CPU constraints, the number of CPUs coldplugged will never be used. We're wasting resources here.
So I'd like that we take into account the number of coldplugged CPUs before we start hotplugging more CPUs. Also, I think that we should handle the non-constrained containers as if they had some CPUs to hotplug. The only way to do that is to define a default amount of CPUs that we expect acceptable to run a non-constrained container.
Does that make sense ?

@sboeuf

I thought we had to specify which CPU (0, 1, 2, ..., N) we're gonna use for each container.

when I started with this, I thought the same, but that is not needed because the kernel automatically runs the workload in N vCPUs. Also we cannot decide what vCPUs the container have to use, the user can decide this docker --cpuset-cpus(in another PR I'll add support for this option).

If the kernel handles the workload on its own, then that's fine to only specify the number of CPU for each process and we don't have to bother with this. Is that right ?

that's correct.

Now, about the coldplugged CPU, I think we can do better here. In case all the containers running will have some CPU constraints, the number of CPUs coldplugged will never be used. We're wasting resources here.

It depends, to deal with this limitation, in https://github.com/clearcontainers/runtime/pull/1041 I'm changing default_vcpus to 1, this vCPU can be used for other processes, remember that our containers are not running alone in the VM, we have other process running, like the kernel, systemd(journal, etc) and the agent.
I agree with you, if the user changes default_vcpus to a number greater than 1, then we will be wasting resources, for that reason I'll document this in https://github.com/clearcontainers/runtime/pull/1041

So I'd like that we take into account the number of coldplugged CPUs before we start hotplugging more CPUs. Also,

and we do, these coldplugged vCPUs are used by containers without CPU constraints, it's up to the user decides the resources available for the containers without a CPU constraint.

I think that we should handle the non-constrained containers as if they had some CPUs to hotplug. The only way to do that is to define a default amount of CPUs that we expect acceptable to run a non-constrained container.

In runC, if containers don't have a CPU constraint, they will try to consume all the resources needed to complete theirs task, they will compete for the resources. Cold plugged vCPUs are used and shared between  the containers without CPU constraint, if the user want to give more priority to one container over these resources, He/She can use docker --cpu-shares (I'll add support for this option in other PR)

Following our discussion on IRC with @devimc, the change looks good and can now be merged as long as we document very well all the behavior we expect with unconstrained vs constrained containers.
LGTM

@devimc please take a look why this is failing so that we can move forward and get this merged ;)


Could not download reference symbols in local VS Code using docker

I am trying to install latest NAV Development Preview on my local host. I'm using docker image navdocker.azurecr.io/dynamics-nav:devpreview-us to get the latest devpreview version with US database.
I was able to start a container and open Dynamics 365 for Financials from a browser. This was my output from running a container:
Using existing license file
Create Web Site
Create NAV Web Server Instance
Enable Financials User Experience
Create http download site
NAV Admin Username  : admin
NAV Admin Password  : Duly5913
Container IP Address: <IP_ADDRESS>
Container Hostname  : b12b2204a385
Web Client          : http://b12b2204a385/NAV/WebClient/
Dev. Server         : http://b12b2204a385
Dev. ServerInstance : NAV

But when i try to download symbols from new VS Code project i get the error:
[2017-10-24 <IP_ADDRESS>] Could not download reference symbols. Please ensure that:
1. The correct server name and instance are specified in the launch.json file.
2. The correct application locale and version are specified in the app.json file

My launch.json file looks like this:
{
	"version": "0.2.0",
	"configurations": [
		{
			"type": "al",
			"request": "launch",
			"name": "Local server",
			"server": "http://b12b2204a385",
			"serverInstance": "NAV",
			"tenant": "",
			"authentication": "UserPassword",
			"startupObjectId": 22
		}
	]
}

And my app.json:
{
  "id": "345b5f4c-51a9-4330-9726-27e544e83249",
  "name": "Docker_demo01",
  "publisher": "Default publisher",
  "brief": "",
  "description": "",
  "version": "<IP_ADDRESS>",
  "compatibilityId": "<IP_ADDRESS>",
  "privacyStatement": "",
  "EULA": "",
  "help": "",
  "url": "",
  "logo": "",
  "capabilities": [],
  "dependencies": [],
  "screenshots": [],
  "platform": "<IP_ADDRESS>",
  "application": {
    "version": "<IP_ADDRESS>",
    "locale": "US"
  },
  "idRange": {
    "from": 50100,
    "to": 50149
  }
}

Version of the AL Language extension is: 0.9.13932. Seems like it's a September update from change log. Don't have options to update to October version yet.
Output of $PSVersionTable (from a powershell process):
Name                           Value
----                           -----
PSVersion                      6.0.0-beta.8
PSEdition                      Core
GitCommitId                    v6.0.0-beta.8
OS                             Microsoft Windows 10.0.15063
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

available country versions of the october preview is -finus, -fingb, -finca and -findk (not -us)
navdocker.azurecr.io is a temporary image repository which will be deleted soon. There might be old versions out there and you have found one.

Thanks! I was able now to download symbols from server image:
[2017-10-25 <IP_ADDRESS>] Using reference symbols cache path: c:\Users\ivand\Documents\AL\Docker_demo01\.alpackages [2017-10-25 <IP_ADDRESS>] All reference symbols are already downloaded
Still not able to build Hello World app:
Microsoft (R) AL Compiler version 0.9.13932 Copyright (C) Microsoft Corporation. All rights reserved
c:\Users\ivand\Documents\AL\Docker_demo01\HelloWorld.al(5,45): error AL0247: The target Page "Customer List" for the extension object is not found Error: The package could not be created.

This one probably belongs on AL/issues - but instead of the Hello World sample - try to create a new with AL GO! (Ctrl+Shift+P - AL GO!) - select local server and modify launch.json with what you have on the landing page.

I also see, that you are using an old AL compiler in VS Code (0.9.13932) - you should uninstall that and install the new, which is available in the docker image (docker logs  will show you the url to use to download the .vsix)

You were right, it was because of the AL version of extension. Thanks!

I was wondering what that .vsix file was in docker image log but now I know.


leo_robot: 2.3.0-1 in 'noetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository leo_robot to 2.3.0-1:

upstream repository: https://github.com/LeoRover/leo_robot.git
release repository: https://github.com/fictionlab-gbp/leo_robot-release.git
distro file: noetic/distribution.yaml
bloom version: 0.11.2
previous version for package: 2.2.0-1

leo_bringup

No changes

leo_fw
* Add IMU gyro calibration (#9 <https://github.com/LeoRover/leo_robot/issues/9>)
* Contributors: Aleksander Szymański

leo_robot

No changes

This requires #34210 to build.

Holding for Noetic sync


Touch up

Additionally this repository should be renamed to vsts-picklist-colors-control and all of the github links updated.

GitHub lets you rename a repository, you should probably do that.


Error opening dcm files

Describe the bug
i have the error when open dcm files multiframe (only one .dcm file)
this happens with local or remote files
Error read Dicom via Diakon parser

I have the some error. Did you fixed it?

updates on this error?

@darkdantez, @bircastri, @AdolfoBanchio thanks for raising this problem,
Recently we have released MRI-viewer version 2.0. You could try it out.
If you face any problems please open new issue with details and screenshots.
Thank you.


failed to connect to instance: Dial error: failed to dial

Bug Description
Since we've upgraded from 1.*.* to 2.*.* we have been noticing 'a lot' of "failed to connect to instance: Dial error: failed to dial (connection name = "******"): dial tcp **.***.***.**:3307: i/o timeout" errors in the SQL Proxy container. We have been trying to debug this issue, but there doesn't really seem to be a clear explanation for it. It is happening across multiple (PHP) applications using different frameworks. Downgrading back to 1.*.* seems to resolve the issue, which (I think) rules out that it is network related. The database is not under (very) heavy load and we're only using ~5% of our connections limit.
Example code (or command)
...
      - command:
        - /cloud-sql-proxy
        - --health-check
        - --http-address=<IP_ADDRESS>
        - --credentials-file=/secrets/cloudsql/cloudsqlproxy-credentials.json
        - --max-sigterm-delay=60s
        - --structured-logs
        - --quiet
        - toppy-***:europe-west4:toppy-***-database
        image: eu.gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.2.0
        imagePullPolicy: IfNotPresent
        name: cloudsqlproxy-container
        ports:
        - containerPort: 3306
          protocol: TCP
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        securityContext:
          allowPrivilegeEscalation: true
          privileged: false
          readOnlyRootFilesystem: false
          runAsGroup: 65532
          runAsNonRoot: true
          runAsUser: 65532
        startupProbe:
          failureThreshold: 20
          httpGet:
            path: /startup
            port: 9090
            scheme: HTTP
          periodSeconds: 1
          successThreshold: 1
          timeoutSeconds: 5
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /secrets/cloudsql
          mountPropagation: None
          name: cloudsqlproxy-service-account
          readOnly: true
...

Stacktrace
n/a

Steps to reproduce?

Not sure, included the sidecar yaml

Environment

OS type and version: GKE 1.25.8-gke.500, Container-Optimized OS with containerd (cos_containerd)
Cloud SQL Proxy version (./cloud-sql-proxy --version): 2.2.0
Proxy invocation command (for example, ./cloud-sql-proxy --port 5432 INSTANCE_CONNECTION_NAME): /cloud-sql-prox --health-check --http-address=<IP_ADDRESS> --credentials-file=/secrets/cloudsql/cloudsqlproxy-credentials.json --max-sigterm-delay=60s --structured-logs --quiet toppy-***:europe-west4:toppy-***-database

Additional Details

Connection is made over a public IP

Edit: updated yaml

@Swahjak Thanks for raising an issue on the Cloud SQL Proxy 😄
handing this over to @hessjcg who is our GKE specialist, he should be able to shed some light on this and hopefully help you get to the bottom of additional errors being seen.

This is surprising.
What region do your GKE nodes live in compared to your instance?

CloudSQL is in europe-west4-b and GKE in europe-west4-a

Downgrading to 1.x.x does seem to reduce the amount of error messages, but we are still seeing couldn't connect to "toppy-***:europe-west4:toppy-***-database": dial tcp 35.2**.2**.2**:3307: connect: connection timed out every now and then (different message, but I assume it's the same issue).

Screenshot from error reporting on one of our applications where we returned to 1.23.x without healthchecks, patched at ~12:30

Screenshot from error reporting on one of our applications where we returned to 1.33.x with healthchecks, patched at ~16:30
We're seeing the same results in the cloud-sql-proxy logs, where the amount of errors seems to align with the errors reported by the applications.

Normally i/o timeout errors indicate no network path from the Proxy to the instance. Assuming there are no changes in your environment to limit access to your public IP, I see one thing that might be worth trying: the resource limits are smaller than we usually recommend.
Compare:
resources:
  requests:
    cpu: 100m
    memory: 100Mi

vs (what we recommend as a starting point):
resources:
  requests:
    # The proxy's memory use scales linearly with the number of active
    # connections. Fewer open connections will use less memory. Adjust
    # this value based on your application's requirements.
    memory: "2Gi"
    # The proxy's CPU use scales linearly with the amount of IO between
    # the database and the application. Adjust this value based on your
    # application's requirements.
    cpu:    "1"

I'd suggest starting with these large values and then adjusting based on observed usage. This could be a case of CPU throttling.

All good points. I'm wondering if the healthcheck in v2 is causing the difference.

@Swahjak thanks so much for posting this issue.  I've been tearing my hair out trying to figure what I am doing wrong (and maybe I am still doing something wrong), but I am getting exactly the same message as you.  I am setting up a new Kubernetes cluster from scratch and this is my first time hooking up to Cloud SQL, so I have no history to compare against.
I want to test by dropping back to the earlier version, what is the image you are using for the 1.x.x? so I can give it a go.
I have tried:
image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:1.33.7

and
image: gcr.io/cloud-sql-docker/gce-proxy:1.33.7

but in each case I get image pull failures
Also, just a quick dumb question, but just to be sure, when I connect to the database, the name I pass is the name of a database on the database instance and not the name of the database instance?  and I can connect on the standard port and using localhost, I've tried both localhost and <IP_ADDRESS>, I just want to make sure I've not made a silly snafu.
The Google docs are always just a little light on some of these more basic details.
Many thanks,
Ross

Oh, I should also have said, I am using the default sidecar configuration as described in the Google docs here, so I have the recommended resources.

@RossAddinall the image pull issue is because you have a slight typo in your second attempt. (cloudsql-docker instead of cloud-sql-docker)
The v1 image should work with the following:
image: gcr.io/cloudsql-docker/gce-proxy:1.33.7

when I connect to the database, the name I pass is the name of a database on the database instance and not the name of the database instance?

Are you referring to the INSTANCE_CONNECTION_NAME?
The INSTANCE_CONNECTION_NAME for your instance can be found on the Overview page for your instance in the Google Cloud console or by running the following command:
gcloud sql instances describe <INSTANCE_NAME> --format='value(connectionName)'

Where INSTANCE_NAME is the name of your Cloud SQL instance.
If you are referring to DB_NAME when connecting that is the name of the actual database on the instance itself and not the instance name.

I can connect on the standard port and using localhost, I've tried both localhost and <IP_ADDRESS>?

Yes both localhost and <IP_ADDRESS> should work for connections. Although we normally recommend <IP_ADDRESS>.
Hope this helps clarify.

@jackwotherspoon many thanks for your help, in fact it turns out that it was my mistake, if you don't mind I'll document here what I did.
TLDR is:
The Cloud SQL proxy is attempting to connect to the Public IP address of the Cloud SQL instance.  I was unable to get to that IP from my container and edited my egress NAT policy following this.  Once I added a CIDR for the Cloud SQL Public IP address (x.x.x.0/24), things started working (afaik).
Answers to @jackwotherspoon question:
I was actually referring to the DB_NAME and I was using the name of a database running on the database instance, though not initially!
Longer version:
This is what I did after the input from @jackwotherspoon:

Corrected the typo in the image I was pulling for the Cloud SQL proxy.  When kubectl applying the deployment I got CrashLoopBackOff errors, this is because the 1.x.x image appears to look for a command:, instead of an args: entry.  I spotted this in this video and this is what I used:

image: gcr.io/cloudsql-docker/gce-proxy:1.33.7
command:
  - /cloud_sql_proxy
  - '-instances=<INSTANCE_CONNECTION_NAME>=tcp:5432'

when this finally ran I got an error message:
2023/06/15 13:33:20 current FDs rlimit set to 1048576, wanted limit is 8500. Nothing to do here.
2023/06/15 13:33:21 Listening on <IP_ADDRESS>:5432 for xxx
2023/06/15 13:33:21 Ready for new connections
2023/06/15 13:33:21 Generated RSA key in 295.212694ms
2023/06/15 13:33:30 New connection for "xxx"
2023/06/15 13:33:30 refreshing ephemeral certificate for instance xxx
2023/06/15 13:33:30 Scheduling refresh of ephemeral certificate in 54m59s
2023/06/15 13:35:42 couldn't connect to "xxx": dial tcp x.x.x.x:3307: connect: connection timed out

this convinced me (more than the 2.x.x output), that this was a connectivity issue.  It was also at this point that I realised that the IP address was the public IP of the Cloud SQL instance, which I hadn't grokked previously.
I then switched back to version 2.3.0 and when I remembered to also switch to the args format, that all worked as well - so far.
I wanted to know if I could get to that IP from my container, so I did:
kubectl exec deployment-7744bdb78b-d74dl  -i -t -- bash -il

I can't use ping in my container so I used:
wget -T 30 x.x.x.x:3307

and observed that it timed out.
I then decided I needed to configure my egress.
I looked at this which then lead me to this.
I created an egress-nat-policy.yaml as described in that final document and I defined a CIDR for x.x.x.0/24 and applied it to my cluster:
kubectl apply -f egress-nat-policy.yaml

At this point the wget failed instantly with error getting response
And my container started correctly and connected to the database.

Circling back to @Swahjak's original question. Are you seeing any improvement with increased resource requirements?

Hey @enocom thank you for getting back on this issue. I have been experimenting with some different resource assignments, but haven't seen any significant improvements (besides switching back to 1.x.x). I must say I haven't been fully focused on this issue due to other priorities, so I haven't been monitoring very closely.
Just a thought, but could connecting through a unix socket make any difference? Is that more / less resource intensive? In any case I'm never going to be able to mach the indicated resources since that would make cloudsqlproxy a very pricey tool (compared to the application infrastructure).

So I've been monitoring this more closely and actively changing resources, but it doesn't seem to make any difference. I'm starting to lean more towards a networking issue. Currently thinking about switching to a private IP on Cloud SQL to see if this makes any difference.

Separately, if you have a support account, it would be worth opening a case, just so we could dig into the backend details some more in case there's something wrong here.

Last week we have migrated to private IP and using Google Cloud DNS with GKE and we haven't seen these problems any more. So I guess this was somehow related to DNS. Even returned the resource to the 'low' values (compared to the advised values).
Than means that from my perspective this can be marked as resolved. Thank you for your time and effort in helping me resolve this issue.

Does migrating to private IP mean you've removed the Proxy from the connectivity path?
I've heard anecdotal data that private IP is faster, but don't have any hard data on that.

@enocom no, the proxy is still there. We started using the --private-ip flag now (and a private IP on the SQL instance obviously).

Ah got it. In that case I'll close this. Thanks for your patience on this.
Out of curiosity, how does Cloud DNS come into the picture?

@enocom since the problems seemed somehow 'connection' related I was looking into the GKE DNS settings, which now allows you to use 'Cloud DNS' instead of 'kube-dns'. I'm not sure if it was the private ip option (not going through egress/ingress NAT) or DNS which in the end resolved the issue since both were applied at the same time.

That's very interesting and good to know. Kubernetes networking is largely unknown to me, but I have anecdotal evidence like this that suggests it can affect connectivity (even though it seems like it shouldn't).

I know this is closed, but just wanted to add that I ran into this issue as well. Hopefully the extra details help!
I am running Kong inside our GKE clusters, and it was repeatedly crashing and restarting because of failures to connect to its database. We tried increasing memory and CPU on both the Kong pods and the CloudSQL instance, increasing connection timeouts from Kong to postgres, etc. Pretty much anything we could think of to increase we tried. All the metrics we were seeing were showing minimal usage across the board, and no real blocking happening on the CloudSQL instance (both cpu and io) either. We finally tried switching to a private IP on the CloudSQL instance yesterday and the errors stopped. We were getting about 40 error logs every 30 minutes, but since 3pm yesterday we haven't had a single one, which is great! But also confusing as to why that fixed it.
We are running the us.gcr.io/cloud-sql-connectors/cloud-sql-proxy:2.6.0 image. We never really saw this be an issue on the v1 proxy image, but it's been awhile since we ran that.

Thanks for the info @jault3. It's helpful.
FWIW v1 proxy would try to dial public IP first and then fallback to private IP. V2 defaults to public and expects users to explicitly choose private IP (--private-ip). Did your instance have a public IP when you saw these failures?

Yep, our instance had a public IP only when we saw the issues (private was disabled). When we switched, we enabled the private IP on the instance, then added the --private-ip flag to our cloud-sql-proxy command.

Got it. It's unclear why public IP would cause this problem, but in any case private IP is a better path for both performance and security.

Super helpful thread, ran into the same issue.
FYI, I did not run into this issue when running my system on a Public GKE Cluster. However, when switching to a private network and running a private GKE cluster I started to encounter this. Moving to a private ip flag fixed this as well for me. Thanks.

I don't want to dig up old issues, but we had this exact issue happen to us during a migration from an old dedicated server to GKE.
We had been using Google Cloud SQL for our production database for a few months now and had no issues connecting to it externally through a Public IP. So, fairly confidently everything would go well, we moved our application to GKE expecting it all to go well.
This was our setup:

Set up MySQL 5.7 instance on Google Cloud SQL with a Public IP
Set up private autopilot cluster behind VPC router with fixed egress IP
Run a single pod with cloud sql proxy

name: sqlauthproxy
image: gcr.io/cloud-sql-connectors/cloud-sql-proxy
args:
    - '--quiet'
    - '--address=<IP_ADDRESS>'
    - '--port=3306'
    - '--credentials-file=/secrets/service_account.json'
    - 'x:europe-west1:x'

Run multiple pods with a traditional web app, using sqlauthproxy as the database host

Everything was fine during testing. Then we swapped our DNS to go from the old dedicated server to GKE, which caused all of our users to now go to the GKE cluster and suddenly the sqlauthproxy logs were being spammed with:
failed to connect to instance: Dial error: failed to dial (connection name = "x:europe-west1:x"): dial tcp <public ip>:3307: i/o timeout

In the application this issue manifested itself as intermittent long running requests that blocked everything. For example, 20 requests would go through just fine, then 1 random request would hang for ~30 seconds, complete (successfully, so DB queries did go through), and then back to normal for the next x requests.
Monitoring showed acceptable load on the database and the containers. We debugged the entire pipeline from our ingress to nginx, php-fpm,... and quickly reverted our DNS back to the old server while we investigated the issue.
In Apache benchmark we could reproduce the issue with some simple load testing. It looked like this:
Percentage of the requests served within a certain time (ms)
  50%     74
  66%     80
  75%     86
  80%     92
  90%    108
  95%    174   <-- all good :D
  98%  14200 <-- what the heck? >:(
  99%  30309
 100%  30318 (longest request)

To fix:

We enabled Private IP on the SQL instance (this caused 5 minutes of downtime btw)
Added the --private flag to the proxy container arguments

Now the benchmarks have a more acceptable distribution (50% 100ms, 100% 3000ms).
We're going to try swapping the DNS back after running some more tests to see if this was the culprit of our botched migration or if we have to dig deeper.
tl;dr: Some networking issue between a private GKE cluster and a public SQL instance using sql auth proxy was causing ~2% of requests to time out. Switching to private ip on the SQL instance fixed the issue in synthetic benchmarks.

Thanks for the detailed write-up @jannes-io. I think private IP is a better option in general, but it's concerning that we're seeing these high tail latencies.
I half wonder if Cloud NAT might be involved here (which would be at play for anyone running inside a private GKE cluster reaching out to a public IP). For example: https://cloud.google.com/nat/docs/troubleshooting#insufficient-ports.


Support for BPMN diagrams

It would be useful to have support for BPMN diagrams in the same way as UML diagrams are supported.
https://bpmn.io/toolkit/bpmn-js/ provides a generator for bpmn diagrams. The only drawback is that the output is in a xml format
Example
  <bpmn:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" id="Definitions_0c3bzp5" targetNamespace="http://bpmn.io/schema/bpmn" exporter="bpmn-js (https://demo.bpmn.io)" exporterVersion="3.4.0">
  <bpmn:process id="Process_0niaa36" isExecutable="false">
    <bpmn:startEvent id="StartEvent_1a2l2kc" name="Start">
      <bpmn:outgoing>SequenceFlow_17igved</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:endEvent id="EndEvent_1wv91wl" name="End">
      <bpmn:incoming>SequenceFlow_0fpenox</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:task id="Task_1d1n4dh" name="Task">
      <bpmn:incoming>SequenceFlow_17igved</bpmn:incoming>
      <bpmn:outgoing>SequenceFlow_0fpenox</bpmn:outgoing>
    </bpmn:task>
    <bpmn:sequenceFlow id="SequenceFlow_17igved" sourceRef="StartEvent_1a2l2kc" targetRef="Task_1d1n4dh" />
    <bpmn:sequenceFlow id="SequenceFlow_0fpenox" sourceRef="Task_1d1n4dh" targetRef="EndEvent_1wv91wl" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="BPMNDiagram_1">
    <bpmndi:BPMNPlane id="BPMNPlane_1" bpmnElement="Process_0niaa36">
      <bpmndi:BPMNShape id="_BPMNShape_StartEvent_2" bpmnElement="StartEvent_1a2l2kc">
        <dc:Bounds x="156" y="103" width="36" height="36" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="162" y="146" width="25" height="14" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="EndEvent_1wv91wl_di" bpmnElement="EndEvent_1wv91wl">
        <dc:Bounds x="463" y="103" width="36" height="36" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="471" y="146" width="20" height="14" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Task_1d1n4dh_di" bpmnElement="Task_1d1n4dh">
        <dc:Bounds x="290" y="81" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="SequenceFlow_17igved_di" bpmnElement="SequenceFlow_17igved">
        <di:waypoint x="192" y="121" />
        <di:waypoint x="290" y="121" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="SequenceFlow_0fpenox_di" bpmnElement="SequenceFlow_0fpenox">
        <di:waypoint x="390" y="121" />
        <di:waypoint x="463" y="121" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

I guess we could do something similar as our existing UML and sequence diagram support by adding a BPMN option and then putting the XML into the code fence. We can then use the suggested library to load the XML and view it on a canvas, which is really similar.
My only real problem with that approach is that you now have a bunch of XML embedded in your feature files, which isn't very readable. Of course that wouldn't matter if your reading it in Augurk, but you'll have to potentially wade through a whole bunch of XML when editing the feature in your editor.
@marktaling Do you have any thoughts on this?

Including the BPMN wouldn't be hard, but I agree it would make your feature files rather unreadable. I do wonder what the usecase is here. Will it be used in actual feature files, or be uploaded by itself (without any scenarios)?
Most elements in BPMN we can already render with our UML and/or sequence diagrams. So it wouldn't be hard to include BPMN but that would require a custom notation which I am currently not a big fan of.
I am not very familiar with BPMN, are there any other tools out there which see a lot of use? Perhaps we can find a slightly more readable approach?
Alternatively, we could include the XML the same way we embed images, merging it in during upload so you do not have the entire (rather unreadable) xml in your feature during editing.

Perhaps it is possible to create a new library based on nomnoml that supports BPMN?
The basic principles are the same.
I'll give it a try....

@RemcoSpil If you succeed, we would be happy to include it.
If not, let us know and we will take a look at including the xml in a non-obtrusive way.


Add xfail to test_read_parquet_schema_validation_with_index_column

Feature or Bugfix

Bugfix

Detail

Add xfail to test_read_parquet_schema_validation_with_index_column since ignore_index was removed

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 99ca5b3adb37d0ecfde3190fcc5c802665743013
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubLoadTests5656BB24-s6u9F3qN9oFy
Commit ID: 99ca5b3adb37d0ecfde3190fcc5c802665743013
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubStandardCodeBuild8C06-llutOAimTATs
Commit ID: 99ca5b3adb37d0ecfde3190fcc5c802665743013
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubStandardCodeBuild8C06-llutOAimTATs
Commit ID: 99ca5b3adb37d0ecfde3190fcc5c802665743013
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubStandardCodeBuild8C06-llutOAimTATs
Commit ID: 99ca5b3adb37d0ecfde3190fcc5c802665743013
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubStandardCodeBuild8C06-llutOAimTATs
Commit ID: 99ca5b3
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

Only fails due to the intermittent TimeStream errors.


chore: extend access token expiration time

Issue #, if available:
Description of changes:
chore: extend access token expiration time
Extend access token expiration to 60 minutes to allow integration tests to run successfully. Once MAFoundation-310 has been implemented to allow multiple clientIds, we'll create a separate client for integration tests and the "main" client access token expiration time can be return to 15 minutes
Checklist:

[ ] Have you successfully deployed to an AWS account with your changes?
[ ] Have you written new tests for your core changes, as applicable?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Updated to make access token expiration time configurable


Add influxd subcommands for setup actions w/o running the full HTTP server

Proposal:
It would be useful for (at least) our DockerHub entrypoint if we could do the following without booting up a full influxd web server:

Answer "is the influxd server already set up"?
Run the steps taken by the onboarding API to set up an initial influxd instance, persisting the resulting metadata

Current behavior:
To check the above, you have to boot up a full instance of influxd and then either curl the web API or use influx setup
Desired behavior:
I'd like to add new CLI subcommands to influxd:

Given the path to a bolt DB, check if the bolt exists & contains the initial metadata created by the onboarding API
Given the arguments to influx setup and an output path, generate initial metadata and write the result as a bolt DB to the output

Alternatives considered:
In the Docker use-case, the alternative to using the above commands would be to boot an instance of influxd and use curl / influx to perform initial setup. That approach is difficult to get right because we want users running Docker to be able to pass in custom config / arguments, which could modify the HTTP port used by the server. If we run the "setup" instance of influxd using the passed-in custom config / arguments, we'll need to somehow find the right HTTP port to use (either by parsing the input args, or by inspecting the influxd logs). If we run the "setup" instance of influxd without any of the custom configs, we could end up generating a bolt DB at the wrong path.
Use case:
Restoring our DockerHub build is top priority for the upcoming 2.0.4 OSS release.

Closing this as we found a lighter-weight approach to get what we needed.


Add deprecated functionality which can't be communicated to the user otherwise

Can't be communicated to the user by deprecating APIs or logging.
Follow up to https://github.com/apache/brooklyn-server/pull/562.

LGTM


Add basic keymaps to the original buffer

Let's add basic keymaps to the original buffer that will affect it's chase buffer.
Added keymaps:

[ ]  q: to destroy(quit) the chase buffer
[ ]  cd: to destroy the chase buffer, same as q
[ ]  cc: chase this buffer aka run file and show chase buffer

I'm implementing the cc by the file type chase code, for instance, the cc will be added by chase.python to the chase.on_buffer_enter.

Scope of this task is set just to the python original but other languages will use the same code in the general purpose chase.


Make twofishes start with system locale

Fix the init script to export the LANG locale environment variable, which fixes an error with the startup of twofishes, where it is not happy trying to read its database with the ASCII encoding.  It should try to use UTF8.
The twofishes init script was failing to start twofishes upon reboot.

Looks pretty simple. :+1:

:white_check_mark:


Upgrading to Vue 3.2.x breaks the Popper component

Hi, great work on the library I am enjoying it! I was using Vue-3-popper v1.2.1 and Vue 3.1.2 and it works fine, but when I try to upgrade Vue to 3.2.x and Vue-3-popper to 1.3.0 I get strange runtime errors that I cannot explain. Hoping you can help me fix it.
These are the 2 errors I see, which prevents my entire view from loading.

I've followed the documentation and made my own wrapper component for the Popper component.
I use it like this in my view:
 <PopoverIcon	class="d-inline-flex" :content="$tc('contractOverview.table.contractExpirationWarning', {								count: item.data.remainingDays})"><i class="pi pi-exclamation-circle" /></PopoverIcon>
However, when I try to upgrade to Vue 3.2 even the sample component does not work for me. I think it could be related to the slot property, but seeing as even the example does not work I don't know how to fix it. Any idea what could be causing this?

I believe this works and it's also simpler looking.
I updated the docs.


Rename recipe.yaml and plugin.yaml to metadata.yaml

This has been on my mind for a very long time but I wanted to wait for when the other renaming topics are closed.
I found the name for recipe.yaml and plugin.yaml in recipe and plugin folders very confusing. The naming suggests that the content of the recipe or plugin are inside these files. I think metadata.yaml is a much better name.
What do you think @AntoineDao? This is not a critical change and I'm fine to keep it as is if you have a strong opinion on the current naming.

Yep I don't see any reason to not change them. It is probably less confusing this way. Might be worth considering package.yaml (similar to NodeJS' package.json)

package.yaml it is!


python3Packages.colour-science: init at 0.4.4

Description of changes
Hey!
This PR adds the colour package by colour-science (https://github.com/colour-science/colour). Since the package's name conflicts with an existing package named colour by vaab (https://github.com/vaab/colour already in nixpkgs), I named this new package colour-science.
I disabled some tests, some of them are very (very) slow, and 4 others are not passing (they fail to read/write an EXR file, I couldn't find a fix).

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 280956

x86_64-linux

:white_check_mark: 2 packages built:

python311Packages.colour-science
python311Packages.colour-science.dist

Hi @FliegendeWurst!
That's quite peculiar :thinking:, what's architecture, and how did you launch the tests ?

Hi @FliegendeWurst!
That's quite peculiar :thinking:, what's your architecture, and how did you launch the tests ?

Also x86_64 Linux. I simply ran nix-shell -p python3Packages...


Permission Issue with GITHUB_TOKEN

Hi, I found that there might be a permission problem with secrets.GITHUB_TOKEN at line 24 in grading.yml. I followed the instructions carefully but could not let github-actions generate a new Issue.
The error I got was
Run<EMAIL_ADDRESS>  with:
    github-token: ***
    feedback: {"reports":[{"filename":"","isCorrect":true,"display_type":"issues","level":"info","msg":"Great job!","error":{"expected":"","got":""}}]}
Error: HttpError: Resource not accessible by integration

I replaced secrets.GITHUB_TOKEN with secrets.EXERCISE_PAT and it worked. I tried another way by changing the Workflow permission in Settings-Actions-General of this repository to read and write permissions, and secrets.GITHUB_TOKEN also worked this time.

Same here, but it is not worked for me to replace "GITHUB_TOKEN"


improvement Empty wal should be deleted when replaying it

Proposed changes
Empty wal file can never be recovered, so it should be deleted when replaying task found it.
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall


Python 3.12 tests issuing DeprecationWarning related to multiprocessing

test_app_runner.py::TestAppRunner::test_code_update   /usr/local/lib/python3.12/multiprocessing/popen_fork.py:66: DeprecationWarning: This process (pid=92883) is multi-threaded, use of fork() may lead to deadlocks in the child.     self.pid = os.fork()
@mmikita95 seems closely related to what you're working on this week, please have a look

I tried running this test on Python 3.12.1, macOS Sonoma 14.3 (M1 chip), and there is no such warning displayed for me. Is there maybe some additional info you could provide about this issue?
I must say that when I was setting up a new 3.12.1 environment (as mine was on 3.10), I've ran into issues with installing pyarrow-12.0.0/12.0.1, so I used Fabien's poetry setup to try to bypass it (successfully), and noticed that it installed a newer version, 15.0.0. I imagine this issue could be happening due to one of our dependencies, and I might've solved it unknowingly installing a newer version for it too.


Add support for explicitly male/female names?

Not sure if this is a generator architecture related issue but since D and d are marked as suitable for a stupid person's name I would expect there to be types of random replacements that indicate the gender of the name to be generated. What say you?

I suppose that could be a useful feature. The primary goal is to clone
the RinkWorks name generator, but also add some useful, backwards
compatible extensions. Your idea could perhaps be another kind of
replacement class with its own letter.

@skeeto
I have to admit, I have no idea if this is even possible. It boils down to a question what makes some names feminine and other masculine. In Lord of the Rings there is a made-up language and in that language some words mean feminine things, so we get a name such as Shelob . But for generic names, I have no idea. From a game developer's point of view it is crucial to specify for the generator whether the target character is male or female, without that the random name generator (RNG) is not very practical. I guess RNGs that utilize Markov chains would not have this problem but on the other hand they would require a large database of known feminine and masculine names.

@1Hyena, What you need is a list of name parts for each gender; normally, the gender is in the suffix of the name; you can also have a list of house names for different tribes, for example. Then you would use those tables as the source of the two or four or whatever generators for each gender/tribe combination.
In some implementation you can easily extend the generator tables by adding your custom tables to different symbols:
In c++, you would add your tables to this: https://github.com/skeeto/fantasyname/blob/4d97716d93846ffd6015d8a68298ba7f9df46d19/c%2B%2B/namegen.cc#L31
In JavaScript, you would add those to:
https://github.com/skeeto/fantasyname/blob/4d97716d93846ffd6015d8a68298ba7f9df46d19/js/namegen.js#L104
Afterwards, you can then use such symbols in your generator at compile time.
There’s an example of extended tables here:
https://github.com/Kronuz/Xapiand/blob/30004104e3f52b8a9666bacaf15862306557e356/src/namegen.cc#L128
That example adds prefixes “K”, “L”, “E”, “F”, “k”, “l”, “e”, “f” to play with. “K” and “k” have lists of male and female prefixes and suffixes, but they’re mixed. You’d need to split the tables in two symbols (one for each gender) and use them in two or more different generators: a female drow generator, a male drow generator)

@Kronuz
thanks for the example. the solution you provided is indeed compatible with my namegen.cpp. Perhaps the main problem now is to have the actual name formulas for a relatively large number of races, including critters/vermin :D any pointers? It's a shame such public databases aren't easily available

@1Hyena I have no idea... if you come across such collection of names, or put one together, I’d be very interested. I’d love have there ability to generate names for multiple races.


Make pipeline teams optional

As issue #48 points out, teams are only a thing on paid plans. This makes the team block optional and updates the readme including a warning about non-admin users creating a pipeline without a team. I'd imagine this doesn't error on a free plan but does error on a paid plan.
Resolves #48

Here's the teams page for a new organization:

It's an optional feature because it subtly changes how permissions work and we didn't want to change that for all historical organizations. :-)

FYI I've added a property to organizations via graphql which indicated whether teams is enabled or not:
query {
  organization(slug: "...") {
    isTeamsEnabled # true/false
  }
}

I'm not sure it makes sense to use here, but it's available nonetheless.


WIP: Calls

Trying to familiarize myself with the EVM, I may need some help though.
The fallback function in Dummy contract is indeed called, but reverts for some reason and I don't understand why.
Thank you very much for this amazing repo, it's a real gold mine.

Finishing in #51 will add you as an author 😄


ROS

I did catkin_make on Firmware folder in my computer and it finished cleanly and without any error but when I
did << roslaunch px4 posix_sitl.launch >> following error appeared but I don't know why ?
(
Invalid  tag: mavlink_sitl_gazebo
ROS path [0]=/opt/ros/kinetic/share/ros
ROS path [1]=/home/alireza/catkin_ws/src
ROS path [2]=/opt/ros/kinetic/share.
Arg xml is
The traceback for the exception was written to the log file.
)
could someone please tell me the reason ?

you need to source the firmware folder

Hi Tobias
you mean :
source Tools/setup_gazebo.bash $(pwd)
$(pwd)/build/posix_sitl_defaultexport
ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:$(pwd)export
ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:$(pwd)/Tools/sitl_gazebo
?
I have sourced it but still my ROS master doesn't find it !
On Mon, Nov 13, 2017 at 1:10 PM, Tobias M<EMAIL_ADDRESS>wrote:

you need to source the firmware folder
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/PX4/Firmware/issues/8205#issuecomment-343864129, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AezLU6VzwGTxiyZnHxAIkLzoMj7Xytmfks5s2A6ggaJpZM4QJ5sj
.

but you were in your firmware folder while sourcing it?

I created a catkin_ws and I included firmware in it , I did catkin_make and it finished cleanly without any error but when  lauched 《 roslaunch px4 posix_sitl.launch 》the error I mentioned aboved appeared.

Should I be in firmware folder ?

 cd %FIRMWARE PATH% source Tools/setup_gazebo.bash $(pwd) $(pwd)/build/posix_sitl_defaultexport ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:$(pwd)export ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:$(pwd)/Tools/sitl_gazebo

Thanks Tobias
On Nov 16, 2017 1:50 PM, "Tobias M."<EMAIL_ADDRESS>wrote:

cd %FIRMWARE PATH% source Tools/setup_gazebo.bash $(pwd)
$(pwd)/build/posix_sitl_defaultexport ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:$(pwd)export
ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:$(pwd)/Tools/sitl_gazebo
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/PX4/Firmware/issues/8205#issuecomment-344878886, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AezLU5tD3K2XwvUDriHk8vRqW7gOMfu7ks5s3AxPgaJpZM4QJ5sj
.

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)


Prometheus Stackdriver Sidecar error component="Prometheus reader" msg="target not found"

The stackdriver sidecar injected into prometheus pod (deployed by prometheus-operator) does not send application metrics to Stackdriver. With the default sidecar configuration I can see default metrics related to alertmanager, prometheus, go, kubedns in stackdriver but the application metrics are missing. In the sidecar container logs I can see such errors constantly (with logging level debug enabled):
level=debug ts=2020-04-27T08:58:48.172Z caller=series_cache.go:354 component="Prometheus reader" msg="target not found" labels="{name="cluster_quantile:apiserver_request_duration_seconds:histogram_quantile",component="apiserver",endpoint="https",group="scheduling.k8s.io",job="apiserver",namespace="default",quantile="0.9",resource="priorityclasses",scope="cluster",service="kubernetes",verb="WATCH",version="v1"}"
Technical details:

Sidecar version: 0.7.3
Prometheus operator version: v0.30.1
relabel_config is configured (multiple)
Sidecar args:

"--stackdriver.project-id=${GCP_PROJECT}"
"--prometheus.wal-directory=/prometheus/wal"
"--stackdriver.kubernetes.location=${GCP_REGION}"
"--stackdriver.kubernetes.cluster-name=${KUBE_CLUSTER}"
"--log.level=debug"

I have the same troubles. Any ideas?

I found https://github.com/Stackdriver/stackdriver-prometheus-sidecar/issues/104#issuecomment-669909442

I noticed, from the colons in the name, that this is a recording rule.
My team recently sunk ~3 days into debugging just this issue. I think our findings will be helpful here.
Basically: the sidecar makes assumptions about the relationship between scrape targets and metrics that don't universally hold when the metric in question is a recording rule.
The key here is targets/cache#targetMatch, reproduced below:
// targetMatch returns the first target in the entry that matches all labels of the input
// set iff it has them set.
// This way metric labels are skipped while consistent target labels are considered.
func targetMatch(targets []*Target, lset labels.Labels) (*Target, bool) {
Outer:
	for _, t := range targets {
		for _, tl := range t.Labels {
			if lset.Get(tl.Name) != tl.Value {
				continue Outer
			}
		}
		return t, true
	}
	return nil, false
}

Basically, for every metric, the sidecar tries to find at least one scrape target for which the metric's label set is a strict superset of the target. If it can't find one, the sidecar will refuse to write the metric to Stackdriver, resulting in the target not found error.
With "normal" metrics, this assumption might hold just fine. However, consider a scrape target target0 that provides label set {job, instance, foo, bar}. Say a metric metric0 gets scraped from target0, and we have recording rule recorded:metric0 that "removes" foo and bar from metric0 via some "downsampling" operation like sum by (job, instance) (metroc0).
When the sidecar tries to write recorded:metric0 to Cloud Monitoring (Stackdriver), it'll comb through the set of known scrape targets, see that the label set in target0 is not fully represented in recorded:metric0, emit the target not found error, and ultimately refuse to write recorded:metric0 to Cloud Monitoring.
The solution is to make sure that your recording rule is always "associated" (in the way defined here w.r.t. label sets) with at least one scrape target. If this scrape target only confers labels job and instance, then both the sidecar and Cloud Monitoring (which requires those two labels) are happy, and so are you. 😁
If any member of the sidecar maintenance team would like to chime in to confirm/refute/refine any of this, that'd be excellent. Otherwise, thanks team for enabling Prometheus-to-GCP metrics until today, and I look forward to migrating to GKE workload metrics as called out in #296.


Watch mode

A --watch mode could be nice to have, R.swift could monitor file changes and regenerate when needed so you don't need to kick off a build every time.

Pretty hard to build with all the Xcode env vars we use and not a priority right now.


[Bug]: Password length visible in login page

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
The minimum length of password is visible in login page
This should not happen
Expected behavior
Only the message for invalid password should be shown
Add ScreenShots

On which device are you experiencing this bug?
No response
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC-EXT contributor
[X] I'm a HACKTOBERFEST contributor
[X] I have starred the repository

@Gauravtb2253, I am not getting your exact thing could you please specify in detail..

The password length should be visible while registering and not while login
Like if someone tries to access other persons account he will get to know that the password is of x length
So it is not a good practice for security reasons to show the length in login page

can you pls add level2 label

Please add the changes photo

actually I am getting error in installing node_modules
But I have changed the error message in the zod validation schema
You can check there

this is the error


Fix bugzilla url in fetch_bugs.

Verified it locally. Current master raises ValueError: Invalid response from server. and this one seems to work as expected.

Coverage increased (+0.02%) to 92.0% when pulling 1134b31ab640b7f75086f8750d48e10371087a63 on akatsoulas:fix-fetch-bugs into 6e39bc11f7f618db015518e54833b2ecf6927efa on mozilla:master.

r+


Prevent hiatusing of threads from updating tagged_at

Widely requested (along with making abandoned do the same, but that seemed like it might require community input). This will prevent marking threads hiatused bumping them on Recently Updated and Unread.

Superseded by #1253


No Op change for a new build to pick latest images

Signed-off-by: sahare<EMAIL_ADDRESS>https://github.com/stolostron/backlog/issues/22075
https://github.com/stolostron/backlog/issues/22160

/cherry-pick release-2.4


Show existing projects

closes #153. This PR implements a show-existing-projects function (API and CLI). This will search the Path.home() / ".datashuttle" directory for any folder that has a config.yaml inside (assuming this is a project folder).
A test is added, it is not required to add to docs because these convenience functions are not explicitly documented but are in the auto-updated CLI / API.
This PR also does some minor refactoring to make the logic clearer. Overall this PR:

moves utils/get_datashuttle_path() to canonical_folders.py and splits the logic into two separate functions
does some minor refactoring of imports on folders.py
introduces folders/get_existing_project_paths_and_names function and API, CLI front-end functions
adds test function.

Thanks @niksirbi good point this is something thats bugged me for a while, I opened #221 to address this. It could run the gambit from not too bad to fix to very complicated 😄 but definately worth trying.


Director can accept bosh events via api call

#133560817
Signed-off-by: Konstantin Maksimov<EMAIL_ADDRESS>

Merged.


To lemmatize or not to lemmatize?

Hi, guys. Thank you for your research. It is extremely interesting and valuable for the community, and I mean it! I am curious why didn’t you use lemmatization or stemming of the words prior to analysis? Is it only due to the increased computational power required, or is there another reason I am missing?
From my perspective, your current approach may potentially underestimate the frequency ratio of some words. For example, from Figure 2, it is clear that the frequency of the word "delve" should be higher, as both "delves" and "delved" are presented in the figure.
I am asking because I am planning to conduct similar research with the Earth Science manuscripts and finding excess words specific for my domain.

To be honest, the main reason was "for simplicity", but one secondary reason was that we thought it may actually be interesting to look at all forms separately -- e.g. "delves", "delved" and "delve" may increase their usage by a different amount (because ChatGPT may prefer to use a specific form particularly often).
In retrospect I think it would actually be more sensible to lemmatize everything. We may change the analysis in future revisions, or possibly add a supplementary analysis with/without lemmatization. Depends also on how the peer review process will go.
It should be relatively straightforward, smth like this code given here https://scikit-learn.org/stable/modules/feature_extraction.html#tips-and-tricks:
from nltk import word_tokenize
from nltk.stem import WordNetLemmatizer
class LemmaTokenizer(object):
    def __init__(self):
        self.wnl = WordNetLemmatizer()
    def __call__(self, articles):
        return [self.wnl.lemmatize(t) for t in word_tokenize(articles)]

vectorizer = CountVectorizer(tokenizer=LemmaTokenizer())

Let me know if you try it out!

Thanks for that, I will let you know! Good luck with the peer-review.


portability: Fix printf format for 64-bit integers (fixes #20)

Thanks. I'm a little embarrassed I was apparently so lazy about this. :)

No problem, we all are sometimes :)


Add sender info to Signal initiated through SignalExternalWorkflowExecution

Is your feature request related to a problem? Please describe.
WorkflowExecutionSignaledEvent contains no reference to a workflow that sent the signal. For example:
    {
      "eventId": "71",
      "eventTime": "2023-02-23T17:19:23.051982830Z",
      "eventType": "WorkflowExecutionSignaled",
      "version": "0",
      "taskId": "265937709",
      "workerMayIgnore": false,
      "workflowExecutionSignaledEventAttributes": {
        "signalName": "endWorkflowSignal",
        "input": null,
        "identity": "history-service",
        "header": null
      }
    },

Describe the solution you'd like
WorkflowExecutionSignaled has a field that contains workflowID and runID of the workflow that sent the signal.
Describe alternatives you've considered
A temporary workaround would be populating the identity field with this information. This is not ideal as this field is just text.

Thank you for reporting this issue. This is a known issue that has been tracked here:  https://github.com/temporalio/temporal/issues/4014.

Thank you for reporting this issue.  You are correct; the WorkflowExecutionSignaledEvent doesn't currently include the workflow ID and run ID of the workflow that sent the signal.
We appreciate your proposed solution of adding workflowID and runID fields to the WorkflowExecutionSignaledEvent. This would provide valuable information for debugging and tracing signal events.  In the meantime, consider using the identity field for your temporary workaround as suggested.
We will consider this feature request for a future release of Temporal.

Thank you for reporting this! I understand the need to have access to the source workflow ID and run ID when handling WorkflowExecutionSignaledEvent. This is currently not supported and the identity field is not suitable for this purpose. We are looking into adding this feature in the future.
In the meantime, you can use the workaround you suggested by populating the identity field with the workflow ID and run ID. This is not ideal, but it will provide you with the information you need.
If this workaround does not work for your use case or you have any further feedback, please let us know. We appreciate your input!


Reduce measure errors

According to docs, pulseIn works better in noInterrupts() mode, so I added a critical section.
The float division is kept outside on purpose (it's slow and can run with interrupts enabled).
Moreover, there was an obvious copy-paste error in header file.
Hope it helps.

thank you
this is not specified on the arduino documentation

Yup. I found it by chance while looking at wiring_pulse.c, to check if it used interrupts...


The GUI is not working on Ubuntu

When launching a study from the GUI on Ubuntu (launched from the executable antares-xpansion-ui, nothing happens (no messages, no errors).
However, the GUI is running normally when launched with the Python launcher using python antares-xpansion-ui.py

hello,

it seems there are some troubles in PyQt5 package installed with pip in ubuntu :
at the end of build step I have theses messages :
WARNING: Cannot find libQt5EglFSDeviceIntegration.so.5
WARNING: Cannot find libxcb-xinerama.so.0 (needed by /ho
WARNING: Cannot find libxcb-xinerama.so.0 (needed by /ho
WARNING: Cannot find libQt5EglFSDeviceIntegration.so.5 (
WARNING: Cannot find libQt5EglFSDeviceIntegration.so.5 (
WARNING: Cannot find libQt5EglFsKmsSupport.so.5 (needed
WARNING: Cannot find libxcb-xinerama.so.0 (needed by /ho
WARNING: Cannot find libxcb-xinerama.so.0 (needed by /ho
WARNING: Cannot find libxcb-xinerama.so.0 (needed by /ho
WARNING: Cannot find libxcb-xinerama.so.0 (needed by /ho
WARNING: Cannot find libQt5EglFSDeviceIntegration.so.5 (
WARNING: Cannot find libicudata.so.56 (needed by /home/b
WARNING: Cannot find libicuuc.so.56 (needed by /home/bar
WARNING: Cannot find libicudata.so.56 (needed by /home/b
WARNING: Cannot find libxcb-xinerama.so.0 (needed by /ho
wich logically lead to an error when executing antares-xpansion-ui :

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb. Abandon (core dumped) (see full log.txt  debug message obtained with export QT_DEBUG_PLUGINS=1)
a cleaner version of Pyqt5 for ubuntu is given via the official ubuntu package : sudo apt install python3-pyqt5
see https://doc.ubuntu-fr.org/pyqt

With a successful installation,  there is a bug at run time. Nothing happens when run button is clicked.
pr #297 will fix it.
log.txt


[NOMERGE] drop in transforms v2 into the v1 tests

This PR should serve as migration test whether we messed something up in transforms v2 that was enforced by the v1 tests. If CI is green here, we can be reasonably confidence that v2 is actually a drop-in replacement for v1.

I worked on making all the test_transforms.py tests pass in 7e032ad
Most of the time it's trivial and not worth bothering about it, like different error messages. But there are some occurrences that require our attention. I marked them all as TODOs in the PR, but the main ones are:

we don't support get_params() on instances
we don't support (or maybe we just don't warn) passing ints as interpolate parameter

we don't support get_params() on instances

This is an oversight on my side. Fix in #7177.

we don't support (or maybe we just don't warn) passing ints as interpolate parameter

We intentionally did not port that behavior since it is deprecated and scheduled for removal in 0.15, i.e. the upcoming release:
https://github.com/pytorch/vision/blob/2cd25c1a05012a3720a87f20cec436811fadeedd/torchvision/transforms/transforms.py#L327-L333
I've opened #7176 to handle this as well as all the other scheduled removals.

Thanks a lot Philp. Regarding int support we need to make sure we raise a proper error now then

I made test_functional_tensor.py pass in 99bc85f. There are 2 important issues:

We do not support ints or tuples for fill in torchscript.
ElasticTransform seems completely broken (no idea why though).

OK, just took care of test/test_transforms_tensor.py. The common theme to most of the failures is that t(img) != scripted(t)(img).
This is probably because either:

for random transforms, sampling is performed differently between v1 and v2
there are other minor implementation differences bewteen v1 and v2

Either way, we should double check all of the those marked as TODO to make sure these are expected.
One thing to note though is that the assertion that t(img) != scripted(t)(img) really doesn't hold anymore. For random transforms the difference can be very significant (99% pixel difference). This is somewhat unexpected as this isn't how the V1 transforms behave. But I feel like this is something we can live with, as long as we document it.

We do not support ints or tuples for fill in torchscript.

This just seems like wrong annotations. We didn't change anything about the functionality so reverting back to whatever v1 has should do the trick. As for why our v2 tests are green: I designed the our tests along the annotations of the functions failing to realize how wrong they actually are. Meaning, we never tested tuples, hence the green CI:
https://github.com/pytorch/vision/blob/1120aa9e89d86bc466bba8f10ba382a5c63d6056/test/prototype_transforms_kernel_infos.py#L440-L454

ElasticTransform seems completely broken (no idea why though).

It should not just be ElasticTransform, but rather all transforms that internally use grid_sample. #6945 ported _apply_grid_transform while simultaneously doing some refactorings. The relevant here is https://github.com/pytorch/vision/pull/6945#discussion_r1021614214:

[...] Important note is that the input image must be float. This is because the handling/casting can be done more efficiently outside of the method.

In practice this meant dropping the
https://github.com/pytorch/vision/blob/1120aa9e89d86bc466bba8f10ba382a5c63d6056/torchvision/transforms/functional_tensor.py#L543
helper.
The error you were seeing was about the image and the grid not having the same dtype, which was handled by this helper. We do have some dtype conversion as well in v2
https://github.com/pytorch/vision/blob/1120aa9e89d86bc466bba8f10ba382a5c63d6056/torchvision/prototype/transforms/functional/_geometry.py#L1511
but this doesn't account for floating point inputs that are not float32, since grid is float32 unconditionally.
As for the reason why our v2 tests didn't catch this: in order to reduce time to signal we initially only wanted to test against uint8 and float32 and so this is the default (which is used almost everywhere) when creating images:
https://github.com/pytorch/vision/blob/1120aa9e89d86bc466bba8f10ba382a5c63d6056/test/prototype_common_utils.py#L298
https://github.com/pytorch/vision/blob/1120aa9e89d86bc466bba8f10ba382a5c63d6056/test/prototype_transforms_kernel_infos.py#L1266
I've opened #7195 to see if there are more bugs like this lurking in v2.
Since #6945 was mostly about performance and the top comment shows significant improvements for uint8 inputs. @vfdev-5 would you have time to investigate whether this comes from removing the helpers from _apply_grid_transform or from something else?

For random transforms the difference can be very significant (99% pixel difference)

IIUC, the times you experienced that is just for the family of AA transforms, right? That is expected, since we actually changed the sampling strategy there. This is why they have separate consistency tests:
https://github.com/pytorch/vision/blob/1120aa9e89d86bc466bba8f10ba382a5c63d6056/test/test_prototype_transforms_consistency.py#L826

and can even lead to images of different shape (see rotate)

For RandomRotation, the parameter sampling is equal:

v1
https://github.com/pytorch/vision/blob/1120aa9e89d86bc466bba8f10ba382a5c63d6056/torchvision/transforms/transforms.py#L1302
v2
https://github.com/pytorch/vision/blob/1120aa9e89d86bc466bba8f10ba382a5c63d6056/torchvision/prototype/transforms/_geometry.py#L338

What you are hitting here are slight differences of how the new expanded size is computed. Again #6945 introduced some performance optimizations that apparently can manifest as a +-1. Thus, we are seeing errors such as:
AssertionError: The values for attribute 'shape' do not match: torch.Size([3, 48, 60]) != torch.Size([3, 48, 59]).

Apart from that, the test passes without issues. IMO, we don't need to fix anything here, since I hope no one depends on the exact shape of an output that changes based on random sampling (with expand=True the output shape depends on the sampled angle).


Tell ci-build workflow to build main branch PRs

Motivation:
We were not getting builds for PRs
Modification:
Tell the ci-build workflow to build PRs that target the main branch.
Result:
We should now get builds for PRs.

The build fails because it doesn't have the changes from #1. This is to be expected, I guess.


plugin: support function/lambda in refctx

The user config may want to set the refctx based
on some command-line option.  However, the command-line
is not parsed until after the user config is loaded.
Thus, allow a function/lambda in refctx so the user
config can delay evaluation until the refctx is expanded
during test runtime.
For example, user config may want to use the platform
command-line value to determine an appropriate refctx.
But, media._get_platform_name() is not resolved until
after the user config is loaded.  Thus, the user config
can delay the evaluation based on platform when the
refctx is expanded during test runtime like so:
 refctx = [
  "driver",
  lambda: "gpu.gen" if media._get_platform_name() in ["XYZ"] else None
 ]

...this will produce ["driver", "gpu.gen"] only when the
platform name is "XYZ".  Otherwise, it produces ["driver"].
Finally, this result will be expanded as usual
(e.g. [drv.iHD, gpu.gen.12] or [drv.iHD], respectively).
The function/lambda should return a string or None.  If
None is returned, then it is ignored.
Signed-off-by: U. Artie Eoff<EMAIL_ADDRESS>

More examples:
refctx = [
  "driver",
  lambda: "gpu.gen" if media._get_gpu_gen() >= 11 else "legacy"
 ]

refctx = [
  lambda: "drv[{driver}].plat[{platform}]" if media._get_platform_name() in ["APL", "BSW"] else "drv[{driver}]"
 ]


JPA based deployment and unavailable data source doesn't fail when deploying

I'm using hibernate5 quickstart and removed src/main/webapp/WEB-INF/hibernate5-quickstart-ds.xml to simulate missing DS.
Enabled ON case
Using Add Deployment wizard, selecting Enabled ON in second step and receiving "Upload successful, hibernate5.war has been successfully uploaded to the content repository."
In reality there is error in server log about missing DS ...              "jboss.persistenceunit.\"hibernate5.war#primary\".__FIRST_PHASE__ is missing [jboss.naming.context.java.jboss.datasources.Hibernate5QuickstartDS]"
Webconsole should reflect that deployment was not enabled and was rolled back. Not available in content repository at all.
Enabled OFF case
When I keep Enabled OFF in second step the app is uploaded to the content repository. When I click on Enable I receive "Last operation failed" which is ok, DS is missing.
But I see still in-progress bar in the background of the deployment name. Failure is not cancelling progress animation in the background.

hibernate5 quickstart from DR17 build to be precise, but I guess you can use upstream one too.


API Token is not updated in pulumi state

What happened?
In our golang controller we have a cloudflare provider instanced like that
	providers[cloudflareProviderName], err = cloudflare.NewProvider(
		ctx,
		cloudflareProviderName,
		&cloudflare.ProviderArgs{
			ApiToken: pulumi.StringPtr(cloudflareAPIToken),
		},
	)

We use it to create/update dns record
Last week we rotate our Cloudflare API token and restarted our app with the new token
All of our stacks are in failed status with an authentication error
{...pulumi:pulumi:Stack package-stack **failed** 1 error\n\nDiagnostics:\n  cloudflare:index:Record (target-web-custom-domain):\n    error: refreshing urn:pulumi:stack::package::cloudflare:index/record:Record::target-web-custom-domain: 1 error occurred:\n    \t* Authentication error (10000)\n\n  pulumi:pulumi:Stack (package-stack):\n    error: update failed\n\nResources:\n    9 unchanged\n\nDuration: 3s`...}
So after many hours we found out what was wrong, the pulumi stack.json contains the token and unfortunately the old one
  "resources": [
      ...
      {
          "urn": "urn:pulumi:stack::package::pulumi:providers:cloudflare::cloudflare",
          "custom": true,
          "id": "f0bca2d3-65de-4c2a-8ce2-68c81b903230",
          "type": "pulumi:providers:cloudflare",
          "inputs": {
              "apiClientLogging": false,
              "apiToken": "XXXXXX",
              "maxBackoff": 30,
              "minBackoff": 1,
              "retries": 3,
              "rps": 4
          },
          "outputs": {
              "apiClientLogging": false,
              "apiToken": "XXXXXX",
              "maxBackoff": 30,
              "minBackoff": 1,
              "retries": 3,
              "rps": 4
          },

After pushing the new token into the object manually, it works
After looking at the successive changelogs & issues, I didn't see any mention about that. So, two questions:
Why is the API token, which is not a resource, is in the stack?
How can existing stacks use the new token?
Example
{...pulumi:pulumi:Stack package-stack **failed** 1 error\n\nDiagnostics:\n  cloudflare:index:Record (target-web-custom-domain):\n    error: refreshing urn:pulumi:stack::package::cloudflare:index/record:Record::target-web-custom-domain: 1 error occurred:\n    \t* Authentication error (10000)\n\n  pulumi:pulumi:Stack (package-stack):\n    error: update failed\n\nResources:\n    9 unchanged\n\nDuration: 3s`...}
Output of pulumi about
CLI
Version      3.70.1
Go Version   go1.20.2
Go Compiler  gc
Host
OS       ubuntu
Version  20.04
Arch     x86_64
Additional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

Hi @mdecalf I'm sorry about your troubles, let's try to figure it out together.

Why is the API token, which is not a resource, is in the stack?

API token is not a resource, but cloudflare.Provider is. Providers are kind of "virtual" resources in the sense that they don't create anything external, but are tracked in state files in order for the CLI to be able to display diffs, track dependencies and so on.

Last week we rotate our Cloudflare API token and restarted our app with the new token

Could you please elaborate on that? Did you change the value in your program, then run pulumi up to apply it? That should have updated the state and all depending resources.

How can existing stacks use the new token?

You need to run pulumi up with the new token and apply all the changes.

Hi @mjeffryes 👋 I'm running into this issue as well
Our existing Cloudflare API token expired, so I updated the values in my Pulumi.<stack-name>.yaml files. Running pulumi up did not resolve the issue - I continued to hit this error:
Diagnostics:
  cloudflare:index:Record (server-record-dev):
    error: deleting urn:pulumi:dev::server::cloudflare:index/record:Record::server-record-dev: 1 error occurred:
    	* error deleting Cloudflare Record: Authentication error (10000)

Not sure I ever would have figured out this bug without finding this issue. I assumed that the providers would always use the api token from the config.

You need to run pulumi up with the new token and apply all the changes.

If this is the case, it wasn't working for me. Does the new api token only get applied at the end of pulumi up? If so, I seemed to be in a frozen state where in order to update the token, I needed to get to the end of pulumi up, but in order to get to the end of pulumi up, I needed to update the token
The solution for me was to manually delete the Cloudflare provider from state - not ideal
Any help appreciated!

Hey folks, sorry you've hit issues here. Are you running refresh=true for pulumi up when you get the stale credentials?
This looks like https://github.com/pulumi/pulumi/issues/4981 - the issue is that the credentials are saved in the state and refresh, unfortunately, does not run the program, so can't get the new credentials - it will always use the stale ones.
The suggested workaround is not to save credentials in state - instead it is preferable to use environment variable to configure credentials for the provider.
If that is not an option the running pulumi up without --refresh=true should also update the credentials stored in the state.
If neither of these works could I ask for a short program which reproduces the issue, as well as the sequence of commands which triggers it?

Thanks for expanding on the workaround @liam-auror!


update debian informations

OOC, why the change from "rakudo" to "perl6" ?

FWIW debian has both perl6 and rakudo packages (I think perl6 is just a metapackage that depends on rakudo).

hello Liz,
On Tue, Nov 27, 2018 at 05:39:24AM -0800, Elizabeth Mattijsen wrote:

OOC, why the change from "rakudo" to "perl6" ?

i'm sorry i didn't explain it in the PR comment.
that's just a "user perspective" change for me: it is simpler for the
user to install perl6 that provide perl6 that explaining that "perl6 is
actually a spec with many implementations but the one you probably want
is rakudo because it is the one supported by the community".
aptitude install perl6 perl6-zef

and have fun :)
regards

Ah yeah, there's also no rakudo binary so IMO this change makes sense.

On Tue, Nov 27, 2018 at 05:41:38AM -0800, Aleks-Daniel Jakimenko-Aleksejev wrote:

FWIW debian has both perl6 and rakudo packages (I think perl6 is
just a metapackage that depends on rakudo).

actually, in stretch, perl6 is a package that depends on
rakudo, perl6-tap-harness, perl6-zef
so installing perl6 provide zef which is probably what's expected by a
newcommer.
marc

Thanks!
I tweaked it a bit here: https://github.com/perl6/perl6.org/commit/850c26433b0d650496a8a60693708181314e90af

@eiro oh! I didn't know that Debian started providing zef… maybe this should be mentioned somewhere. Please also see this ticket: https://github.com/perl6/user-experience/issues/29

hello,
On Tue, Nov 27, 2018 at 01:57:57PM +0000, Aleks-Daniel Jakimenko-Aleksejev wrote:

@eiro oh! I didn't know that Debian started providing zef… maybe this should be mentioned somewhere. Please also see this ticket: https://github.com/perl6/user-experience/issues/29

cool! but wait ... i said "stretch" which is the current stable but i
use buster (the future one) ... FIY
marc

yeah, we do have zef now, but it still has a few rough edges, most notably if you install a perl module that also has an executable (e.g. prove6), then that does not end up in a PATH you normally find executables in. the idea is that we would modify zef to symlink in /usr/bin or so, but that work has not yet happened.
there is also a first module package (perl6-readline) in the works. based on this we want to change some of the packaging infrastructure, and then go nito full-blown moduel packaging mode :)

hello,
On Tue, Nov 27, 2018 at 06:40:02AM -0800, Robert Lemmen wrote:

prove6), then that does not end up in a PATH you normally find
executables in. the idea is that we would modify zef to symlink in
/usr/bin or so, but that work has not yet happened.

what about non-root users? why not steal the perl5 -Mlocal::lib strategy?
PERL_MB_OPT="--install_base "/home/mc/tmp/demobase""; export PERL_MB_OPT;
PERL_MM_OPT="INSTALL_BASE=/home/mc/tmp/demobase"; export PERL_MM_OPT;
when i used zef from the sources, the final target used to be
~/.perl6/bin but now i use the debian package and
locate -r '/cro$'

outputs
/home/mc/.zef/store/cro-0.7.6.tar.gz/cro-0.7.6/bin/cro
/home/mc/.zef/store/cro.git/fb251c594c3ed04cd9a16c1b045f4380abb40549/bin/cro
/home/mc/.zef/tmp/cro.git/bin/cro
/home/mc/.zef/tmp/cro.git/bin/cro

but none of them have a shebang nor are executable
find $( locate -r '/cro$' ) -executable

remains empty.
regards
marc

@eiro sorry, I wasn very inprecise above. I did not mean installation through zef as a normal user, but apt-get install of a perl6-* package that contains executables.
The calling zef as a user case you describe should work as expected, what you are showing looks like a bug to me. it should work just like a zef you installed from source...
do you want to report a debian bug for it, or shall I?

hello,

The calling zef as a user case you describe should work as expected, what you are showing looks like a bug to me. it should work just like a zef you installed from source...
do you want to report a debian bug for it, or shall I?

i will... and maybe with a patch provided.
regards
marc


Deprecated URLs

Hey there,
First of all thanks for the library it works very well and it's really easy to use.
As you know they've deprecated the old endpoints, i see you've addressed this in commit: https://github.com/ln-nicolas/api_insee/commit/b98752aa7205d1e406a16a3b6a4c26f02eae9f1f .
I wanted to maybe suggest dropping the V3.11 since it would also work as such:  '/entreprises/sirene/siren' instead of '/entreprises/sirene/V3.11/siren' and it might be easier to maintain.
Secondly, are you planning to release these changes? The config.py is not exposed through the init so there's no easy way of changing the configuration of the library from the script we're importing it.
Thanks!

Great ideas, dropping the version in URL is more future proof et we would need a release for url update as well.

Is it possible to release 1.6 with this fix ?

A new version has been release
Sorry for the long delay


File/folder creation

Type: Feature Request
you show the file structure creation only once. it is not coming again after refined requests. you should let the files or folders created directly from the chat.
Extension version: 0.23.2
VS Code version: Code 1.96.2 (fabdb6a30b49f79a7aba0f2ad9df9b399473380f, 2024-12-19T10:22:47.216Z)
OS version: Linux x64 6.8.0-51-generic snap
Modes:

/needsMoreInfo
What are your concrete steps?


[HOLD for payment 2023-11-13] Expense - Workspace avatar and name change after creating a workspace expense

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: <IP_ADDRESS>
Reproducible in staging?: y
Reproducible in production?: n
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:

Navigate to staging.new.expensify.com
Create a new workspace.
Go to workspace chat.
Click + > Request money.
Create a manual request.

Expected Result:
The workspace avatar and name in the expense preview match the actual workspace avatar and name.
Actual Result:
The workspace avatar and name in the expense preview change. The name is changed to the requester name.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
https://github.com/Expensify/App/assets/93399543/6de5cea6-d905-43a7-97a1-f5e8e491ea73

View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

I'm guessing it might be related to https://github.com/Expensify/App/pull/30591 but I'm confirming (running into a crash prior to creating a money request on dev so haven't been able to test yet)

nope, not #30591. Although the optimistic data IS weird, it's not related to this bug. Looking more.

Looks like a regression of this PR

This change is the source of this issue

Nicely found, @s-alves10 . Looks like changing that to:
    const primaryDisplayName = isWorkspaceActor ? displayName : ReportUtils.getDisplayNameForParticipant(actorAccountID);

works well, though I need to see if there are any unexpected consequences there

@dangrous are you creating a PR for this, or should I prepare that quick fix PR?

Yep, I grabbed it here - https://github.com/Expensify/App/pull/30342

@joekaufmanexpensify - adding bug zero to assist with payment for reviewer of linked PR!

Sure, happy to help!

Only payment due here is $500 to @0xmiroslav for review of the internal PR. Paid via NewDot.

@0xmiroslav could you please request $500 and confirm here once complete?


Automation API seemingly removes AWS policy attachments that do not belong to stack.

Expected behavior
In our project set up we have a main Pulumi project, as well as a "nested" Pulumi project and "child" stack that we use with the Automation API and Jest for spinning up temporary resources needed for running integration tests on the "parent" stack.
We expect that pulumi up for our main project will create those stack resources belonging to our main project, and that running our Automation API scripts will deploy and teardown the child stack and only its resources.
Current behavior
What we see happen is that after the Automation API scripts run, role policy attachments associated with lambdas in the parent stack are removed. Pulumi still considers those policy attachments as existing stack resources until running pulumi refresh on the parent stack.
Steps to reproduce
I have created a simple example repo for recreating this behavior. https://github.com/andrewlaskey/pulumi-example
There is a main project that can be deployed with pulumi up that creates a lambda with two policies attached. Then there is a script that can be run, which uses the Automation API to create another stack with a lambda, policies, and a stack reference to the "parent" stack.

Set AWS profile
Deploy main project stack: pulumi stack select parent-stack and pulumi up
Confirm deployment by looking in Pulumi dashboard and role in AWS console.
Run the automation API: npm run automation
Run the teardown script: npm run automation:destroy
Refreshing the page in the AWS console for the role will show that the policies are gone.
pulumi up in the main project will not recreate those policies and only after pulumi refresh and pulumi up will the main stack be corrected again.

Example
     Type                         Name                                                            Status
 +   pulumi:pulumi:Stack          disappearing-policies-parent-stack                              created
 +   ├─ aws:iam:Role              pulumiPolicyTest-role                                           created
 +   ├─ aws:iam:PolicyAttachment  pulumiPolicyTest-lambda-AWSLambdaBasicExecutionRole-policy      created
 +   ├─ aws:iam:PolicyAttachment  pulumiPolicyTest-lambda-AWSLambdaVPCAccessExecutionRole-policy  created
 +   └─ aws:lambda:Function       pulumiPolicyTest                                                created

Outputs:
    testLambdaName: "pulumiPolicyTest-aabdd56"
    testLambdaRole: "pulumiPolicyTest-role-71b7bf4"

Resources:
    + 5 created

Duration: 21s

> automation:destroy
> ts-node scripts.ts --destroy

******** CHILD INFRA TEARDOWN ********
Destroying stack: child-stack
Destroying (child-stack)

View Live: https://app.pulumi.com/andrewlaskey/disappearing-policies-child-infra/child-stack/updates/3

 -  aws:iam:PolicyAttachment pulumiPolicyTestChild-lambda-AWSLambdaBasicExecutionRole-policy deleting
 -  aws:iam:PolicyAttachment pulumiPolicyTestChild-lambda-AWSLambdaVPCAccessExecutionRole-policy deleting

 -  aws:lambda:Function pulumiPolicyTestChild deleting

 -  aws:lambda:Function pulumiPolicyTestChild deleted

 -  aws:iam:PolicyAttachment pulumiPolicyTestChild-lambda-AWSLambdaBasicExecutionRole-policy deleted

 -  aws:iam:PolicyAttachment pulumiPolicyTestChild-lambda-AWSLambdaVPCAccessExecutionRole-policy deleted

 -  aws:iam:Role pulumiPolicyTestChild-role deleting

 -  aws:iam:Role pulumiPolicyTestChild-role deleted

 -  pulumi:pulumi:Stack disappearing-policies-child-infra-child-stack deleting

 -  pulumi:pulumi:Stack disappearing-policies-child-infra-child-stack deleted

Outputs:
  - integrationLambdaName: "pulumiPolicyTestChild-f5e373d"

Resources:
    - 5 deleted

Duration: 8s

Context (Environment)
This is affecting the development of our project and our ability to create temporary resources for the purpose of integration testing our main project. We could reconfigure the type of tests we are running so that we don't need ephemeral infrastructure, however, that would limit the kind of tests we can run. We would also like to better understand the ways in which nested Pulumi projects can possibly interact with each other so we can avoid this pitfall if we need to follow this pattern for some other reason.
Thanks!

Actually, I'm not sure why I didn't notice this at the outset, but the problem here is PolicyAttachment -- this is applied to a policy which is the same policy in the case of the child and parent programs. You're modifying what roles a particular policy is attached to. Instead, what you actually want to use is RolePolicyAttachment which applies a policy to a role.

Wow, yep that was the problem. 🤦
Thanks for finding that!