text:
feat: pass state=owllyId to authurl

Change Method from Get to Post? (GetEidAuthUrl)
so we can "hide" the state inside the body of the request.
https://github.com/project-owlly/cloud/blob/master/functions/src/request/oidc/getOIDC.ts
Prototyp: https://www.figma.com/proto/JytQQfL4c12pJanZHzisp0/Prototyp_2_wecollect_wizard?node-id=328%3A0&scaling=scale-down
Additionally, we need to change:

E-Collect Button https://github.com/project-owlly/e-collecting/issues/49
Signature Button https://github.com/project-owlly/signature/issues/25

@sansan88 did you cleared how we can call eID and get back an information?

Yes thats working! /return page has all of it

We neeed a post! I can change this.. need it for login anyway

To be honest with you, I don't think "callable" function is a valid reason as it is not a standard.
HttpClient or fetch are and supports post  or get.

We have use onRequestfor our functions
If I understand the docs, callable work with onCall

The functions.https.onCall trigger automatically deserializes the request body and validates auth tokens.

https://firebase.google.com/docs/functions/callable

repo: project-owlly/cloud


text:
Varlink creates a new runtime for each API operation

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
Description
podman varlink can occasionally linger for a time accepting multiple requests, due to the default timeout. While it lingers, it services any new inbound API requests. Each new API request for every endpoint that is not podman version will initialize a new libpod Runtime. However, each Runtime will initialize a new ocicni CNI plugin manager, which will initiate inotify on a directory to search for new plugins. There is a max of 128 inotify sessions per user by default in Fedora, so if we receive 128 API requests before podman varlink times out and dies, we will begin throwing errors.
@jwhonce first noticed this in the Python tests.
Best solution is probably to initialize a single Runtime when podman varlink starts up and save it in the varlink API struct so that multiple API requests can share a runtime.
Steps to reproduce the issue:

Repeatedly barrage the varlink interface with requests without pause

Describe the results you received:
{'parameters': {'reason': 'error configuring CNI network plugin: could not create new watcher too many open files'}, 'error': 'io.projectatomic.podman.RuntimeError'}
Describe the results you expected:
No open files error
Additional information you deem important (e.g. issue happens only occasionally):

@baude PTAL

I'll look at it.

can someone provide a way for me to test this more easily so I can verify the new implementation actually works?

source: gharchive/issue

authors: baude mheon rhatdan

repo: projectatomic/libpod

license_type: permissive

license_source: github-api


text:
podman ps -a reports 'no exit file for container found' after manually killing conmon process

Manually killing conmon process of a container results in below error for podman ps -a
unable to create output: no exit file for container a9aa67f40bc6c... found: timed out waiting for the condition

Scenario and how to reproduce:
TEST 01: First kill the process inside container - no issue observed

Run a container:

# podman run -d alpine sleep 1000 &
# ab60719c7d0af70a355d14bc558faa1032d89987ea94afa0055b6d8af597e57b

# podman ps
CONTAINER ID   IMAGE    COMMAND      CREATED AT                      STATUS              PORTS   NAMES
ab60719c7d0a   alpine   sleep 1000   2018-03-02 11:16:00 -0500 EST   Up 16 seconds ago           cocky_hawking

First kill sleep process inside container. This will also result in conmon process exiting, all ok:

F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
1     0   942     1  20   0  86080  1848 SyS_po Ssl  ?          0:00 /usr/libexec/crio/conmon -c ab60719c7d0af70a355d14bc558faa1032d89987ea94afa0055b6d8af597e57b -u ab60719c7d0af70a355d14bc558faa1032d89987ea94afa0055b6d8af597e57b -r /usr/bin/runc -b /var/lib/containers/storage/overlay-containers/ab60719c7d0af70a355d14bc558faa1032d89987ea94afa0055b6d8af597e57b/userdata -p /var/run/containers/storage/overlay-containers/ab60719c7d0af70a355d14bc558faa1032d89987ea94afa0055b6d8af597e57b/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/ab60719c7d0af70a355d14bc558faa1032d89987ea94afa0055b6d8af597e57b/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket
4     0   963   942  20   0   1512     4 hrtime Ss   ?          0:00 sleep 1000

# kill -9 963

No issue observed and podman ps -a works correctly:

# podman ps -a
CONTAINER ID   IMAGE    COMMAND      CREATED AT                      STATUS                          PORTS   NAMES
ab60719c7d0a   alpine   sleep 1000   2018-03-02 11:16:00 -0500 EST   Exited (0) About a minute ago           cocky_hawking

TEST 02: First kill conmon process & then process inside container - issue observed

Run a container:

# podman run -d alpine sleep 1000 &
# a9aa67f40bc6cf158850110b8c7f6cf74a00c654bc6d4c9fca16ddcef8a02dc3

First kill conmon process of container.

F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
1     0  1103     1  20   0  86080  1916 SyS_po Ssl  ?          0:00 /usr/libexec/crio/conmon -c a9aa67f40bc6cf158850110b8c7f6cf74a00c654bc6d4c9fca16ddcef8a02dc3 -u a9aa67f40bc6cf158850110b8c7f6cf74a00c654bc6d4c9fca16ddcef8a02dc3 -r /usr/bin/runc -b /var/lib/containers/storage/overlay-containers/a9aa67f40bc6cf158850110b8c7f6cf74a00c654bc6d4c9fca16ddcef8a02dc3/userdata -p /var/run/containers/storage/overlay-containers/a9aa67f40bc6cf158850110b8c7f6cf74a00c654bc6d4c9fca16ddcef8a02dc3/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/a9aa67f40bc6cf158850110b8c7f6cf74a00c654bc6d4c9fca16ddcef8a02dc3/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket
4     0  1113  1103  20   0   1512     4 hrtime Ss   ?          0:00 sleep 1000

# kill -9 1103

After killing conmon process first, PID 1 will become PPID of sleep process which is running inside container. I guess this is expected:

F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  1113     1  20   0   1512     4 hrtime Ss   ?          0:00 sleep 1000

Now systemd with PID 1 have become parent of sleep which was running inside container. Running podman ps -a still shows container up but there is no conmon process:

# podman ps -a
CONTAINER ID   IMAGE    COMMAND      CREATED AT                      STATUS                     PORTS   NAMES
a9aa67f40bc6   alpine   sleep 1000   2018-03-02 11:18:55 -0500 EST   Up 56 seconds ago                  youthful_wilson
ab60719c7d0a   alpine   sleep 1000   2018-03-02 11:16:00 -0500 EST   Exited (0) 3 minutes ago           cocky_hawking

Now kill sleep process and podman ps -a shows below error. It states no exit file for container found

# kill -9 1103

# podman ps -a
unable to create output: no exit file for container a9aa67f40bc6cf158850110b8c7f6cf74a00c654bc6d4c9fca16ddcef8a02dc3 found: timed out waiting for the condition

After this state if I run any more containers, I can check running containers with podman ps but running podman ps -a results in above error becuase of how first container was killed.
Trying to remove the first container with container ID also does not work.

# podman rm a9aa67f40bc6cf158850110b8c7f6cf74a00c654bc6d4c9fca16ddcef8a02dc3
failed to delete container a9aa67f40bc6cf158850110b8c7f6cf74a00c654bc6d4c9fca16ddcef8a02dc3: no exit file for container a9aa67f40bc6cf158850110b8c7f6cf74a00c654bc6d4c9fca16ddcef8a02dc3 found: timed out waiting for the condition

Forgot to specify version while opening issue.
# podman version
Version:       0.2.3-dev
Go Version:    go1.9.4
Git Commit:    "656840c9924b0348c7e939b4215f14c5b076842f"
Built:         Fri Mar  2 09:47:14 2018
OS/Arch:       linux/amd64

This sounds like a conmon issue.
Conmon, if it is killed by a signal we can catch (ex. SIGTERM), should first kill the container it's managing, create the exit file, and then exit. This guarantees that the container is actually dead, and we are in a sane state.
To ensure containers in a bad state can actually be removed, we have added code in master to better handle missing exit files. The container process running would still interfere with removal, but that should be fixable by manually killing the runc in question

There's a PR open against conmon upstream with a partial fix - https://github.com/kubernetes-incubator/cri-o/pull/1409
This, combined with the existing fix we added here, should be enough to handle most cases where conmon is manually killed. We can't do anything about SIGKILL, though, as SIGKILL cannot be caught.

Partial fix in conmon merged, though we won't take advantage of it until we move to using conmon for cleanup.

@mheon Any progress on this?  Or does this still need @giuseppe to implement this in conmon?

@rhatdan I think this is fixed in conmon

@mheon so we have not done the second part yet for podman to tell conmon to cleanup?

@rhatdan Yes. I'm not sure if we are really in a better place for this bug once that lands, though.
If conmon is manually killed in such a way that it can't create the exit file and can't clean up, we end up in a bad place, especially in the CRI-O case where we only determine exit files based on inotify for the exit file. I don't think there's a way around that.

I am fine with keeping this open, but I would like to get moving on implementing this hook.

@giuseppe could you look into this?

@rhatdan I wonder if it makes sense to break conmon out into a dedicated project. I know there are pros and cons, but it would make packaging much easier and maybe even testing as we could make tests depend on CRI-O and Podman.

Yes we have talked about moving conmon out into its own package.

We now have podman container cleanup.

authors: mheon rhatdan sunilcio vrothberg


text:
Calico selecting wrong device for deletion during cleanup

Hola crew,
While debugging a pod that apparently stopped receiving traffic for an unknown reason today and had to be flushed, I discovered that the pod was using a network device that apparently had been incorrectly cleaned up by calico as part of another pod deletion.
Note: My networking knowledge is ... okay. Much of the specifics are over my head.
Expected Behavior

A new pod is scheduled
That new pod starts the pause container and establishes the network namespace (or so)
Calico is called via cni to create the necessary adapters and so
Those adapters are created successful, and kubernetes attempts to start the pod.
That pod creation fails; in this case due to bad mount configuration
Kubernetes schedules that pod for cleanup
Kubernetes calls Calico via the CNI to clean the pod up
Calico removes the adapter & releases the IP
Everything is fine.

Current Behavior
Assuming the same steps above, the problem is as so:

That pod creation fails
Something (I would assume docker) cleans up the veth pair for that container
Kubernetes calls Calico via the CNI to clean the container up
Calico determines somehow the adapter to delete incorrectly. In the logs below, you'll see the adapter that is deleted is not the one recorded against that pod object.
Calico releases that IP.
Calico thinks everything is fine. It is not.

Later, when that pod is eventually deleted Calico attempts to clean up that device, discovers it is not there and carries on ignoring that.
Possible Solution
It would depend on the nature of the problem; I am guessing that the device id is not checked when the DEL command is issued; rather a proxy where the relevant device can be looked up — namespace path, for example. This might be where it goes awry, as the namespace path (if i understand correctly) is /proc/$PID/ns/net, and that $PID might get reallocated.
(These compute nodes are hella busy).
Steps to Reproduce (for bugs)
Absolutely no idea. It happens rarely on production. The reconstruction above is from logs.
Context
We have to put liveness probes on things to reboot them and, apparently, re-trigger the creation of these devices (or so). TBD — Still working on a hotfix.
Your Environment

Calico version

calico/node:v3.8.1

Orchestrator version (e.g. kubernetes, mesos, rkt):

kubernetes v1.15.x

Operating System and version:

Ubuntu 18.04

Link to your project (optional):

(It's closed source)
(Heavily Redacted) Logs

Aug 30 22:08:27 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:08:27.922 [INFO][11914] k8s.go 361: Populated endpoint ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0" Namespace="__NAMESPACE__" Pod="__POD_NAME__" WorkloadEndpoint="__WORKLOAD_ENDPOINT__" endpoint=&v3.WorkloadEndpoint{TypeMeta:v1.TypeMeta{Kind:"WorkloadEndpoint", APIVersion:"projectcalico.org/v3"}, ObjectMeta:v1.ObjectMeta{Name:"__WORKLOAD_ENDPOINT__", GenerateName:"__PARTIAL_POD_NAME__", Namespace:"__NAMESPACE__", SelfLink:"", UID:"8b9ffc8a-19f0-4f23-9fee-edf4cb8bc8e5", ResourceVersion:"475949471", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:63734422103, loc:(*time.Location)(0x2346b20)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string{"projectcalico.org/orchestrator":"k8s", "projectcalico.org/serviceaccount":"__SERVICE_ACOUNT__", "app":"__APP_NAME__", "pod-template-hash":"6867d79cdb", "projectcalico.org/namespace":"__NAMESPACE__"}, Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, Spec:v3.WorkloadEndpointSpec{Orchestrator:"k8s", Workload:"", Node:"__NODE_NAME__", ContainerID:"", Pod:"__POD_NAME__", Endpoint:"eth0", IPNetworks:[]string{"10.217.51.215/32"}, IPNATs:[]v3.IPNAT(nil), IPv4Gateway:"", IPv6Gateway:"", Profiles:[]string{"kns.__NAMESPACE__", "ksa.__NAMESPACE__.__SERVICE_ACOUNT__"}, InterfaceName:"cali23af261a86a", MAC:"", Ports:[]v3.EndpointPort(nil)}}
Aug 30 22:08:27 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:08:27.922 [INFO][11914] k8s.go 362: Calico CNI using IPs: [10.217.51.215/32] ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0" Namespace="__NAMESPACE__" Pod="__POD_NAME__" WorkloadEndpoint="__WORKLOAD_ENDPOINT__"
Aug 30 22:08:27 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:08:27.922 [INFO][11914] network_linux.go 76: Setting the host side veth name to cali23af261a86a ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0" Namespace="__NAMESPACE__" Pod="__POD_NAME__" WorkloadEndpoint="__WORKLOAD_ENDPOINT__"
Aug 30 22:08:27 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:08:27.939 [INFO][11914] network_linux.go 396: Disabling IPv4 forwarding ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0" Namespace="__NAMESPACE__" Pod="__POD_NAME__" WorkloadEndpoint="__WORKLOAD_ENDPOINT__"
Aug 30 22:08:28 __NODE_NAME__ systemd-networkd[27141]: cali23af261a86a: Gained carrier
Aug 30 22:08:28 __NODE_NAME__ networkd-dispatcher[27494]: WARNING:Unknown index 1913 seen, reloading interface list
Aug 30 22:08:28 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:08:28.060 [INFO][11914] k8s.go 388: Added Mac, interface name, and active container ID to endpoint ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0" Namespace="__NAMESPACE__" Pod="__POD_NAME__" WorkloadEndpoint="__WORKLOAD_ENDPOINT__" endpoint=&v3.WorkloadEndpoint{TypeMeta:v1.TypeMeta{Kind:"WorkloadEndpoint", APIVersion:"projectcalico.org/v3"}, ObjectMeta:v1.ObjectMeta{Name:"__WORKLOAD_ENDPOINT__", GenerateName:"__PARTIAL_POD_NAME__", Namespace:"__NAMESPACE__", SelfLink:"", UID:"8b9ffc8a-19f0-4f23-9fee-edf4cb8bc8e5", ResourceVersion:"475949471", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:63734422103, loc:(*time.Location)(0x2346b20)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string{"projectcalico.org/namespace":"__NAMESPACE__", "projectcalico.org/orchestrator":"k8s", "projectcalico.org/serviceaccount":"__SERVICE_ACOUNT__", "app":"__APP_NAME__", "pod-template-hash":"6867d79cdb"}, Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, Spec:v3.WorkloadEndpointSpec{Orchestrator:"k8s", Workload:"", Node:"__NODE_NAME__", ContainerID:"2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0", Pod:"__POD_NAME__", Endpoint:"eth0", IPNetworks:[]string{"10.217.51.215/32"}, IPNATs:[]v3.IPNAT(nil), IPv4Gateway:"", IPv6Gateway:"", Profiles:[]string{"kns.__NAMESPACE__", "ksa.__NAMESPACE__.__SERVICE_ACOUNT__"}, InterfaceName:"cali23af261a86a", MAC:"ae:09:0e:99:3e:54", Ports:[]v3.EndpointPort(nil)}}
...
Aug 30 22:10:01 __NODE_NAME__ systemd-networkd[27141]: cali23af261a86a: Lost carrier
...
Aug 30 22:10:03 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:10:03.659 [INFO][31825] plugin.go 442: Extracted identifiers ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0" Node="__NODE_NAME__" Orchestrator="k8s" WorkloadEndpoint="__WORKLOAD_ENDPOINT__"
Aug 30 22:10:03 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:10:03.677 [WARNING][31825] workloadendpoint.go 75: Operation Delete is not supported on WorkloadEndpoint type
Aug 30 22:10:03 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:10:03.677 [INFO][31825] k8s.go 470: Endpoint deletion will be handled by Kubernetes deletion of the Pod. ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0" endpoint=&v3.WorkloadEndpoint{TypeMeta:v1.TypeMeta{Kind:"WorkloadEndpoint", APIVersion:"projectcalico.org/v3"}, ObjectMeta:v1.ObjectMeta{Name:"__WORKLOAD_ENDPOINT__", GenerateName:"__PARTIAL_POD_NAME__", Namespace:"__NAMESPACE__", SelfLink:"", UID:"8b9ffc8a-19f0-4f23-9fee-edf4cb8bc8e5", ResourceVersion:"475951609", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:63734422103, loc:(*time.Location)(0x2346b20)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string{"app":"__APP_NAME__", "pod-template-hash":"6867d79cdb", "projectcalico.org/namespace":"__NAMESPACE__", "projectcalico.org/orchestrator":"k8s", "projectcalico.org/serviceaccount":"__SERVICE_ACOUNT__"}, Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, Spec:v3.WorkloadEndpointSpec{Orchestrator:"k8s", Workload:"", Node:"__NODE_NAME__", ContainerID:"", Pod:"__POD_NAME__", Endpoint:"eth0", IPNetworks:[]string{"10.217.51.215/32"}, IPNATs:[]v3.IPNAT(nil), IPv4Gateway:"", IPv6Gateway:"", Profiles:[]string{"kns.__NAMESPACE__", "ksa.__NAMESPACE__.__SERVICE_ACOUNT__"}, InterfaceName:"cali23af261a86a", MAC:"", Ports:[]v3.EndpointPort(nil)}}
Aug 30 22:10:03 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:10:03.677 [INFO][31825] k8s.go 477: Cleaning up netns ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0"
Aug 30 22:10:03 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:10:03.682 [INFO][31825] network_linux.go 450: Calico CNI deleting device in netns /proc/1316/ns/net ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0"
Aug 30 22:10:03 __NODE_NAME__ systemd-networkd[27141]: calicd9e81b465b: Lost carrier
Aug 30 22:10:03 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:10:03.804 [INFO][31825] network_linux.go 467: Calico CNI deleted device in netns /proc/1316/ns/net ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0"
Aug 30 22:10:03 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:10:03.804 [INFO][31825] k8s.go 484: Releasing IP address(es) ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0"
Aug 30 22:10:03 __NODE_NAME__ kubelet[27693]: 2020-08-30 22:10:03.804 [INFO][31825] utils.go 168: Calico CNI releasing IP address ContainerID="2a0894d5fbf6d033c94cab8bb328e45762ce63bd69678fd16953e58ac6482cc0"

(calicd9e81b465b is the one that shouldn't have been deleted, cali23af261a86a is the one that was / should have been)

Yeah, the Calico CNI plugin will use the netns+ifce name in order to find the correct interface to clean up on teardown (https://github.com/projectcalico/cni-plugin/blob/master/pkg/dataplane/linux/dataplane_linux.go#L462).
But, it's trusting that the container runtime is passing it the correct netns and interface name. I don't think we can take the arguments given to us by the runtime and say "actually, I think you meant to delete this interface!"
Basically, I don't see how this would be a result of the pid being re-used, unless it was a bug in the container runtime itself, since the container runtime shouldn't send us DEL requests for the wrong netns. Does that make sense?
What container runtime are you guys using?

@andrewhowdencom Would you provide more info on this?

Broadly, it happens fairly rarely so we created a liveness probe that probed TCP and forced a reboot (and correspondingly reconstruction of the adapter) and the problem is papered over.

(to answer the earlier question, docker)

(to answer the earlier question, docker)

Hm, we test pretty extensively with Docker, but I suppose that an issue like this might just appear as a flake and get missed. I'm still feeling confident that this is a runtime / configuration issue rather than a Calico issue. The CNI plugin needds to assume the netns it is provided is correct. If it's given an incorrect netns... well, there's not much it can do!

repo: projectcalico/calico


text:
calico/typha is reconnecting without any back-off mechanism

We observed that when the kubernetes api server is not available,
calico/typha is trying to reconnect to the kubernetes server
without any back-off mechanism and it can easily reach 1k connection attempts/s.
Would it be possible to throttle the retries to about 100/s or 10/s?
We are concerned about a possible overload issue on our reverse proxy
in the network path, which is shared by several kubernetes api servers.
Expected Behavior
The reconnect attempts are throttled.

Current Behavior

Calico/typha maintains a high reconnect rate indefinitely.
Possible Solution

Throttle the reconnect attempts.
Steps to Reproduce (for bugs)

Monitor the connection establishment attempts by the calico/typha pod
Stop the kubernetes api server

Context

We are introducing a feature where the network path to the hosted api servers
share a load balancer and a few reverse proxies,
and we are concerned that this thundering herd behavior might lead to a DDoS attack.
Related issue: https://github.com/projectcalico/felix/issues/324#issuecomment-111108710
Your Environment

And/Or, calico/typha container version (if running Typha in a container): v3.13.5
Which orchestrator are you using (e.g. Kubernetes, OpenStack, Docker, Mesos): Kubernetes
Orchestrator version (if used): 1.20.2

This should be fixed in the upcoming Calico v3.23.0 release.  I added a throttle that prevents us from looping more often than 500ms.  Avoids a 100ms delay in the happy case but should do the trick if we're hitting the bad case described in this issue.

authors: fasaxc istvanballok


text:
drop contour.spec.namespace, create resources in the same namespace as the Contour CR

Follow-up to https://github.com/projectcontour/contour-operator/pull/382
We have clarified our policy around alpha APIs to allow fields to be dropped without revving the API version (this diverges slightly from upstream). As such, we are free to go ahead and drop the namespace field from the Contour spec and always create resources in the same namespace as the Contour CR itself, to simplify namespace management.

do we still want to transition to using the contour ContourDeployment CRD? if so could be a related change needed to stop using the Contour CRD from the operator, move the required fields over, etc.

authors: skriss sunjayBhatia

repo: projectcontour/contour-operator


text:
Add fly postgres detach before fly apps destroy

This fly-pr-reviews-apps pull request is depended on this workflow.

I need this pull request to be merged to the main before this pull request can be resolved.

source: gharchive/pull-request

repo: projectstake/fly-pr-review-apps


text:
Remove scrollTo from MonthPager and add onTouchEvent()

#181

Thanks, but this change is already part of a future-1.x release. Closing.

license: MIT


text:
feat: Add mysqld_exporter role

Add a role for deploying the mysqld_exporter.

Yup, I just copied the node_exporter and am still working on this.

Ok, I updated based on #65

repo: prometheus-community/ansible


text:
Add more info about filters to docs and rename struct fields

Adjusts the way monitoring.filters are documented and applied.
Similar to #165, I found it hard to use the filters initially so hopefully more detailed docs can help. Especially related to the fact that the monitoring.filters flag should be specified multiple times vs comma delimited like other multi-valued params.
This also adjusts the way the filters are applied to be based on prefix vs contains, https://github.com/prometheus-community/stackdriver_exporter/pull/198/commits/507f6b3119310e14e3a62e66b30100f899e00de0. I think the original contains implementation made it hard to define what exactly belongs in the first section of the extra_filters. Forcing it to be a prefix makes it a lot more concrete.

This looks good, is there someone who can review it?

I think only @SuperQ can approve PR's ATM

Hey @SuperQ  - I'm bumping into this again, It would really save me a tonne of bother if we could get this approved. 🙏

Should be good to go now @SuperQ


text:
Feature request: Add group creation time to group_by hash

What did you do?

Alert fired, started flapping
Ops person manually silenced the alert
Ops person also acknowledged the alert in Opsgenie

What did you expect to see?

A new batch of alerts should not be grouped into an already resolved group

What did you see instead? Under which circumstances?

Alert resolved, alertmanager did not send a notification to Opsgenie due to #226
A week later, new hosts started alerting, but were grouped into the same already-acknowledged incident in Opsgenie
Full datacenter outage occurs due to missed alerts

Environment

Alertmanager version:

alertmanager, version 0.24.0 (branch: HEAD, revision: f484b17fa3c583ed1b2c8bbcec20ba1db2aa5f11)
  build user:       root@265f14f5c6fc
  build date:       20220325-09:31:33
  go version:       go1.17.8
  platform:         linux/amd64

Hi! :wave:
I think the main issue here is that Alertmanager cannot close incidents if all alerts in a group are silenced.
When silencing alerts for an active incident, you need to take care and make sure the incident is closed in your IRM (Opsgenie). If you leave the incident open, and new alerts are sent from Alertmanager to the same incident, you may or may not get paged for them.
I also recommend checking your Opsgenie configuration, as it sounds like the incident might have been left open by mistake? This shouldn't happen as you should be paged at regular intervals for active incidents until they are resolved.
To answer some of your questions:

Add group creation time to group_by hash

This won't work I'm afraid. Consider the case where the system clock on two Alertmanager servers are out of sync by 1ns. You will have different group creation times on each Alertmanager server, creating duplicate incidents in your IRM.

A new batch of alerts should not be grouped into an already resolved group

Given it had been a week since the last alert was resolved, and I assume there were no other active alerts in the group during that time, Alertmanager would have created a new group for these new alerts. However, group keys are deterministic, and if a group is "re-opened" it will re-use the same group key. This is intentional.

authors: ccope grobinson-grafana

repo: prometheus/alertmanager


text:
HistogramTimer API

Hi! My team at work is converting some of our projects over from docs.rs/prometheus to this crate. One nice-to-have feature we miss from the old crate is the HistogramTimer type. I suggest adding it into this crate for two reasons:

It's convenient for working with histograms and less error-prone than tracking time manually (using HistogramTimer means you don't have to check every possible early return/drop point yourself)
It would simplify the process of porting code from docs.rs/prometheus over to this crate.

Happy to implement this myself.

I am in favor of this. Given that Histogram is Clone, Send and Sync, I don't think this change will be intrusive.

Happy to implement this myself.

Great. Thank you. Let me know in case you need any help.

Referencing https://github.com/nox/prometools/blob/main/src/histogram.rs by @nox here.
Again, I am in favor of supporting this natively.

authors: adamchalmers mxinden


text:
Metric names are incorrectly generated

The problem is demonstrated by the following comment —
//! let expected = "# HELP my_counter This is my counter.\n".to_owned() +
//!                "# TYPE my_counter counter\n" +
//!                "my_counter_total 1\n" +
//!                "# EOF\n";

The HELP and TYPE lines should use my_counter_total, not my_counter.

It is somewhat surprising that the metric name provided to counter constructors will have _total appended to it automatically. It would be cool if that were better documented, and ideally only happened if the provided metric name didn't already end in _total.

The HELP and TYPE lines should use my_counter_total, not my_counter.

Not according to the OpenMetrics specification:
https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#counter-1

It is somewhat surprising that the metric name provided to counter constructors will have _total appended to it automatically. It would be cool if that were better documented, and ideally only happened if the provided metric name didn't already end in _total.

Good idea. For the former, would you mind extending the documentation @08d2? For the latter, let's move the discussion to https://github.com/prometheus/client_rust/issues/52.

Not according to the OpenMetrics specification

I don't know anything about OpenMetrics, really, and I don't consider it any kind of authority. I can observe that the "_created" thing described in your link is not valid for Prometheus, though.

AFAIK, this is not compatible with the Prometheus exposition format.

Note that you need to set the right content type in order for Prometheus parse the output of a scrape in the Open Metrics format.
https://github.com/prometheus/client_rust/blob/69e6674064c08630b7b397a58d6e99279d8d98ce/examples/tide.rs#L37

We have ~100 unsuffixed metrics at work and we are trying to move away from prometheus and to switch to prometheus-client, this automatic suffixing is an issue, we don't want to change dozens of dashboards because a library forces counter renames on us. Would you accept a PR adding an LegacyUnsuffixedCounter<A> type to this crate?

Note that I would see this as a small helper to enable folks to migrate to the OpenMetrics format eventually.

OpenMetrics remains an experiment, not a standard. Prometheus client libraries should default to the core exposition formats, and leave OpenMetrics as an opt-in alternative.

authors: 08d2 mxinden nox


text:
Compaction fails when total symbol size exceeds 2^32 bytes

What did you do?
compact blocks from 7 2day files  to larger one by thanos.   duration=300
What did you expect to see?
7*2day blocks can be compacted successfully.
What did you see instead? Under which circumstances?
normal compact process halt, and throw this error " 2 errors: populate block: add series: read symbols: invalid checksum; read symbols: invalid checksum"
Environment
4C16G , block files index is 1.5G,4.2g,4.13g,3.74g,5.24g,5.25g,5.06g

System information:
insert output of uname -srm here

Prometheus version:
1.8.2
insert output of prometheus --version here

Logs:

caller=compact.go:416 msg="critical error detected; halting" err="compaction: group 300@14327834599727325097: compact blocks [xx,xx,xx,xx,xx,xx,xx]: 2 errors: populate block: add series: read symbols: invalid checksum; read symbols: invalid checksum"

code info:
thanos compact/compact.go
     comp.Compact(dir,plan,nil)

tsdb/compact.go
  L380  Compact
  L424 c.write(dest,meta,blocks)
         c.populateBlock
              indexw.AddSeries(ref,sl,chks...) ??

good

What OS are you using? I know we've had problems with OpenBSD.
https://github.com/prometheus/prometheus/issues/8877

Centos
------------------ Original ------------------
From: Levi Harrison @.>
Date: Wed,Jul 14,2021 10:11 AM
To: prometheus/prometheus @.>
Cc: Jupiter @.>, Author @.>
Subject: Re: [prometheus/prometheus] when compact blocks, err "errors: populate block: add series: read symbols: invalid checksum; read symbols: invalid checksum" (#9078)
What OS are you using? I know we've had problems with OpenBSD.
#8877
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

now,i change to a 16C-64G envirnment, when above invalid error occurs, the %MEM only reach 40%. So we can see this issue may has no relation with MEM size.
if i compact the front 6 blocks, it works well
if i compact the back 6 blocks, it works well too.
When this error info occurs in compact 7 blocks, the process only pass 40s;  but when front or back 6 block compacted successfully, it passed half an hour.
So ,Any one has a idea,
1、how and when the tsdb read symbols and why it think invalid？
2、every block's index and chunks are read into memery or write to disk at the same time?

error code area:
github.com/prometheus/prometheus/tsdb/encoding/encoding.go
func NewDecbufAt(bs ByteSlice, off int, castagnoliTable *crc32.Table) Decbuf {
...
if castagnoliTable != nil {
if exp := binary.BigEndian.Uint32(b[len(b)-4:]); dec.Crc32(castagnoliTable) != exp {
fmt.Println("exp,dec.Crc32",exp,dec.Crc32(castagnoliTable))
debug.PrintStack()
return Decbuf{E: ErrInvalidChecksum}
}
}
...}
stack info:
    /usr/local/go/src/runtime/debug/stack.go:16 +0x25

hash/crc32.archUpdateCastagnoli(0x35933015, 0x7fa5fb604190, 0x2e6, 0x1000002ea, 0xc0ca6ccfea)
/usr/local/go/src/hash/crc32/crc32_amd64.go:193 +0x3de
hash/crc32.Update(0xc000000000, 0xc000170400, 0x7fa5f5cf4009, 0x591046d, 0x105910471, 0x1ca6ccfea)
/usr/local/go/src/hash/crc32/crc32.go:215 +0x11a
hash/crc32.Checksum(...)
/usr/local/go/src/hash/crc32/crc32.go:249
github.com/prometheus/prometheus/tsdb/encoding.(*Decbuf).Crc32(...)
/opt/ts/tshouse-thanos/vendor/github.com/prometheus/prometheus/tsdb/encoding/encoding.go:180
github.com/prometheus/prometheus/tsdb/encoding.NewDecbufAt(0xb7d9c0, 0xc0148b2780, 0x5, 0xc000170400, 0x0, 0x0, 0x0, 0x0, 0x0)
/opt/ts/tshouse-thanos/vendor/github.com/prometheus/prometheus/tsdb/encoding/encoding.go:126 +0x23c
github.com/prometheus/prometheus/tsdb/index.NewSymbols(0xb7da00, 0xc0148b2780, 0x2, 0x5, 0x105910476, 0x0, 0x0)
/opt/ts/tshouse-thanos/vendor/github.com/prometheus/prometheus/tsdb/index/index.go:1246 +0xd0
github.com/prometheus/prometheus/tsdb/index.(*Writer).finishSymbols(0xc000284f00, 0xc001b484e0, 0x0)
/opt/ts/tshouse-thanos/vendor/github.com/prometheus/prometheus/tsdb/index/index.go:534 +0x3cb
github.com/prometheus/prometheus/tsdb/index.(*Writer).ensureStage(0xc000284f00, 0xc000000102, 0xc000036000, 0xc00108ee78)
/opt/ts/tshouse-thanos/vendor/github.com/prometheus/prometheus/tsdb/index/index.go:359 +0x273
github.com/prometheus/prometheus/tsdb/index.(*Writer).AddSeries(0xc000284f00, 0x0, 0xc00031c3c0, 0x6, 0x6, 0xc0003518c0, 0x1, 0x1, 0x0, 0x0)
/opt/ts/tshouse-thanos/vendor/github.com/prometheus/prometheus/tsdb/index/index.go:408 +0x48
github.com/prometheus/prometheus/tsdb.(*LeveledCompactor).populateBlock(0xc0001aafa0, 0xc00019e280, 0x7, 0x8, 0xc0001f46c0, 0xb82060, 0xc000284f00, 0xb7b7c0, 0xc0001aa960, 0x0, ...)
/opt/ts/tshouse-thanos/vendor/github.com/prometheus/prometheus/tsdb/compact.go:783 +0x1345
github.com/prometheus/prometheus/tsdb.(*LeveledCompactor).write(0xc0001aafa0, 0x7ffd24b428dd, 0x65, 0xc0001f46c0, 0xc00019e280, 0x7, 0x8, 0x0, 0x0)
/opt/ts/tshouse-thanos/vendor/github.com/prometheus/prometheus/tsdb/compact.go:582 +0x5d8
github.com/prometheus/prometheus/tsdb.(*LeveledCompactor).Compact(0xc0001aafa0, 0x7ffd24b428dd, 0x65, 0xc00019ea80, 0x7, 0x8, 0x0, 0x0, 0x0, 0xea51d4b131a97a01, ...)
/opt/ts/tshouse-thanos/vendor/github.com/prometheus/prometheus/tsdb/compact.go:424 +0x617
main.main()
/opt/ts/tshouse-thanos/pkg/compact/tsdb.go:104 +0xc43
crc,^crc 898838549 3396128746
exp,dec.Crc32 1697605998 3396128746

Hi，i have added more infos,pls help to review that. Our tsdb take lots service datas,
a monitor metric’s label may change as time flows, it also may be dropped at some chunk.So may this affect the final compact. i also find the tsdb code try to add series from chunks according a global index symbol
------------------ Original ------------------
From: Levi Harrison @.>
Date: Wed,Jul 14,2021 10:11 AM
To: prometheus/prometheus @.>
Cc: Jupiter @.>, Author @.>
Subject: Re: [prometheus/prometheus] when compact blocks, err "errors: populate block: add series: read symbols: invalid checksum; read symbols: invalid checksum" (#9078)
What OS are you using? I know we've had problems with OpenBSD.
#8877
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Maybe related to https://github.com/thanos-io/thanos/issues/1728?
Also, what Thanos version are you using? I can't find pkg/compact/tsdb.go anywhere.

prometheus version: 1.8.2
thanos version : 0.16.0 , #1728 has no conclusion now.
ah,compact/tsdb.go is my test tool according thanos/pkg/compact/compact.go . our current version may has much different with master.
very confused and  sad -_-

Given the RC for 0.22.0 was just released, and it's been almost a year since 0.16.0 came out, you might want to try upgrading, although I know that might be difficult with your custom version. Thanos doesn't actually use version 1.8.2 of Prometheus (if it did there would be no /tsdb directory), so by upgrading you'd get both new Thanos and TSDB changes.
https://github.com/thanos-io/thanos/issues/1728 ends at the 64 GiB index limit, which seems to not have been fixed yet as #5884 isn't merged. I wonder how big the indexes in those blocks are, maybe it is that.
You may also want to file an issue in Thanos and see what they say.

en, i try to use the latest prometheus version, then make my compact tool, the error also occurs.
BTW, i think it has no business with thanos, because it also use the prometheus's compact interface.
the very simple tool  like:
ctx, _ := context.WithCancel(context.Background())
levels, err := compactions.levels(4)
compDownSample, err := tsdb.NewLeveledCompactor(ctx, nil, logger, levels, downsample.NewPool(),nil)
comps := map[int64]tsdb.Compactor{
downsample.ResLevel1: compDownSample ,
downsample.ResLevel2: compDownSample,
}
fmt.Println("start tsdb tool,plan",plan)
var compID  [16]byte
compID, err = comp.Compact(dir, plan, nil)

Hi,LeviHarrison
i think i have dug out the  reason of my "invalid checksum":
index->symbol len is 4byte, but our service datas, reach to 4388357229, and it's cut down to 4byte. So the crc32 errors in the end.
prometheus/tsdb/index/index.go  func() finishSymbols
w.buf1.PutBE32int(int(w.f.pos - w.toc.Symbols - 4))
btw, thank you very much for your help and proposal.

So, Can tsdb make some optimization ？@fabxc   @bwplotka @roidelapluie  please help to review. Thanks a lot.

@t00350320 thanks for your investigation, seems like you found the issue.

So, Can tsdb make some optimization ？

Can you please elaborate on this?

hi
root cause is :according to tsdb index file format, symbol_table part, first 4byte shows the length of total symbol strings of all the blocks being compacted. It works well at most time.
But our prometheus systerm has more than 10 million symbols. So the symbol_table part becomes really big. It’s larger than 4byte. In function finishsymbol() , the original symbolstr len is cut down to 4byte, like:
putbe32(f.pos-toc.symbol-4 )
When make crc32 hash to fill the index’ symbol_part’s crc32 zone, it use the cut down length . But at Newdecbuf crc32 check(newsymbol), it reads the original length.
So this the details. You can find all in func finishsymbol.
tadb compact blocks workflow like this:
func populateBlocks
   addsymbols from all blocks.( now the new index file only has symbol info,but symbol length and crc32 have not been filled)
   addchunk one by one (now the new chunk file start to make)
   addseries of cur chunk(because all the symbols have been written to index, we need to finish symbols by filling symbol len and crc32(error pops up here). then the index of symbol_table part finished.  series are appended...)
------------------ Original ------------------
From: Ganesh Vernekar @.>
Date: Mon,Jul 19,2021 9:17 PM
To: prometheus/prometheus @.>
Cc: Jupiter @.>, Mention @.>
Subject: Re: [prometheus/prometheus] when compact blocks, err "errors: populate block: add series: read symbols: invalid checksum; read symbols: invalid checksum"【tsdb/index/index.go】【cause found, need review！！！】 (#9078)
@t00350320 thanks for your investigation, seems like you found the issue.
So, Can tsdb make some optimization ？
Can you please elaborate on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

So can tsdb reserve 8byte for symbollen zone. We know fabulous amounts of IOT services will access to prometheus systerm.
------------------ Original ------------------
From: Jupiter @.>
Date: Mon,Jul 19,2021 10:28 PM
To: reply+AJ4LJWC4PURI7GRR6VTLFVV7AFOF5EVBNHHDQNYUJQ @.>
Subject: Re: [prometheus/prometheus] when compact blocks, err "errors: populate block: add series: read symbols: invalid checksum; read symbols: invalid checksum"【tsdb/index/index.go】【cause found, need review！！！】 (#9078)
hi
root cause is :according to tsdb index file format, symbol_table part, first 4byte shows the length of total symbol strings of all the blocks being compacted. It works well at most time.
But our prometheus systerm has more than 10 million symbols. So the symbol_table part becomes really big. It’s larger than 4byte. In function finishsymbol() , the original symbolstr len is cut down to 4byte, like:
putbe32(f.pos-toc.symbol-4 )
When make crc32 hash to fill the index’ symbol_part’s crc32 zone, it use the cut down length . But at Newdecbuf crc32 check(newsymbol), it reads the original length.
So this the details. You can find all in func finishsymbol.
tadb compact blocks workflow like this:
func populateBlocks
   addsymbols from all blocks.( now the new index file only has symbol info,but symbol length and crc32 have not been filled)
   addchunk one by one (now the new chunk file start to make)
   addseries of cur chunk(because all the symbols have been written to index, we need to finish symbols by filling symbol len and crc32(error pops up here). then the index of symbol_table part finished.  series are appended...)
------------------ Original ------------------
From: Ganesh Vernekar @.>
Date: Mon,Jul 19,2021 9:17 PM
To: prometheus/prometheus @.>
Cc: Jupiter @.>, Mention @.>
Subject: Re: [prometheus/prometheus] when compact blocks, err "errors: populate block: add series: read symbols: invalid checksum; read symbols: invalid checksum"【tsdb/index/index.go】【cause found, need review！！！】 (#9078)
@t00350320 thanks for your investigation, seems like you found the issue.
So, Can tsdb make some optimization ？
Can you please elaborate on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

I have few more questions for you:

What is the architecture of your system? 32 bit or 64 bit? (since you said IOT)
What is the number of series in that block?

You mentioned 10M symbols, and the 4 bytes in the symbol table is the number of symbols which can easily hold the number 10M, and we are actually using 8 bytes for storing the byte offset of the symbol table in the TOC. But I see that we are doing int(<byte offset>) when consuming it, which will end up being a 32 bit int in 32 bit architecture.

Ah I totally missed that len part in the symbol table. Making it 8 bytes is a big breaking change. While it might be possible to do it with versioning, we have to analyse how it might affect entire ecosystem (like if it will make running on 32 bit IoT systems impossible). And if we are going to bump up the version, we might as well spend some time in seeing what other things we could possibly improve, so it is not going to be a instant change.
That said, to fill up 2^32 bytes of symbol table with 11744785 symbols, the average size of symbol should be 365 bytes, which is very big and not ideal. You should try to analyse the labels and avoid any long label name/values.
PS: No issues with delayed replies, that's totally fine.

yes, modify the index format length is not esay. I'll add an errlog and pull request later, when the actual length over 4byte.

@codesome  now that https://github.com/prometheus/prometheus/pull/9104/files is fixed, can we close this?

#9104 only adds a log for this and does not fix the underlying issue. I think we should keep it open until we eventually fix this.

I wonder if we can somehow leverage https://github.com/prometheus/prometheus/pull/11711 to create another BlockPopulator and shard the results blocks and prevent hitting the 64GB limit.
Thoughts?

I think we should also discuss if we shouldn't make this a known limitation by design, document it and keep it as is. Anything beyond 64GB limit (or even half of it) is basically physically un-queryable (too long to traverse all postings) and should be sharded to multiple blocks by series dimension.
Also I think the original error report is not valid anymore as Thanos handles this in a clean way, by ignoring that compaction group and allowing users to shard manually (until auto vertical block sharding is done).

Closing this in lieu of #5868 . The current plan is to port a Thanos feature to avoid compacting blocks that are too large.
The larger index size seems to be too complicated to get it in.

authors: LeviHarrison alanprot beorn7 bwplotka codesome liubo-it roidelapluie t00350320

repo: prometheus/prometheus


text:
Prepare Release 2.47.2

Cherry-pick one PR #12838 as requested by @krajorama.
Also this will build with Go 1.21.3, thus resolving certain CVE reports.

hi @bboreham  can you cherrypick  #12760  as well due to CVE reported due to alertmanager dependency
https://github.com/advisories/GHSA-v86x-5fm3-5p7j
CVE-2023-40577

Why is Prometheus vulnerable to that?

Why is Prometheus vulnerable to that?

i @bboreham  container vulnerability scanners are picking upreference to alertmanager package used in go.mod i suppose and falgging this prometheus dockerimage.

Indeed. However it is the policy of the Prometheus project to respond to real vulnerabilities and not to react to spurious reports from inaccurate scanners.

Indeed. However it is the policy of the Prometheus project to respond to real vulnerabilities and not to react to spurious reports from inaccurate scanners.

The funny things is that we are not even using alertmanager for our prometheus setup . but you can`t  argue with vogons :(

The release candidate for 2.48.0 should be out in the next day or so, and will include the change you asked about.

authors: bboreham nikhil-bhat


text:
Add a favicon to the web GUI

The favicon is taken from https://prometheus.io/assets/favicons/favicon.ico
For @fabxc ?

There is a similar open (but ancient) PR here: https://github.com/prometheus/prometheus/pull/1238
I don't feel strongly about the details discussed there, so I'd like to leave the decision to those that do.
@juliusv perhaps?

Thanks for the reply, beorn7.
I find it helpful to have a favicon to find Prometheus in the list of open tabs in my browser. This PR would be Good Enough for that.

It's kind of hilarious that we still haven't managed to get a Favicon, even though it's annoying for ourselves as well.
I'm perfectly fine with this. 👍
@alicebob would you mind filing the same PR against Alertmanager? As the other PR hints, ideally we'd have a distinguishing color – but this ends in endless discussions around design concerns again. This is way better than nothing.

authors: alicebob beorn7 fabxc


text:
Add custom labels and busy flag to github runner metrics

Currently , github runner exporter metrics only give the following properties "owner", "id", "name", "os", "status".
The underlying github client provides additional properties like labels and busy boolean flag.
It is helpful to have the labels in case of self hosted runners as those can be used downstream.
Similarly, having a boolean flag for the busy status helps in better incorporation downstream.

Busy is a separate metric, so IMHO it doesn't make sense to add it as a label.

And generally speaking you should use the getters defined by the GitHub client, that way you don't need to fight with alle the pointers.

Thanks, Will remove the busy label . Though I still feel we should keep the customs label as additional properties in the metrics. What do you think ?

I'm not sure if somebody really needs the worker labels as metric labels. We already got a pretty crazy label cardinality. Maybe it should be done similar to the workflow collector, than it's up to the user to define his own cardinality and the defaults are more simple.

When you speak about workflow collector which flow should I look into ? Is there any example dashboard to check it and whether I can use it for my usecase.

There are various places where the config option for a flexible list of labels is defined:

https://github.com/promhippie/github_exporter/blob/master/pkg/command/command.go#L315-L321
https://github.com/promhippie/github_exporter/blob/master/pkg/config/config.go#L37
https://github.com/promhippie/github_exporter/blob/master/pkg/config/config.go#L86-L99
https://github.com/promhippie/github_exporter/blob/master/pkg/exporter/workflow.go#L34
https://github.com/promhippie/github_exporter/blob/master/pkg/exporter/workflow.go#L122-L127
https://github.com/promhippie/github_exporter/blob/master/pkg/store/types.go#L26-L56
https://github.com/promhippie/github_exporter/blob/master/hack/generate-metrics-docs.go#L28

There you can see all the places where something got to be defined to get everything properly configured :)

Thanks. By a quick glance, what I understand is these are workflow labels. However, I am interested in getting the custom labels attached to a runner  example
{id : 10, 	name : ai-runner-gpu, 	type: custom} as returned by github client. I would look further into this but in case you know if that would be possible to get via the flow you have suggested as prometheus pmetrics.

I know, but at least for me the runner labels are not interesting for the Prometheus labels and they tend to increase the Prometheus label cardinality, at https://www.robustperception.io/cardinality-is-key/ you can find a nice articel for that topic.
With the configurable way mentioned above the admin of the exporter can decide about the cardinality. I would run it with the default labels for the runner collector, you would append labels to the the list of labels and somebody else would strip it even more down.

To be more specific, by default it would be the same as before:

owner
id
name
os
status

For you this would be set to this via environment variable:

owner
id
name
os
status
labels

And somebody else who don't care about all the additional labels could do:

owner
id
name

Thanks. I will update this thread once I have tried this out and how I could use it in my use case.

Thanks for your patience. Write a message if something is still unclear or if you want to discuss it further. We could also chat on Gopher Slack or some other platform like Matrix if you want to discuss something more interactively :)

Hi, how do I join the gopher slack. i guess it is invite only.

I think you can join via https://invite.slack.golangbridge.org/

Created a new PR with our discussion : https://github.com/promhippie/github_exporter/pull/283

authors: SudeshnaBora tboerger


text:
[Fix #263] Implement imread

Renamed compare branch from r/checkpoints to imread (previous discussion at #291)

Tests are failing using dl backed and the reason is img.dataSync() returns a Uint8Array on tf and Float32Array when we use dl backend.

@Qti3e I knew about this issue, and was checking to see if it was discovered here: https://github.com/propelml/propel/issues/51
I will try to fix that today now that it's blocking you.

@ry Thanks, would be great : )

@ry Scipy has support for Float32 as well, Would it be possible to implement this thing after you force dl to return an Int32Array ?:thinking: https://github.com/scipy/scipy/blob/f238270111976d00615686395df0986847c25132/scipy/misc/pilutil.py#L291-L294

@Qti3e I'd rather our imread only return integer tensors. Because we have the rescale() method, it's easy for users to change to float if they want.

@ry PTAL

repo: propelml/propel


text:
Create decentralize-danny.toml

add new event to website per Flor

@tbenbow Can you take a look at PR, it is failing and I am not sure what the issue is.


text:
🛑 nftschool.dev is down

In 527b272, nftschool.dev (https://nftschool.dev) was down:

HTTP code: 0
Response time: 0 ms

Resolved: nftschool.dev is back up in 62cf8a7 after 33 minutes.

repo: protocol/upptime-pln


text:
🛑 dist.ipfs.tech is down

In a0724bd, dist.ipfs.tech (https://dist.ipfs.tech) was down:

HTTP code: 404
Response time: 19 ms

Resolved: dist.ipfs.tech is back up in 3629f6c after 6 minutes.


text:
🛑 docs.ipfs.io is down

In 1ed8681, docs.ipfs.io (https://docs.ipfs.io) was down:

HTTP code: 526
Response time: 670 ms

Resolved: docs.ipfs.io is back up in 501bd27 after 12 minutes.


text:
Add GCAM-China

Insert URLs to the project here: https://github.com/umd-cgs/gcam-china

[x] The projects is active, documented, open source licensed, shows usage from external parties and is directly targeting environmental sustainability. Find more details in the Contribution Guide.

All issues labeled as Good First Issue of the project listed on OpenSustain.tech will be visible on ClimateTriage.com. This is a great way to welcome new community members to your project.
All projects listed will be posted on our Mastodon channel

@bpbond @pralitp

repo: protontypes/open-sustainable-technology


text:
望改进！

不能与ssr同时使用，需要切换代理有点麻烦，希望可以改进

这两个必然有冲突的，因为都是使用代理的方式

不知是否可行。。。先有
情景模式：Proxyee Down（HTTP:9999）及SSR（SOCKS5:1080）
再建“自动切换模式”：规则列表规则走SSR，默认情景模式走Proxyee Down（😂还是二者互换？）

@AnyWAT 这样是可以，但是配置起来麻烦，还不如每次下载前切换下模式，毕竟下载不常有

但 https://github.com/proxyee-down-org/proxyee-down/issues/805#issuecomment-424605817 pac?t= 后面的数字时变时新，顷刻即失常，😂 还是上述自建“自动切换模式”来得简单点？

authors: AnyWAT jiangxiaoshaui monkeyWie

repo: proxyee-down-org/proxyee-down

license_source: bigquery


text:
Metadata not received Android/Windows

Hi,
I tried the ESP-A2DP example sketch with the following environment
Arduino 1.8.15. ESP32 Core: 1.0.6
ESP32-A2DP
So far I have no success with metadata from any device:
Tried the following devices
Huawei Mate 10 Android 11(AVRCP 1.6)

Huawei Media Player
Samsung Media Player (known that this one transmits AVRCP Data correct)
Hifi-Cast Player (known for proper AVRCP standard)
Deezer

Samsung A3 2016

Samsung Media Player

Huawei Media M5 lite Tab 10.1

Huawei Music Player

Lenovo T460 Notebook

Windows Media Player

None of the above showed any Metadata.
I can control volume, I can skip up and down
Tried as well Arduino IDE 1.8.13 with ESP32 Core 1.0.4-> same result
Do you have any idea what I am doing wrong?
Sketch:
bt_music_receiver_to_dac.txt
Logs:
verboselogs.txt

You are right, the AVRC Metadata for the release < 2.0.0 was broken when I introduced the support for 2.0.0. I have committed the correction and you can try again.

Thanks for the fast help and rework of your code.
I tried again and it works as expected:
21:05:01.377 -> [W][BluetoothA2DPSink.cpp:410] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
21:05:01.446 -> [I][BluetoothA2DPSink.cpp:752] av_hdl_avrc_evt(): AVRC passthrough rsp: key_code 0x4b, key_state 0
21:05:01.533 -> [W][BluetoothA2DPSink.cpp:410] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
21:05:01.580 -> [I][BluetoothA2DPSink.cpp:752] av_hdl_avrc_evt(): AVRC passthrough rsp: key_code 0x4b, key_state 1
21:05:01.878 -> [W][BluetoothA2DPSink.cpp:410] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
21:05:01.978 -> [W][BluetoothA2DPSink.cpp:410] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
21:05:01.978 -> [I][BluetoothA2DPSink.cpp:756] av_hdl_avrc_evt(): AVRC metadata rsp: attribute id 0x1, Million Years Ago
21:05:01.978 -> [W][BluetoothA2DPSink.cpp:410] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
21:05:02.032 -> [I][BluetoothA2DPSink.cpp:756] av_hdl_avrc_evt(): AVRC metadata rsp: attribute id 0x2, Adele
21:05:02.032 -> [W][BluetoothA2DPSink.cpp:410] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
21:05:02.032 -> [I][BluetoothA2DPSink.cpp:756] av_hdl_avrc_evt(): AVRC metadata rsp: attribute id 0x4, 25
21:05:02.032 -> [W][BluetoothA2DPSink.cpp:410] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
21:05:02.032 -> [I][BluetoothA2DPSink.cpp:756] av_hdl_avrc_evt(): AVRC metadata rsp: attribute id 0x8, 9
21:05:02.032 -> [W][BluetoothA2DPSink.cpp:410] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
21:05:02.032 -> [I][BluetoothA2DPSink.cpp:756] av_hdl_avrc_evt(): AVRC metadata rsp: attribute id 0x10, 11
21:05:02.105 -> [W][BluetoothA2DPSink.cpp:410] app_task_handler(): app_task_handler, APP_SIG_WORK_DISPATCH sig: 1
21:05:02.105 -> [I][BluetoothA2DPSink.cpp:756] av_hdl_avrc_evt(): AVRC metadata rsp: attribute id 0x20,
21:05:02.936 -> Connected Lautstärke 1: 70
21:05:05.951 -> Connected Lautstärke 1: 70

authors: Uspizig pschatzmann


text:
Addition of lighted and shaded triangles to PSM3D

This should be achieved via a settable lighting mode and configurable ambient and directional lights.

Shaded triangles added in 20bd23f8f0f8c23832abf5d69776e926cc205e01. Lighting system to be worked on soon.

Lighting system with ambient and diffuse lighting added in 32b158f708f44873e30e7485978c65e8aee98f44.

repo: pseudophpt/pseultra


text:
WIP: Reference Implementations Citations & Doc Update -- fixes #9

Description
Provides proper citations for reference implementations w/in READMEs and scripts themselves.  Also provides docs cleanup & copyright year update.
Questions:

I will handle incorporating all of the appropriate references, but I may ping script authors for some assistance locating proper resources if it's not clear already where equations/algorithms come from.

Progress
I will update the following list of reference implementation modules as they are finished and incorporated into this PR.  Hopefully this can be a quick process.

[ ] Configuration Interaction
[ ] Coupled Cluster
[x] Electron Propabator
[x] MD Verlet Integrator
[x] Moller-Plesset
[x] One electron property/RESP
[ ] Response Theory
[ ] Self-Consistent Field
[ ] SAPT

Status

[x] Click when ready for review
[ ] Click when ready for merge

Whoops I just went directly to the changes which looked like a complete set of changes. Too late now, please do make a new PR.

authors: dgasmith dsirianni


text:
Streaming Server is not available

Hi,
Found this docker image and it's super great and helpful. I got the docker image running, open it up with http://:8080, all good, but it complains "Streaming Server is not available", i tried to install this stream-service on my ubuntu 22.04 following the chatgpt tutorial but the "stremio-service.service - Stremio Service" failed, do you have any tutorial to install this? or am i on the wrong path?
Thank you so much for the help.

Hi,
Try this : https://github.com/psyb0t/safe-stremio/pull/2

Hi,
Found this docker image and it's super great and helpful. I got the docker image running, open it up with http://:8080, all good, but it complains "Streaming Server is not available", i tried to install this stream-service on my ubuntu 22.04 following the chatgpt tutorial but the "stremio-service.service - Stremio Service" failed, do you have any tutorial to install this? or am i on the wrong path?
Thank you so much for the help.

The solution to that is this: https://github.com/psyb0t/safe-stremio/tree/master?tab=readme-ov-file#final-steps
Checking the solution that @Korben00 came up with now.

Okay so the solution to that is remains this: https://github.com/psyb0t/safe-stremio/tree/master?tab=readme-ov-file#final-steps. @yinjiehuang pls confirm that it's working on your end so that I can close this issue.

works fine now! Thank you folks!

@yinjiehuang awesome! 🖤🖤 closing the issue now.

license: WTFPL


text:
Performance: use git index to list existing files in get_list_of_assets()

The function get_list_of_assets() is extremly inefficient, and gets called many times (e.g. when creating a new file, when renaming a file, and probably also during some of onyo fscks functions).
The inefficience is mainly caused through this call in a loop:
run_cmd("git -C \"" + repo_path + "\" check-ignore --no-index \"" + elem + "\"")
Instead there should be used the git index, which can probably already be called to list files with the python git implementation used in other functions.

I have encountered this numerous times in onyo fsck. I will address this as part of my work refactoring the command.

I close this issue, because the git index is used since the merge #216, and your onyo fsck work also solves this.
If there is something that I am missing, feel free to open again.

authors: TobiasKadelka aqw

repo: psyinfra/onyo

license: ISC


text:
New server purchase by someone with a subuser on panel results in error

Basically the title.
If someone makes a server purchase on WHMCS, but that persons email is already tied to a subuser account on the pterodactyl panel, there's an error during server creation.
Deleting their subuser account resolves the issue.

You’d need to include the actual error as the account already existing shouldn’t affect the module as it checks for that.

post - https://panel.exiled.host/api/application/users
{"username":"REDACTED","email":"REDACTED","first_name":"REDACTED","last_name":"REDACTED","external_id":"1114"}

Array
(
    [errors] => Array
        (
            [0] => Array
                (
                    [code] => ValidationException
                    [status] => 422
                    [detail] => The email has already been taken.
                    [meta] => Array
                        (
                            [source_field] => email
                            [rule] => unique
                        )

                )

        )

    [status_code] => 422
)

get - https://panel.exiled.host/api/application/users?filter[email]=REDACTED
(returns a long list of some users, but is not a complete list and does not have the user in question on said list)
get - https://panel.exiled.host/api/application/users/external/1114
Array
(
    [errors] => Array
        (
            [0] => Array
                (
                    [code] => NotFoundHttpException
                    [status] => 404
                    [detail] => The requested resource could not be found on the server.
                )

        )

    [status_code] => 404
)

This sounds to me like you're running the wrong version of the module for your panel, or it's just fully ignoring ?filter[email]= query string be it due to a different panel version or custom modifications.

Panel version 1.10.1, unsure how to check the module version, but this has always been an issue, honestly it just didn't happen enough to be a concern until recently. And it's happened on unmodded panel versions.

Still happening, Wings 1.11.8, Panel 1.11.2 (also tried upgrading panel to 1.11.5 and no change)

This sounds to me like you're running the wrong version of the module for your panel, or it's just fully ignoring ?filter[email]= query string be it due to a different panel version or custom modifications.

This reply still applies.

Imagine, I update everything to the most recent version, and somehow you still think it's because something is outdated. I'm honestly amazed at your logic.

Here is my reasoning:

Based on the provided module debug logs, ?filter[email]=... returns multiple matches for an exact match => something is wrong either in the module or the panel
If the module or the panel was broken out of the box, significantly more people would notice this being broken, especially when it's something as obvious as assigning the servers to the wrong user. Every company using this module would as a result have people complaining that they didn't get their paid service assigned to them, which would rather quickly be narrowed down to possibly being related to this module as it is responsible for doing the whole server creation.
You are running a modified version of the panel based on the login page not being the default one. Thus the conclusion based on the previous points is that you have modified your panel and as a result broken some functionality in it that prevents returning the exact user based on the email match. I've also confirmed that the latest panel version does not behave like what you're claiming, thus I realistically can't provide support for the changes that you've made to your panel - but this of course would be a completely different scenario if you did run stock Pterodactyl where this issue happens.

Ok well my company is merging with another so in a few weeks when it happens again on a default panel just like it was before I installed a theme, I'll come back to see what the next excuse is.

As mentioned before, I'm unable to reproduce this with a stock install of the latest panel version. However, if you have more concrete reproduction steps that I can do to replicate this issue, I would be happy to fix this if it's genuinely an issue with the module.

repo: pterodactyl/whmcs


text:
Remove this Indian Railways (http://api.erail.in) False api #important

Please remove this from apiurl list it's a false api
it's on transportation section and named as Indian railways
by checking it manually its look like a someone's personal website please check and remove it

Link - False api link

Hi,
Indian Railways don't have an official API for public, but I found a website which that provides API and is authorized by Indian Railways.
I would like to work on this issue.
Link - https://www.affiliate.confirmtkt.com/

repo: public-apis/public-apis


text:
Publicodes vs openfisca vs catala ?

Ecrire un petit texte (format billet de blog) présentant et expliquant les différences et points communs entre publicodes, catala et openfisca.

J'ai l'impression que ça se rapproche de https://github.com/publicodes/publicodes/wiki/Projets-similaires, à fusionner ?
Je l'ajoute dans le blog

authors: Clemog EmileRolley

repo: publicodes/publicodes


text:
UAT | E-filing | Error for same mobile number

Module: E-filing
Section: Respondent Details
Issue: There is an error message displayed for 'Respondent cannot have same mobile number as complainant' displayed only when Respondent email address is added:

Respondent mobile number is added as same number as complainant.
Respondent email address is added

Expected behavour:

Error message is displayed post adding mobile number and not only when email is added

resolved

repo: pucardotorg/dristi


text:
[Snyk] Security upgrade openjdk from 17-jdk-alpine to 24-ea-12-jdk-oraclelinux8

Snyk has created this PR to fix 4 vulnerabilities in the dockerfile dependencies of this project.
Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Snyk changed the following file(s):

build/maven/Dockerfile

We recommend upgrading to openjdk:24-ea-12-jdk-oraclelinux8, as this image has only 30 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Out-of-bounds Read SNYK-ALPINE314-APKTOOLS-1533752
  714

Off-by-one Error SNYK-ALPINE314-LIBTASN1-3173577
  714

Buffer Overflow SNYK-ALPINE314-OPENSSL-1569445
  714

Buffer Overflow SNYK-ALPINE314-OPENSSL-1569445
  714

Out-of-bounds Write SNYK-ALPINE314-ZLIB-2976174
  714

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

@tejasbeehyv Found this vulnerability. Can you please look into this upgrade the base images as required?


text:
在headerview是地图的时候，地图和maintableview手势冲突，这个要如何解决呢？谢谢了。

Feature描述
请简单描述你想要的效果：
在headerview是地图的时候，地图和maintableview手势冲突，这个要如何解决呢？谢谢了。

参考效果
如果你想要实现一个其他APP已有的效果：
1.参考APP名字：
2.目标页面路径：
3.目标效果截图：
其他补充
关于目标效果的其他说明：？

你尝试实现- (BOOL)mainTableViewGestureRecognizer:(UIGestureRecognizer *)gestureRecognizer shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer;代理方法，当判断otherGestureRecognizer是地图的手势时，就return NO；

蛋疼，百度地图是没有手势漏出……

你打断点看一下手势的类名，或许有线索

好的


text:
Carthage error

Skipped building JXSegmentedView due to the error:
Dependency "JXSegmentedView" has no shared framework schemes for any of the platforms: iOS

Please use "github "pujiaxin33/JXSegmentedView" >= 1.3.2" to import, it works.


text:
[META] PDF considersations

Before a PDF download feature goes into production, consider:

#76
What should be on the front page? Something based on the rights? (Mudd sample: http://findingaids.princeton.edu/AC044/c0095.pdf)
Should this always be available for open content? If not, how do we decide when? Case by case?
Should the PDF be degraded in some way (grayscale? watermarked? extra compression?

See also #25

repo: pulibrary/plum


text:
riscv-dbg: Re-align dmi_bscane_tap interface with dmi_jtag_tap

The current occamy design does not synthesize for FPGA because of a pin-mismatch between dmi_jtag_tap.sv and dmi_bscane_tap.sv that was introduced in #373.
I also contributed this upstream.
CC: @bluewww @meggiman

Merged in upstream and released as https://github.com/pulp-platform/riscv-dbg/releases/tag/v0.5.1

repo: pulp-platform/snitch


text:
Document the PULUMI_CONSOLE_DOMAIN env var

Proposed changes
Add PULUMI_CONSOLE_DOMAIN to the documentation for supported environment variables.
Unreleased product version (optional)
This has long-since shipped in the CLI, added in https://github.com/pulumi/pulumi/pull/4410. 😓
Related issues (optional)
Fixes #2995

Semi-related: with the "suggest change" widget, this page doesn't look all that great. Has there been any discussion on if we want the Search/Feedback widget on the right to be collapsible or anything?

@cnunciato the idea of changing the layout to just have two columns, and put an example at the bottom of the description looks awesome. I'm inclined to not spend any more time on this, but should the opportunity arise to adjust that page, your suggestion is 🔥 .

repo: pulumi/docs


text:
Importing a client fails with a panic

What happened?
Trying to import a client:
pulumi import auth0:index/client:Client aws

Gets an error:
Diagnostics:
  pulumi:pulumi:Stack (aws-sso-production):
    panic: interface conversion: interface {} is nil, not map[string]interface {}
    goroutine 30 [running]:
    github.com/auth0/terraform-provider-auth0/auth0.flattenClientAddons(0xc000b4c030)
    	/home/runner/go/pkg/mod/github.com/auth0/terraform-provider-auth0@v0.29.0/auth0/resource_auth0_client.go:997 +0xbdd
    github.com/auth0/terraform-provider-auth0/auth0.readClient(0xc000438230, {0x1eac9e0, 0xc00082cf00})
    	/home/runner/go/pkg/mod/github.com/auth0/terraform-provider-auth0@v0.29.0/auth0/resource_auth0_client.go:640 +0x10db
    github.com/hashicorp/terraform-plugin-sdk/helper/schema.(*Resource).Refresh(0xc0003f98c0, 0xc00062adc0, {0x1eac9e0, 0xc00082cf00})
    	/home/runner/go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk@v1.16.1/helper/schema/resource.go:516 +0x1df
    github.com/hashicorp/terraform-plugin-sdk/helper/schema.(*Provider).Refresh(0xc000566380, 0xc0008df690, 0x10)
    	/home/runner/go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk@v1.16.1/helper/schema/provider.go:333 +0x65
    github.com/pulumi/pulumi-terraform-bridge/v3/pkg/tfshim/sdk-v1.v1Provider.Refresh({0xc0008df870}, {0x200a529, 0xc000566400}, {0x22b97b8, 0xc000465f00})
    	/home/runner/go/pkg/mod/github.com/pulumi/pulumi-terraform-bridge/v3@v3.20.0/pkg/tfshim/sdk-v1/provider.go:102 +0x99
    github.com/pulumi/pulumi-terraform-bridge/v3/pkg/tfbridge.(*Provider).Read(0xc00080e6c0, {0x22b8788, 0xc0006155f0}, 0xc00062aa50)
    	/home/runner/go/pkg/mod/github.com/pulumi/pulumi-terraform-bridge/v3@v3.20.0/pkg/tfbridge/provider.go:941 +0x651
    github.com/pulumi/pulumi/sdk/v3/proto/go._ResourceProvider_Read_Handler.func1({0x22b8788, 0xc0006155f0}, {0x1f85720, 0xc00062aa50})
    	/home/runner/go/pkg/mod/github.com/pulumi/pulumi/sdk/v3@v3.27.0/proto/go/provider.pb.go:2647 +0x7b
    github.com/grpc-ecosystem/grpc-opentracing/go/otgrpc.OpenTracingServerInterceptor.func1({0x22b8788, 0xc000615380}, {0x1f85720, 0xc00062aa50}, 0xc0004e20c0, 0xc00000c468)
    	/home/runner/go/pkg/mod/github.com/grpc-ecosystem/grpc-opentracing@v0.0.0-20180507213350-8e809c8a8645/go/otgrpc/server.go:57 +0x425
    github.com/pulumi/pulumi/sdk/v3/proto/go._ResourceProvider_Read_Handler({0x1fc6de0, 0xc00080e6c0}, {0x22b8788, 0xc000615380}, 0xc00096e4e0, 0xc0004e2fe0)
    	/home/runner/go/pkg/mod/github.com/pulumi/pulumi/sdk/v3@v3.27.0/proto/go/provider.pb.go:2649 +0x138
    google.golang.org/grpc.(*Server).processUnaryRPC(0xc00037da40, {0x22cf8c0, 0xc0001fa600}, 0xc000854120, 0xc000856330, 0x2c9eed8, 0x0)
    	/home/runner/go/pkg/mod/google.golang.org/grpc@v1.37.0/server.go:1217 +0xc8f
    google.golang.org/grpc.(*Server).handleStream(0xc00037da40, {0x22cf8c0, 0xc0001fa600}, 0xc000854120, 0x0)
    	/home/runner/go/pkg/mod/google.golang.org/grpc@v1.37.0/server.go:1540 +0xa2a
    google.golang.org/grpc.(*Server).serveStreams.func1.2()
    	/home/runner/go/pkg/mod/google.golang.org/grpc@v1.37.0/server.go:878 +0x98
    created by google.golang.org/grpc.(*Server).serveStreams.func1
    	/home/runner/go/pkg/mod/google.golang.org/grpc@v1.37.0/server.go:876 +0x294

    error: preview failed

  auth0:index:Client (aws):
    error: Preview failed: transport is closing

Same issue if important with the resource option:
const app = new auth0.Client("aws", {

}, { import: "<id>"})

Steps to reproduce

Create an auth0 client
try and import

Expected Behavior
It imports
Actual Behavior
A panic
Versions used
CLI
Version      3.30.0
Go Version   go1.17.9
Go Compiler  gc

Plugins
NAME    VERSION
auth0   2.8.0
aws     5.3.0
docker  3.2.0
nodejs  unknown

Host
OS       darwin
Version  12.3.1
Arch     x86_64

This project is written in nodejs (/Users/lbriggs/.asdf/shims/node v14.16.0)

Current Stack: lbrlabs/production

Found no resources associated with lbrlabs/production

Found no pending operations associated with lbrlabs/production

Backend
Name           pulumi.com
URL            https://app.pulumi.com/jaxxstorm
User           jaxxstorm
Organizations  jaxxstorm, lbrlabs, team-ce, demo, pulumi

NAME            VERSION
@pulumi/awsx    0.40.0
@pulumi/pulumi  3.30.0
@types/node     14.18.16
@pulumi/auth0   2.8.0
@pulumi/aws     5.3.0

Pulumi locates its logs in /var/folders/1y/s9gz0_l10hb2y8mtknj45stc0000gn/T/ by default

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 @jaxxstorm - I am struggling to reproduce this at this point in time.
On v2.8.0 of this provider

Created an example Client following the documentation- removed a few of the bells and whistles for simplicity's sake

pulumi about
CLI
Version      3.78.0
Go Version   go1.20.7
Go Compiler  gc

Plugins
NAME    VERSION
auth0   2.8.0
nodejs  unknown

Ran the import

pulumi import auth0:index/client:Client my_client <client_id obtained from console>
[...]
Please copy the following code into your Pulumi application. Not doing so
will cause Pulumi to report that an update will happen on the next update command.

Please note that the imported resources are marked as protected. To destroy them
you will need to remove the `protect` option and run `pulumi update` *before*
the destroy will take effect.

import * as pulumi from "@pulumi/pulumi";
import * as auth0 from "@pulumi/auth0";

const my_client = new auth0.Client("my_client", {
    allowedLogoutUrls: ["https://example.com"],
    allowedOrigins: ["https://example.com"],
    appType: "non_interactive",
    callbacks: ["https://example.com/callback"],
    clientMetadata: {
        foo: "zoo",
    },
    customLoginPageOn: true,
    description: "Test Applications Long Description",
    grantTypes: [
        "authorization_code",
        "http://auth0.com/oauth/grant-type/password-realm",
        "implicit",
        "password",
        "refresh_token",
    ],
    isFirstParty: true,
    isTokenEndpointIpHeaderTrusted: true,
    jwtConfiguration: {
        alg: "RS256",
        lifetimeInSeconds: 300,
        scopes: {
            foo: "bar",
        },
        secretEncoded: true,
    },
    mobile: {
        ios: {
            appBundleIdentifier: "com.my.bundle.id",
            teamId: "9JA89QQLNQ",
        },
    },
    name: "myClient-48368fa",
    refreshToken: {
        expirationType: "non-expiring",
        idleTokenLifetime: 2592000,
        infiniteIdleTokenLifetime: true,
        infiniteTokenLifetime: true,
        rotationType: "non-rotating",
        tokenLifetime: 31557600,
    },
    tokenEndpointAuthMethod: "client_secret_post",
    webOrigins: ["https://example.com"],
}, {
    protect: true,
});

I can report an import of a similar basic client (modulo updates to the resource) also works on the latest version of this provider, v2.24.0.
If this issue still persists for you, please feel free to re-open this bug with the relevant details. 🙏

authors: guineveresaenger jaxxstorm


text:
Upgrade terraform provider aws to v5.21.0

Automation failed due to:

Conflict in patches within the upstream go.mod. Manually resolved but also, as suggested by @VenelinMartinov, moved the one added require line to be on its own to reduce future conflicts.
Manually mapped aws_ec2_image_block_public_access.

@iwahbe ta, it's related to the legacy S3 bucket - we need an extra module referenced

@iwahbe ta, it's related to the legacy S3 bucket - we need an extra module referenced

Thanks for checking.

authors: danielrbradley iwahbe

repo: pulumi/pulumi-aws


text:
Generate JAVA sdk from typescript provider error

Getting error while generating Java SDk from typescript provider
cd provider/cmd/pulumi-gen-abc && go run . java ../../../sdk/java /pulumi-abc-sdk/schema.json
Failed: Unrecognized language "java"%

@bala-auvaria Thank you for confirming, I moved this issue to the boilerplate repo. Indeed, we need to add Java here.

authors: bala-auvaria mikhailshilkov


text:
Unable to create an internal gcp.compute.GlobalAddress without an address

Hello!

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)

Issue details
Trying to create a GlobalAddress without specifying the address won't work.
Steps to reproduce
    const address = new gcp.compute.GlobalAddress(name, {
      purpose: 'PRIVATE_SERVICE_CONNECT',
      addressType: 'INTERNAL',
      project: project,
      network: pulumi.interpolate`projects/${project}/global/networks/default`,
    });

Expected: GCP should choose the address automatically as stated in the docs:

https://www.pulumi.com/registry/packages/gcp/api-docs/compute/globaladdress/#state_address_nodejs
https://cloud.google.com/compute/docs/ip-addresses/reserve-static-internal-ip-address#gcloud

Actual:
I get the following error:
    	* Error creating GlobalAddress: googleapi: Error 400: Invalid value for field 'resource.address': ''. The field is not a valid IP address or does not match the given prefix length, invalid

Hi @vschettino-asimov. First off, thanks for submitting this issue.
This looks like more of an issue with the docs than the code. I ran some tests and it looks like when purpose is PRIVATE_SERVICE_CONNECT:

addressType must be INTERNAL
If addressType is INTERNAL, address must be specified.

addressType and address are required when purpose is PRIVATE_SERVICE_CONNECT. The problem is that we don't have an example that demonstrates this, and the docs for the inputs do not specify the inter-dependencies.
FWIW, the gcloud docs do show an example with PRIVATE_SERVICE_CONNECT which implies the other required properties, but again - it's implicit and it should be more explicit:
gcloud compute addresses create PSC-ADDRESS-1 --global --addresses=10.110.0.10 --purpose=PRIVATE_SERVICE_CONNECT --network=default

Hope this helps for now! In the longer term, we'll look at including an example in the Pulumi docs that more clearly demonstrates this use case.

authors: jkodroff vschettino-asimov

repo: pulumi/pulumi-gcp


text:
UX Researcher: Creating Interview Script - Batch 1: Needs Around Alerts and Notifications

I am going to modify my base interview questions and scope them down to create an interview script for the interviews with our primary users: Jeremy and Allen.
This portion of the interview script will focus on user needs around alerts and notifications in the CMS #300
Feature: Create interview script for user interviews with Jeremy and Allen
  As a UX researcher
  I want to create an interview script from my list of interview questions crafted for the CMS UX that is catered to the role of the specific interviewee around understanding their needs around alerts and notifications in the CMS
  So that I can make sure to ask the interviewee specific questions that will be relevant to their role and their team

 Scenario: Craft interview script for Jeremy
    Given that Jeremy will be the main user entering marketing content into our CMS
     When I go to craft his interview script centered around his team's needs around alerts and notifications in the CMS
     Then I will be able to ask Jeremy the questions that will allow me to gather data to understand the marketing team's needs around alerts and notifications in our CMS
      And the cadence at which they prefer to receive alerts and notifications
      And the type of work they do that would benefit from having alerts and notifications
      And the different types of alerts and notifications they might need
      And the channels through which they would receive alerts and notifications
      And their preferences around configuring alerts and notifications

Scenario: Craft interview script for Allen
    Given that Allen will be the main user entering ID content into our CMS
     When I go to craft his interview script centered around his team's needs around alerts and notifications in the CMS
     Then I will be able to ask Allen the questions that will allow me to gather data to understand the ID team's needs around alerts and notifications in our CMS
      And the cadence at which they prefer to receive alerts and notifications
      And the type of work they do that would benefit from having alerts and notifications
      And the different types of alerts and notifications they might need
      And the channels through which they would receive alerts and notifications
      And their preferences around configuring alerts and notifications

Research Interview Script

[ ] Create interview script for Allen about needs around alerts and notifications
[ ] Create interview script for Jeremy about needs around alerts and notifications

Blocker to #423

@ineedsubstance @joshkimmell @poofichu @Snugug @scottnath @SirSpidey
And another creating interview script story

Link to interview script on Box: https://ibm.box.com/s/3qcrna0siatds3c9lme34ebm6k1i1yad

repo: punchcard-cms/punchcard


text:
Feature/reference

Content to Content Reference

Resolves #45
DCO 1.1 Signed-off-by: Ayush Gupta <ayush2k@gmail.com>

@Snugug @scottnath

I've looked over the whole thing. Great work. I think we could clean up a chunk of the logic if we moved up https://github.com/punchcard-cms/content-types/issues/83.

made identifier required to save: https://github.com/punchcard-cms/content-types/pull/94

@scottnath @Snugug updated

Please add a test for the return new Promise in utils.fill
In content type edit route, there are no tests for your new work. Please add some

Merged! Thanks for being awesome this summer @ayush2k! The remaining issues we'll work out later

authors: Snugug ayush2k scottnath


text:
Update package clean-css, because we had problems with shorthand

We had a problem with the clean-css with version 1.x, so i updated the package. Please review and check if you find some problems. Thx!
Example:
font: 500 2em/1.1 'DIN Condensed',Arial,sans-serif;

was this after the minify-process:
font: 400 500 2em/1.1 'DIN Condensed',Arial,sans-serif;

+1 :smile:

@stuartromanek @jsumnersmith @kyjoya @suhmantha1 would y'all please take a look at this pull request and make sure it doesn't cause any CSS problems (mostly looking for flat-out errors here) with a few of our fancier websites when Apostrophe is using this newer version of the cleancss package? I can see that the older version is missing support for a valid CSS construct, and I'd like to accept this pull request, but we need some due diligence here first. Thanks!

Closing because 0.5.x is in maintenance mode. Please use 2.x for new development. It uses a much newer release of clean-css.

authors: Vispercept boutell matthaias

repo: punkave/apostrophe

license: mit


text:
ArchLinux package is gone

The ArchLinux package Maintained by Niels Abspoel is gone the link responds with a 404.

What do you expect as an outcome? We currently don't maintain that package :smile:

@tuxinaut I added python2-puppetboard, python-pypuppetdb and python2-pypuppetdb to the AUR4 and will shortly move it into the official community repo.

Thank you for be the new maintainer for this package :+1:

authors: bastelfreak daenney tuxinaut

repo: puppet-community/puppetboard


text:
(maint) Pin to rubocop 0.50.0

Rubocop dropped support for Ruby 2.0 analysis, see commit
https://github.com/bbatsov/rubocop/commit/2f6f3f297cd957def22419d8d70a1afd9410e497.
Pin to rubocop 0.50.0, while fixing rubocop errors that occur with
0.51.0.

Talked this over with @pcarlisle, merging.

repo: puppetlabs/bolt


text:
Fix reference to unknown 'log' library in aggregate.rb

Describe the Bug
Line 115 of aggregate.rb tries to call 'log.warn', but 'log' is unknown, which breaks legacy builds.
Expected Behavior
Custom facts using legacy aggregate reference do not cause errors to be thrown during puppet install
Steps to Reproduce
Steps to reproduce the behavior:

Create new module with lib/facter/[customfact].rb that uses 'Facter.define_fact([name], type: :aggregate)' and 'define_resolution([name], type: :aggregate)
Run puppet

Environment

Version facter [4.7.0] puppet [8.6.0]
Platform [RHEL 8]

Additional Context

@personjs thanks for the bug report, we'll look into this.

This should be fixed in https://github.com/puppetlabs/facter/pull/2722/commits/00bc4db614a2d97331cf1210f8261f2d965d1e1f

Fixed in https://github.com/puppetlabs/facter/pull/2722/commits/707e8f928135613033af5b9248f60254c9d17d91

authors: cthorn42 joshcooper personjs

repo: puppetlabs/facter


text:
(maint) Update cmake URL but ignore certificate

cmake.org updated to redirect to HTTPS and use a shorter URL. However
the certificate they use requires validation from an SSL chain that's
not installed on Ubuntu 12.04. Since we were previously using HTTP, just
ignore the certificate for now while this is resolved.

Everything is terrible

authors: MikaelSmith branan


text:
Fix ifconfig parse logic failing on some tunnels

Tunnel interfaces that have a line similar to
"tunnel inet 192.0.2.1 --> 192.0.2.2" would fail the network resolver
because IPs were extracted through two separate IP + mask patterns.
However, in the example above, there is no such thing as a netmask.
This fix merges the patterns and extracts the IPs and netmasks
together so that no mismatches can occur. It might also fix some
cases where only the netmask would be nil and therefore produce an
invalid binding that could in turn resolve to the wrong (outer) IP of
the tunnel instead of the inner IP.

Can one of the admins verify this patch?

Hey @joshcooper, thanks for getting back to me!
I see your point and I have marked the tests as pending in the first commit, and unmarked them in the following one.
Please check one more time if this looks good to you now :)

Closing and reopening to trigger the right set of checks

Hey @joshcooper! To avoid further confusion and delays I have just merged the two commits into one and skipped the failing tests commit that was meant to demonstrate the failure. I have also rebased the branch once again. I hope that this way we can conclude this PR for good :)

authors: Woellchen joshcooper puppetlabs-jenkins


text:
Make code blocks scroll horizontally at >80 chars.

Add overflow-x: auto to pre code to enable horizontal scrolling.
Override deprecated word-wrap, supported overflow-wrap, and white-space to prevent line breaks in pre code.

lgtm

authors: gguillotte nfagerlund

repo: puppetlabs/puppet-docs-bootstrap


text:
(SERVER-653) Skip foreground test on RHEL5

The timeout command isn't available on RH5, so skip it

:+1:

repo: puppetlabs/puppet-server