text:
Clarifies several aspects of etcd that have caused confusion

Description

Clarifies that the production install for etcd requires an etcd data store set up in advance.
Provides link to coreos docs for instructions.
Also clarifies that the Quickstart is there as an alternative to the production install and does not require you to set up etcd in advance.
Clarifies that if you want to protect bare metal hosts, you cannot use the Kubernetes API datastore.
Also adds some notes in the install procedures in case people have missed this information which is there in the requirements and in the before you begin instructions: you need an etcd cluster to get through the procedure.

Todos

[ ] Tests
[ ] Documentation
[ ] Release note

Release Note

None required

Deploy preview for calico ready!
Built with commit a1e9294b76b0ffac3a30cf6697360f8e7140be6f
https://deploy-preview-2356--calico.netlify.com

source: gharchive/pull-request

authors: caseydavenport emanic

license_type: permissive

license_source: github-api


text:
dbc: polish the adb over DbC blog

Signed-off-by: Pandey, Prabhat Chand prabhat.chand.pandey@intel.com
Signed-off-by: Tonny Tzeng tonny.tzeng@intel.com
Reviewed-by: Kristi Rifenbark kristi@buzzcollectivemarketing.com

@klynnrif, @prabhatchand could you help to review this entire blog? the original PR was submitted by @prabhatchand , I merged that PR and re-format with this PR, so some of paragraphs may not be presented in the diff view. Thanks.

repo: projectceladon/celadon-documentation


text:
Unable to run with docker-compose

Attempting to run this locally using the specified docker-compose.yml on the v3.2.0 tag.
The changes I made
Dockerfile: ENV RAILS_ENV development
Dockerfile: RUN su app -c 'bundle install --without test'
docker-compose.yml: Removed env_file: .env-prod
Once the mongo and cypress containers start I run into errors where unicorn and the 4 delayed job works won't run with the following error: runsv unable to start ./run file does not exist. I checked the those run files do in fact exist in the context of those processes.

If you do not modify the docker-compose.yml file at all you will be able to run the application. You will need to create a .env-prod file with the following contents:
DEVISE_SECRET_KEY=<insert rails secret key there>
SECRET_KEY_BASE=<insert rails secret key there>

You can generate a rails secret key using the following command:
hexdump -n 64 -e '/1 "%02x"' -e '/64 "\n"' /dev/urandom
Also I would suggest using the following docker-compose.yml file so you do not have to go through the whole build process:
version: "3"

services:
  cypress:
    image: projectcypress/cypress:release-latest
    environment:
      - MONGO_PORT_27017_TCP_ADDR=mongodb
      - MONGO_PORT_27017_TCP_PORT=27017
    ports:
      - "3000:3000"
    links:
      - mongodb:mongo
    env_file: .env-prod
    restart: unless-stopped
  mongodb:
    image: mongo:3.4.5
    volumes:
      - /data/db
    restart: unless-stopped

Thank you for the response. I created the .env-prod file, but I'm still seeing the following.

Using projectcypress/cypress:release-latest is actually 3.2.0 so that should give you the version you desire.

I see that now. Thanks!

Just wanted to update...the problems I saw only existed with using docker toolbox on windows. Running on any flavor of linux and the docker-compose just works.

source: gharchive/issue

repo: projectcypress/cypress


text:
change match string for npm error message (using GUID)

the public test failed because somehow MadeUpKuduPackage is added to npm cache on kudu-ci machine. Adding a GUID to the madeUpPackageName should prevent it from matching any npm cache (if accident happened again)
I removed the old match string: "One or more of the selected node/npm paths do not exist." since this error message is return by kudu, not by npm install

:shipit:

authors: davidebbo watashiSHUN

repo: projectkudu/kudu

license_source: bigquery


text:
fix: lenth -> length

May be breaking sinc it is in trace message

Hi
If the problem persists and is related to running it on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service

Sorry, the message was not intended for pull requests.

authors: jvano nschonni


text:
Dapr sidecars not being added to docker compose

🔥 Bug Description
The docker-compose.yml produced for the AspireWithDapr sample doesn't include the sidecars. I get:
version: "3.8"
services:
  aspire-dashboard:
    container_name: "aspire-dashboard"
    image: "mcr.microsoft.com/dotnet/nightly/aspire-dashboard:8.0.0-preview.6"
    environment:
      DOTNET_DASHBOARD_UNSECURED_ALLOW_ANONYMOUS: "true"
    ports:
    - target: 18888
      published: 18888
    - target: 18889
      published: 4317
    restart: unless-stopped
  apiservice:
    container_name: "apiservice"
    image: "localhost:5001/nmr/apiservice:latest"
    environment:
      OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES: "true"
      OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES: "true"
      ASPNETCORE_FORWARDEDHEADERS_ENABLED: "true"
      OTEL_EXPORTER_OTLP_ENDPOINT: "http://aspire-dashboard:4317"
    ports:
    - target: 8080
      published: 10000
    - target: 8443
      published: 10001
    restart: unless-stopped
  webfrontend:
    container_name: "webfrontend"
    image: "localhost:5001/nmr/webfrontend:latest"
    environment:
      OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES: "true"
      OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES: "true"
      ASPNETCORE_FORWARDEDHEADERS_ENABLED: "true"
      OTEL_EXPORTER_OTLP_ENDPOINT: "http://aspire-dashboard:4317"
    ports:
    - target: 8080
      published: 10002
    - target: 8443
      published: 10003
    restart: unless-stopped

Adding the following got the example working:
  webfrontend-dapr:
    image: "daprio/daprd:latest"
    command: [
      "./daprd",
      "-app-id", "web",
      "-app-port", "8080"
    ]
    depends_on:
      - webfrontend
    network_mode: "service:webfrontend"

  apiservice-dapr:
    image: "daprio/daprd:latest"
    command: [
      "./daprd",
      "-app-id", "api",
      "-app-port", "8080"
    ]
    depends_on:
      - apiservice
    network_mode: "service:apiservice"

🔍 Steps to Reproduce the Bug

Clone the AspireWithDapr sample - https://github.com/dotnet/aspire-samples/tree/main/samples/AspireWithDapr
Run aspirate generate --output-format compose in .\AspireWithDapr\AspireWithDapr.AppHost\

Thanks - I'll take a look tomorrow

Fixed in version: https://github.com/prom3theu5/aspirational-manifests/tree/v0.7.7-preview
Its building / releasing now

license: MIT


text:
Prev/Next Links are strange

I am at the bottom of Compatibility
The prev/next links at the bottom are strange:

Yeah, that's because Compatibility is sourced from prometheus-operator and not from prologue. Seems like an issue in how we categorize pages.
Thanks for reporting this! If you have more issues regarding usage of prometheus-operator, join us on kubernetes slack in #prometheus-operator channel.

It seems to be fixed now

yes, I can confirm. Looks good now. Thank you!

authors: guettli paulfantom simonpasquier

repo: prometheus-operator/website


text:
Error on notify: context deadline exceeded

If I group my alerts in such a way that 4 alerts fall in a group I get following error:
ERRO[0300] Error on notify: context deadline exceeded    source=notify.go:152
ERRO[0300] Notify for 1 alerts failed: context deadline exceeded  source=dispatch.go:238
& if I modify grouping so that 1 group has one alert each, then thing move smoothly.
Please help to correct where I am wrong.
alertmanager.conf:
 group_by: ['severity', 'alertname', 'instance']
  group_wait: 1m
  group_interval: 5m
  repeat_interval: 30m
  receiver: alerta
  routes:
  - match_re:
      service: container
    receiver: mail
  - match:
      service: jira_chk
    receiver: JIRA

That seems highly unlikely to be related to the grouping. context deadline exceeded simply means the request timed out.
The error message shows that only one of the four alerts failed. So against your expectation the 4 alerts are not in the same group.
The most likely thing here is that notification requests to one of your receivers are timing out. Your configuration changes then cause no requests being sent to that receiver in the first place.
For further debugging we need the full configuration (before AND after) and the label sets of the four alerts.

Difference in old & new configuration is "group_by" & "repeat_interval" value
Old alertmanager.conf:
global:
  # The smarthost and SMTP sender used for mail notifications.
  smtp_smarthost: 'mailhostX:25'
  smtp_from: 'XYZ@ABC'

route:
  group_by: ['severity', 'alertname']
  group_wait: 1m
  group_interval: 5m
  repeat_interval: 333h
  receiver: alerta
  routes:
  - match_re:
      service: container
    receiver: mail
  - match:
      service: jira_chk
    receiver: JIRA

inhibit_rules:
- source_match:
    severity: 'low'
  target_match:
    severity: 'warning'
  # Apply inhibition if the alertname is the same.
  equal: ['alertname', 'cluster', 'service']

receivers:
- name: 'alerta'
  webhook_configs:
  - url: 'http://<IP>:8995/api/webhooks/prometheus'
    send_resolved: true

- name: 'mail'
  email_configs:
  - to: 'kk@ABC'
    send_resolved: true

- name: 'JIRA'
  webhook_configs:
  - url: 'http://<IP>:8955/issues/projects/LP'
    send_resolved: true

New alertmanager.conf:
global:
  # The smarthost and SMTP sender used for mail notifications.
  smtp_smarthost: 'mailhostX:25'
  smtp_from: 'XYZ@ABC'

route:
  group_by: ['severity', 'alertname', 'instance']
  group_wait: 1m
  group_interval: 5m
  repeat_interval: 30m
  receiver: alerta
  routes:
  - match_re:
      service: container
    receiver: mail
  - match:
      service: jira_chk
    receiver: JIRA

inhibit_rules:
- source_match:
    severity: 'low'
  target_match:
    severity: 'warning'
  # Apply inhibition if the alertname is the same.
  equal: ['alertname', 'cluster', 'service']

receivers:
- name: 'alerta'
  webhook_configs:
  - url: 'http://<IP>:8995/api/webhooks/prometheus'
    send_resolved: true

- name: 'mail'
  email_configs:
  - to: 'kk@ABC'
    send_resolved: true

- name: 'JIRA'
  webhook_configs:
  - url: 'http://<IP>:8955/issues/projects/LP'
    send_resolved: true

Complete Error:
ERRO[239100] Error on notify: context deadline exceeded    source=notify.go:152
ERRO[239100] Notify for 4 alerts failed: context deadline exceeded  source=dispatch.go:238
WARN[239100] Notify attempt 1 failed: Post http://:8955/issues/projects/LP: dial tcp :8955: getsockopt: connection refused  source=notify.go:193
ERRO[239101] Error on notify: context deadline exceeded    source=notify.go:152
ERRO[239101] Notify for 1 alerts failed: context deadline exceeded  source=dispatch.go:238
With old configuration: I have 5 alerts for jira_chk receiver; 4 in a group & 1 in other if

I am also facing the same issue. Does alertmanager retries fail notifications?

Here are my logs (using latest stable version - v0.3.0):
{"level":"warning","msg":"Notify attempt 2 failed: context deadline exceeded","source":"notify.go:193","time":"2016-08-04T03:02:01Z"}
{"level":"warning","msg":"Notify attempt 3 failed: context deadline exceeded","source":"notify.go:193","time":"2016-08-04T03:02:01Z"}
{"level":"error","msg":"Error on notify: context deadline exceeded","source":"notify.go:152","time":"2016-08-04T03:02:01Z"}
{"level":"error","msg":"Notify for 1 alerts failed: context deadline exceeded","source":"dispatch.go:238","time":"2016-08-04T03:02:01Z"}
{"level":"warning","msg":"Notify attempt 1 failed: Post https://events.pagerduty.com/generic/2010-04-15/create_event.json: dial tcp: lookup events.pagerduty.com on 10.14.0.2:53: read udp 10.14.22.55:44485-\u003e10.14.0.2:53: i/o timeout","source":"notify.go:193","time":"2016-08-04T03:02:02Z"}
{"level":"warning","msg":"Notify attempt 2 failed: context deadline exceeded","source":"notify.go:193","time":"2016-08-04T03:02:11Z"}
{"level":"warning","msg":"Notify attempt 3 failed: context deadline exceeded","source":"notify.go:193","time":"2016-08-04T03:02:11Z"}
{"level":"error","msg":"Error on notify: context deadline exceeded","source":"notify.go:152","time":"2016-08-04T03:02:11Z"}
{"level":"error","msg":"Notify for 1 alerts failed: context deadline exceeded","source":"dispatch.go:238","time":"2016-08-04T03:02:11Z"}
{"level":"warning","msg":"Notify attempt 1 failed: Post https://events.pagerduty.com/generic/2010-04-15/create_event.json: dial tcp: lookup events.pagerduty.com on 10.14.0.2:53: read udp 10.14.22.55:53401-\u003e10.14.0.2:53: i/o timeout","source":"notify.go:193","time":"2016-08-04T03:02:12Z"}
{"level":"warning","msg":"Notify attempt 2 failed: context deadline exceeded","source":"notify.go:193","time":"2016-08-04T03:02:21Z"}
{"level":"warning","msg":"Notify attempt 3 failed: context deadline exceeded","source":"notify.go:193","time":"2016-08-04T03:02:21Z"}
{"level":"error","msg":"Error on notify: context deadline exceeded","source":"notify.go:152","time":"2016-08-04T03:02:21Z"}
{"level":"error","msg":"Notify for 1 alerts failed: context deadline exceeded","source":"dispatch.go:238","time":"2016-08-04T03:02:21Z"}
{"level":"warning","msg":"Notify attempt 1 failed: Post https://events.pagerduty.com/generic/2010-04-15/create_event.json: dial tcp: lookup events.pagerduty.com on 10.14.0.2:53: read udp 10.14.22.55:47474-\u003e10.14.0.2:53: i/o timeout","source":"notify.go:193","time":"2016-08-04T03:02:22Z"}

@rohit01 yes, Alertmanager retries failed notifications. However, only up until the timeout. Timeout of sends themselves is not a retry condition as it would defeat its purpose.

@rohit01 could you share your configuration as well? Did it also happened after you changed something or was it there from the beginning?

It started happening automatically one day without any config change. All of a sudden, we stopped getting any alerts. Did random things like restart container, minor config changes and it started working again with intermittent failures.
We were on version 01.0, we tried 0.1.1 and finally moved to v0.3.0 (yesterday).
Here's the configuration:
global:
  # The smarthost and SMTP sender used for mail notifications.
  smtp_smarthost: '****'
  smtp_from: '****'

# The root route on which each incoming alert enters.
route:
  # The labels by which incoming alerts are grouped together. For example,
  # multiple alerts coming in for cluster=A and alertname=LatencyHigh would
  # be batched into a single group.
  group_by: ['severity', 'alertname', 'instance', 'job']

  # When a new group of alerts is created by an incoming alert, wait at
  # least 'group_wait' to send the initial notification.
  # This way ensures that you get multiple alerts for the same group that start
  # firing shortly after another are batched together on the first
  # notification.
  group_wait: 3s

  # When the first notification was sent, wait 'group_interval' to send a batch
  # of new alerts that started firing for that group.
  group_interval: 3s

  # If an alert has successfully been sent, wait 'repeat_interval' to
  # resend them.
  repeat_interval: 3h

  # A default receiver
  receiver: 'notifications'

  # All the above attributes are inherited by all child routes and can
  # overwritten on each.

  # The child route trees.
  routes:
  # This routes performs a regular expression match on alert labels to
  # catch alerts that are related to a list of services.
    - match_re:
        severity: ^(critical|warning)$
      receiver: 'notifications'
      # Child Routes (having greater precedence)
      routes:
      - match:
          severity: critical
        receiver: 'notifications-and-pagerduty'

# Inhibition rules allow to mute a set of alerts given that another alert is
# firing.
# We use this to mute any warning-level notifications if the same alert is
# already critical.
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    # Apply inhibition if the following matches.
    equal: ['CITY', 'SERVICE', 'instance']

  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    # Apply inhibition if the following matches.
    equal: ['alertname', 'instance', 'job']

receivers:
  - name: 'notifications'
    # Send email
    email_configs:
      - to: '<email 1>'
        require_tls: false
      - to: '<email 2>'
        require_tls: false

  - name: 'notifications-and-pagerduty'
    # Trigger pagerduty
    pagerduty_configs:
      - service_key: <hidden>
    # Send email
    email_configs:
      - to: '<email 1>'
        require_tls: false
      - to: '<email 2>'
        require_tls: false

This is worrying as it's two cases. But OTOH in both cases the error messages indicate a timeout when sending the notification (not anywhere in our code before or after). So I'm wondering if it's just an unlucky coincidence.
Have you verified whether you can curl the respective notification endpoint (PagerDuty in your case @rohit01) within the timeout?

@fabxc What is the timeout value?
Unable to find in code.

@rohit01 I was not quite precise earlier.
The general timeout is the grouping interval, which you can think of the "update frequency" for a group of alerts. You have set yours very low, it should generally be at the order of 1 minute or more as it is meant to avoid getting spammed. PagerDuty for that matter will not even page you again and has issues updating the data (last time I checked). So there's no value in having it that low here.
It also means your effective request timeout to PagerDuty is only 3 seconds.
The timeout is assigned here: https://github.com/prometheus/alertmanager/blob/7b20b776eaca8ceeac09eff0187222fe317b2ec2/dispatch.go#L314-L316
Now for your error logs on the failed retry attempts. This seems to be an issue here:
https://github.com/prometheus/alertmanager/blob/master/notify/notify.go#L191-L199
We retry notification with backoff based on a ticker. We attempt to receive a signal from that ticker, but want to abort that if the context timed out. In the code we just do a plain select over both signals, the choice is random.
If we retry with a timed out context, the notification immediately fails. The code should check the context first before then waiting on whatever signal appears first.
Does that make sense? So your problem would most likely disappear if you set group_interval to a value of 3-5 minutes.
Sorry about addressing your issue super late, @kavyakul. Your error logs also simply indicates a failure to reach the notification endpoint:  dial tcp :8955: getsockopt: connection refused. Have you checked whether you can manually curl it from the Alertmanager host?

@fabxc Thanks for the explanation. We were running with group_interval as 1s as well. Now, I think we know the reason for our pain :)

Yes, I suppose we could think about making changes to have a timeout larger than group_interval to allow for "immediate updates". But I believe this at best enables self harm for users and cannot see any practical value.
@brian-brazil what's your opinion?

I'd not consider any group interval under a minute to be sane. I think our current behaviour is fine.
If you want some form of automated action faster than that, then you want a dedicated realtime control system because humans can't respond that fast.

Hi
I have similar issue.
Getting context deadline exceeded and also I can able to curl the endpoint from alert manager host
here is my alert rules config:
alert.rules
groups:

name: sample
rules:

alert: prometheus_remote_storage_succeeded_samples_total_alert
expr: sum(prometheus_remote_storage_succeeded_samples_total{instance="prometheus:9090"}) == 0
for: 30s
labels:
severity: warning
annotations:
summary: Instance {{ $labels.instance }} cannot store sample to remote storage

name: sample1
rules:

alert: sample_alert
expr: testmetric == 0
labels:
severity: warning
instance: i1
annotations:
summary: this is sample summary for {{ $labels.instance }}

alertmanager.yaml
global:
resolve_timeout: 5m
route:
group_by: ['instance']
group_wait: 1m
group_interval: 1m
repeat_interval: 1h
receiver: 'web.hook'
receivers:

name: 'web.hook'
webhook_configs:

url : http://json-server.2304650011.svc:3030/EspServiceRequest/

Alert:
See Attachment
Can connect to endpoint:
sh-4.2# curl -v http://json-server.2304650011.svc:3030/EspServiceRequest/

About to connect() to json-server.2304650011.svc port 3030 (#0)
Trying 192.168.81.205...
Connected to json-server.2304650011.svc (192.168.81.205) port 3030 (#0)

GET /EspServiceRequest/ HTTP/1.1
User-Agent: curl/7.29.0
Host: json-server.2304650011.svc:3030
Accept: /

Error:
level=error ts=2018-09-19T23:31:48.278890325Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded"
level=error ts=2018-09-19T23:31:48.278990617Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded"
level=error ts=2018-09-19T23:31:58.279279537Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded"
level=error ts=2018-09-19T23:31:58.279346534Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded"
Could you please let me know for any solution for this.
Regards,
Keshav Sharma

also having the same solution here
My alertmanager and prometheus are both in a kubernetes cluster. And using helm with the stable/prometheus chart.
here is my configuration for alertmanager.
`alertmanagerFiles:
alertmanager.yml:
global:
resolve_timeout: 1h
slack_api_url: 'https://hooks.slack.com/services/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'
route:
  group_by: ['instance','alertname']
  group_wait: 1s
  group_interval: 3m
  receiver: ea_sspc
  repeat_interval: 30m

receivers:
  - name: 'ea_sspc'
    slack_configs:
      - channel: 'viper-lab-sspc'
        send_resolved: false
        text: 'Test device Selenium/Appium is down, please SSH and restart'`

and here are the logs
level=info ts=2018-10-25T23:10:17.313219036Z caller=cluster.go:587 component=cluster msg="gossip settled; proceeding" elapsed=10.000852659s level=error ts=2018-10-25T23:17:19.970316317Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.970394998Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.987694626Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.987740048Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded"

also having the same solution here
My alertmanager and prometheus are both in a kubernetes cluster. And using helm with the stable/prometheus chart.
here is my configuration for alertmanager.
alertmanagerFiles:
  alertmanager.yml:
    global:
      resolve_timeout: 1h
      slack_api_url: <secret>

    route:
      group_by: ['instance','alertname']
      group_wait: 1s
      group_interval: 3m
      receiver: ea_sspc
      repeat_interval: 30m

    receivers:
      - name: 'ea_sspc'
        slack_configs:
          - channel: 'viper-lab-sspc'
            send_resolved: false
            text: 'Test device Selenium/Appium is down, please SSH and restart'

and here are the logs
level=info ts=2018-10-25T23:10:17.313219036Z caller=cluster.go:587 component=cluster msg="gossip settled; proceeding" elapsed=10.000852659s level=error ts=2018-10-25T23:17:19.970316317Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.970394998Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.987694626Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.987740048Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded"

also having the same solution here
My alertmanager and prometheus are both in a kubernetes cluster. And using helm with the stable/prometheus chart.
here is my configuration for alertmanager.
alertmanagerFiles:
  alertmanager.yml:
    global:
      resolve_timeout: 1h
      slack_api_url: <secret>

    route:
      group_by: ['instance','alertname']
      group_wait: 1s
      group_interval: 3m
      receiver: ea_sspc
      repeat_interval: 30m

    receivers:
      - name: 'ea_sspc'
        slack_configs:
          - channel: '@me'
            send_resolved: false
            text: 'Test device Selenium/Appium is down, please SSH and restart'

and here are the logs
level=info ts=2018-10-25T23:10:17.313219036Z caller=cluster.go:587 component=cluster msg="gossip settled; proceeding" elapsed=10.000852659s level=error ts=2018-10-25T23:17:19.970316317Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.970394998Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.987694626Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.987740048Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded"

also having the same solution here
My alertmanager and prometheus are both in a kubernetes cluster. And using helm with the stable/prometheus chart.
here is my configuration for alertmanager.
alertmanagerFiles:
  alertmanager.yml:
    global:
      resolve_timeout: 1h
      slack_api_url: <secret>

    route:
      group_by: ['instance','alertname']
      group_wait: 1s
      group_interval: 3m
      receiver: default
      repeat_interval: 30m

    receivers:
      - name: 'default'
        slack_configs:
          - channel: '@me'
            send_resolved: false
            text: 'Test device Selenium/Appium is down, please SSH and restart'

and here are the logs
level=info ts=2018-10-25T23:10:17.313219036Z caller=cluster.go:587 component=cluster msg="gossip settled; proceeding" elapsed=10.000852659s level=error ts=2018-10-25T23:17:19.970316317Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.970394998Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.987694626Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.987740048Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded"

also having the same solution here
My alertmanager and prometheus are both in a kubernetes cluster. And using helm with the stable/prometheus chart.
here is my configuration for alertmanager.
alertmanagerFiles:
  alertmanager.yml:
    global:
      resolve_timeout: 1h
      slack_api_url: <secret>

    route:
      group_by: ['instance','alertname']
      group_wait: 1s
      group_interval: 3m
      receiver: default
      repeat_interval: 30m

    receivers:
      - name: 'default'
        slack_configs:
          - channel: '@me'
            send_resolved: false
            text: 'text'

and here are the logs
level=info ts=2018-10-25T23:10:17.313219036Z caller=cluster.go:587 component=cluster msg="gossip settled; proceeding" elapsed=10.000852659s level=error ts=2018-10-25T23:17:19.970316317Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.970394998Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.987694626Z caller=notify.go:332 component=dispatcher msg="Error on notify" err="context deadline exceeded" level=error ts=2018-10-25T23:17:19.987740048Z caller=dispatch.go:280 component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="context deadline exceeded"

authors: Keshav0690 brian-brazil brummetj fabxc kavyakul rohit01

repo: prometheus/alertmanager


text:
Allow adding arbitrary labels to metrics when generating output

It's useful to be able to apply a label across all metrics, for
example when using a multi-processing framework to apply a
label for worker ID to all metrics (including from builtin
collector types). This change adds a new Registry type that
applies a dictionary of labels when metrics are collected.
Signed-off-by: Will Newton will.newton@gmail.com

@csmarchbanks I'm a little confused by your comment, since the Python client doesn't seem to have the concept of a Registerer like the Golang client. Is the idea that we would create a wrapper class that contains a Registry which augments the labels of a collector when .register() is called? Then we could make multiple wrappers that add different labels, and they could all reference the same registry.

I can imagine a few implementations that would be acceptable, but my guess is that we will have a new class that inherits from CollectorRegistry but overrides collect() to add the labels to each metric as they are yielded rather than adding labels to the collectors. You could then do something like:
REGISTRY.register(labeled_registry)

to add all of the labeled metrics to the default registry or any other registry. Does that make sense?

authors: Sircular csmarchbanks willnewton


text:
Provide docker image of wasm

Proposal
Now docker has gradually supported the virtual machine deployment of wasm. It is hoped that prometheus can experimentally support this deployment method.

Because of Prometheus's extensive use of the local filesystem, my understanding is that it would prohibitively difficult to compile it to wasm.

Because of Prometheus's extensive use of the local filesystem, my understanding is that it would prohibitively difficult to compile it to wasm.

Now wasm runtime has wasmrime wasmage wasmer, etc., and support for local files is gradually improving. I think this plan can indeed be considered

WASI on top of WASM is the common system level interface, however it does not currently support mmap -- mmap is pretty crucial for Prometheus (although it could be worked around, but the performance and reliability may suffer, so I'm not sure it would be worth it).
It might be interesting to experiment with compiling parts of Prometheus to WASM before we provided a Docker image, for example running promtool unit tests in a browser could provide some nice benefits.

Prometheus compiles to wasm already but does not work as we do nothing for mmap.

authors: Avey777 LeviHarrison dgl roidelapluie

repo: prometheus/prometheus


text:
React UI: Alert filters are not remembered

What did you do?
Hide inactive alerts on /new/alerts.
What did you expect to see?
When hiding inactive alerts, I expect them to stay hidden after going another page and back to /new/alerts, or refreshing. Just like the current behaviour on the /alerts page
What did you see instead? Under which circumstances?
Revisiting the React UI /new/alerts page will have all three options enabled again.
Environment
Ubuntu 18.04 LTS, cloudalchemy.prometheus ansible role. Binaries come from github.

System information:

Linux 5.0.0-1035-azure x86_64

Prometheus version:

prometheus, version 2.18.1 (branch: HEAD, revision: ecee9c8abfd118f139014cb1b174b08db3f342cf)
  build user:       root@2117a9e64a7e
  build date:       20200507-16:51:47
  go version:       go1.14.2

Alertmanager version:
Not relevant to the issue

Prometheus configuration file:
Not relevant to the issue

Alertmanager configuration file:
Not relevant to the issue

Logs:
Not relevant to the issue

Note: This also goes for the Show annotations option in the React UI on the /new/alerts page

I'm interested in working on this issue.

authors: licarpen vosdev


text:
Fix IPv6 scraping

Fixes #1944 and #914
@w0mbat @jimmidyson @juliusv

Okay, I hope this is good now. Can I have a final look? @jimmidyson @brancz, Julius is on vacation.

LGTM

authors: brancz fabxc


text:
storage: optimize dropping chunks by using minShrinkRatio

If minShrinkRatio > 0, I think we can skip to read the beginning part of chunks, because, we are interested with the chunk index which satisfy minShrinkRatio, not first chunk index before beforeTime.

@beorn7
After discussing about storage code in https://github.com/prometheus/prometheus/issues/2384, I notice that we can use another optimization method.
This is the my proposal. Please review this.

Thanks for review!
I fixed!!

Thanks again.


text:
Add support for POSTing to /series endpoint

Closes #5417
The ParseForm() method in net/http supports url-encoded parameters in the request body if the method is POST, with a built-in 10 MB limit.
This change should mitigate issues where a user runs into query string length limits when providing a large number of selectors using the GET method inline in the URL query string.

maybe need modify web/api/v1/api_test.go L838, support POST unit test for series endpoint.

LGTM

I was going to suggest adding POST support to the query endpoints for https://github.com/prometheus/client_golang/issues/428, but it looks like that was already implemented. Instead, I've just updated the API documentation instead.

Thanks!

authors: bobmshannon brian-brazil eahydra


text:
fallback mocha to the previous version since ts-mocha required v8

With the codemirror synchronization (https://github.com/prometheus/codemirror-promql/pull/163) , I just noticed dependabot made a mistake by increasing the version of mocha. ts-mocha required the v8 and cannot work with the v8.
In prometheus I look at the deps installed and actually there are two mocha versions installed (the v8 and the v9). So I suspect that it used actually the v8 and not the v9.
Signed-off-by: Augustin Husson husson.augustin@gmail.com

Why was CI successful?

that's what I tried to explain.
in the prometheus CI, you still have the version v8 of mocha installed probably coming from another inner dependency. So ts-mocha is happy since it has the version to work with. Even if there is another version installed at the same time.
WIth the npm workspaces, you can have different version used by the different npm woir involved. That's why we tried to align the version across the different npm workspaces. Unfortunately it's not always possible specially when you are depending of react-script which blocks many possible update.
When you move to prometheus/codemirror, well you just have this repo involved it's not anymore a npm workspaces, so the dependency written in the pakcage.json are only the one used.
I hope it answer the question.

Thanks for the explanation, I get it now.

authors: Nexucis roidelapluie


text:
Use new version format in release names

The version format has been changed to include a v prefix. Should we include this in directory and tarball names for consistency?
@fabxc @sdurrheimer

I'm fine with both, with or without the v. We just need to keep in mind this change might hurt peoples automation scripts :).

The applied rename already hurt ours. We have VERSION variables in all our
makefiles, we now need to append a v depending on the context.
On Tue, Jul 19, 2016 at 2:08 AM, Steve Durrheimer notifications@github.com
wrote:

I'm fine with both, with or without the v. We just need to keep in mind
this change might hurt peoples automation scripts :).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/prometheus/promu/issues/33#issuecomment-233540841,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAANaGdBiZjh8n0RRnUFKmO8PJ0x4SNBks5qXGn3gaJpZM4JPV-z
.

I don't think we need it in the tarball. It is natural to have the version number in the form we have. Tags, however, can be anything, not just versions. That's the rationale of having the v prefix, essentially namespacing. That doesn't apply to the directory and tarball name.

authors: beorn7 grobie sdurrheimer

repo: prometheus/promu


text:
go build should run from within the binary directory

With go modules the build needs to happen in the module directory so that the build process uses the go.mod file within that module directory.
When a module has its own go.mod file in its root directory go build withing that dir will use it otherwise it walks the parent dirs and uses the first go.mod it finds. This change keeps backwards compatibility for all existing setups, but also allows tools with their own go.mod within their own dir.

hm, it seems that promu is designed to build by a remote path even without the source doe present so need to think a bit how to handle this.

I wouldn't have time to finish this and add proper tests anytime soon so closing for now.


text:
Implement new "dsl_ode_trigger_count_range_get/set" services

New Get/Set services to complete the Count Trigger
/**
 * @brief Gets the current minimum and maximum count settings in use
 * by the named Count Trigger
 * @param[in] name unique name of the Count Trigger to query
 * @param[out] minimum the current minimum count for triggering ODE occurrence, 0 = no minimum
 * @param[out] maximum the current maximum count for triggering ODE occurrence, 0 = no maximum
 * @return DSL_RESULT_SUCCESS on successful query, DSL_RESULT_ODE_TRIGGER_RESULT otherwise.
 */
DslReturnType dsl_ode_trigger_count_range_get(const wchar_t* name,
    uint* minimum, uint* maximum);

/**
 * @brief Sets the minimum and maximum count settings to use for a
 * named Count Trigger
 * @param[in] name unique name of the Count Trigger to update
 * @param[in] minimum the new minimum count for triggering ODE occurrence, 0 = no minimum
 * @param[in] maximum the new maximum count for triggering ODE occurrence, 0 = no maximum
 * @return DSL_RESULT_SUCCESS on successful update, DSL_RESULT_ODE_TRIGGER_RESULT otherwise.
 */
DslReturnType dsl_ode_trigger_count_range_set(const wchar_t* name,
    uint minimum, uint maximum);

Merged into v0.14.alpha


text:
Update license string in setup.py

This updates the license string in setup.py to 'BSD License' to match the project's license. This will update the license displayed on the PyPi project page whenever the package metadata is rescanned. This change will allow for automatic license validation.

Thank you! I'll try to publish a new PyPI release soon.

authors: jdtemplet jonathanslenders

repo: prompt-toolkit/pyvim


text:
Multiple Schema SQL Server Reverse Engineer Problem

There is a same bug that exists in Propel 1 when you are trying to reverse engineer MS SQL Server database with multiple schema.
I was using dev-master (currently after 2.0.0-alpha8). Correction is made in the file vendor\propel\propel\src\Propel\Generator\Reverse\ (assumming you’re using composer).
I posted the correction in the following gist, changes commented by me (Abah):
https://gist.github.com/donnyfauzan/fcdfeccb2374f37857c28d0cb4010b23

Is this still relevant or can it be closed?

The bug occured in the  2.0.0-alpha8 release. Reviewing the code today, looks like some refactoring was done. I haven't got time to recheck if the problem still exists, so I think we can close the issue for now. If later on the bug still persists, i will open a new issue.

authors: dereuromark donnyfauzan zaunaf

license: mit


text:
Update file paths relative to input path

This PR adds attribute absolute_path to JSON report. Also makes  source, scanned_files, and skipped_files fields, with file paths relative to the input path as outlined in #101.
Closes #101
Sample scan output with input path referring to a file. The model scanned is generated using XGBoost notebook.
{
    "summary": {
        "total_issues_by_severity": {
            "LOW": 0,
            "MEDIUM": 0,
            "HIGH": 0,
            "CRITICAL": 1
        },
        "total_issues": 1,
        "input_path": "notebooks/XGboostModels/unsafe_model.pkl",
        "absolute_path": "/Users/mehrinkiani/Documents/modelscan/notebooks/XGboostModels",
        "modelscan_version": "0.0.0",
        "timestamp": "2024-02-09T17:25:29.623039",
        "skipped": {
            "total_skipped": 0,
            "skipped_files": []
        },
        "scanned": {
            "total_scanned": 1,
            "scanned_files": [
                "unsafe_model.pkl"
            ]
        }
    },
    "issues": [
        {
            "description": "Use of unsafe operator 'system' from module 'posix'",
            "operator": "system",
            "module": "posix",
            "source": "unsafe_model.pkl",
            "scanner": "modelscan.scanners.PickleUnsafeOpScan",
            "severity": "CRITICAL"
        }
    ],
    "errors": []
}

Sample scan output with input path referring to a directory. The model scanned is generated using Pytorch notebook
{
    "summary": {
        "total_issues_by_severity": {
            "LOW": 0,
            "MEDIUM": 0,
            "HIGH": 0,
            "CRITICAL": 1
        },
        "total_issues": 1,
        "input_path": "notebooks/PyTorchModels",
        "absolute_path": "/Users/mehrinkiani/Documents/modelscan/notebooks/PyTorchModels",
        "modelscan_version": "0.0.0",
        "timestamp": "2024-02-09T17:24:11.058155",
        "skipped": {
            "total_skipped": 0,
            "skipped_files": []
        },
        "scanned": {
            "total_scanned": 2,
            "scanned_files": [
                "safe_model.pt:safe_model/data.pkl",
                "unsafe_model.pt:unsafe_model/data.pkl"
            ]
        }
    },
    "issues": [
        {
            "description": "Use of unsafe operator 'system' from module 'posix'",
            "operator": "system",
            "module": "posix",
            "source": "unsafe_model.pt:unsafe_model/data.pkl",
            "scanner": "modelscan.scanners.PickleUnsafeOpScan",
            "severity": "CRITICAL"
        }
    ],
    "errors": []
}

Thank you @willarmiros. The detailed description in the issue was helpful!
The colon in the path is used when ModelScan scans a zipped file (code reference). In the second sample output, the files safe.pt and unsafe.pt are zipped files and when unzipped, the particular file scanned is data.pkl

@mehrinkiani that makes sense, sounds good and thanks for explaining!

authors: mehrinkiani willarmiros

repo: protectai/modelscan


text:
🛑 status.filecoin.io is down

In 9c4b46d, status.filecoin.io (https://status.filecoin.io) was down:

HTTP code: 418
Response time: 212 ms

Resolved: status.filecoin.io is back up in 70c9efd after 8 minutes.

repo: protocol/upptime-pln


text:
🛑 trusted-setup-snapdeals.filecoin.io is down

In be9a22b, trusted-setup-snapdeals.filecoin.io (https://trusted-setup-snapdeals.filecoin.io) was down:

HTTP code: 0
Response time: 0 ms

Resolved: trusted-setup-snapdeals.filecoin.io is back up in 3e63164 after 6 minutes.


text:
could not determine GOARCH and Go compiler

I have the gocyto bash file in my gocyto directory. From that directory, I was using the following command:
./gocyto --out test.html directory-of-my-package
I got the error "failed packages load: could not determine GOARCH and Go compiler". When I checked for go env, I found that I have the following:
GOARCH="amd64"
GCCGO="gccgo"

For macos, I had to build and install myself:
git clone git clone https://github.com/protolambda/gocyto.git /tmp/gocyto
pushd /tmp/gocyto

go build && go install

popd

Now I get panic: pointer analysis failed no main/test packages to analyze (check $GOROOT/$GOPATH), so checking out #7

i also meet this error.

authors: NickLarsenNZ Shahanewaz soluty

repo: protolambda/gocyto


text:
issue#1666 - add profile for only api build

Closes #1666: request: a command to compile just kafka-ui-api, ignoring the frontend

What changes did you make?
Created a profile to build only the api. To build only the api this command is used:
cd kafka-ui-api
 ./mvnw compile -Papi-prod

Is there anything you'd like reviewers to focus on?
Nope.
How Has This Been Tested?

[x] No need to
[X] Manually - I made the build from the command line
[x] Unit checks
[x] Integration checks
[x] Covered by existing automation

Checklist

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation (e.g. ENVIRONMENT VARIABLES)
[x] My changes generate no new warnings (e.g. Sonar is happy)
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged

Check out Contributing and Code of Conduct
A picture of a cute animal (not mandatory but encouraged)

@Corlobin Hey, thanks for your contribution!

authors: Corlobin Haarolean

repo: provectus/kafka-ui


text:
update cosmos sdk to 0.42.4

Description
Updates cosmos sdk to 0.42.4 as a non-breaking change to the v1.0.x release.
closes: #235

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

While there are broken tests in this PR due to the SDK upstream changing the way GRPC error codes are tagged, I am not planning to fix these tests because this is destined for a revision level point release and we need to keep the changes to an absolute minimum.

repo: provenance-io/provenance


text:
how to convert a HF Diffusers saved pipeline to a Stable Diffusion checkpoint?

I wanna to convert the current UNet, VAE, scheduler, tokenizer and Text Encoder diffusers model structure to a single safetensors checkpoint file then i can load in comfyUI,any advice or solution?

Is this a joke...? Uhm YES there is a comfyui solution, LOL
https://github.com/kijai/ComfyUI-Marigold

authors: LastTargaryen frankchieng

repo: prs-eth/Marigold


text:
Unable to login, authorization redirects to bsky.social's landing page

Typing in my handle (maxfz.xyz) and clicking login sends me to the authorization process like expected, but clicking accept redirects me to https://bsky.social/about instead of back to picosky. Going back to picosky after that doesn't show me as logged in.

Tried to log in with my DID, results in the same behavior

no idea how this could be happening, i havent changed anything
can you confirm to me you are logging through bsky.social and it originated from psky.social

https://github.com/user-attachments/assets/cfec8acb-e9fc-42e7-a108-7bf48d748f80

ngl i have no idea how this could be happening
ill look into it but i cant reproduce it on any of my accounts

is it possible to have request logs with "persist logs" turned on so it doesn't wipe on page navigation

Do you have any privacy-related browser extensions installed?

@notjuliet:
https://github.com/user-attachments/assets/8319945d-fc52-493e-b6cd-37f46f1c6ddc
@DavidBuchanan314:
i do have uBlock Origin and Privacy Badger, i'll try disabling those

i'm pretty sure this is a firefox issue? managed to "fix" by signing in on chrome and copying the app's localStorage over. after looking at the requests, it seems having a redirect with a url in the query portion (e.g. ?iss=https://bsky.social for oauth) causes that url to take precedence somehow?

found the issue in one of my addons, "Skip Redirect", and fixed it by adding a whitelist rule for ://psky.social

authors: DavidBuchanan314 maxfzz notjuliet

repo: psky-atp/client


text:
Use testinfo.desc

Instead of Makefile use testinfo.desc which has variables resolved.

Fixes #131

/packit test

Merged in 3dff02a after a couple of adjustments in 878b19d. Thanks for the improvement!

authors: hegerj psss

repo: psss/tmt


text:
Release Tasks

[ ] Use rails console to update all candidate_numbers to strings, zero padded, with 12 digits before release
[ ] #820

Plan to release September 5th

Cron workflows are on hold for now: https://github.com/psu-libraries/etda-config/pull/113


text:
How we are creating Agents for logged in users is a bit scary

When looking into showing the email and login for the logged in user in the new work form (refs #1453)
We ran into this code: https://github.com/psu-stewardship/scholarsphere/blob/develop/app/services/alias_management_service.rb#L61-L63
We are using this to create the agents for a logged in user.  That means for a user who we know the login and email, we are still using the name to differentiate the person.

Verify this is addressed by #1453

repo: psu-stewardship/scholarsphere


text:
500 Error for draft work resources

When requesting the uuid for a Work that is still in draft, i.e. it has only one version and that version is in draft status, we're getting a 500 error:
ActionView::Template::Error: undefined local variable or method `model_name' for #NullWorkVersion:0x00007fc0943c84d8
Similar to #714

@awead @srerickson We need to decide what the desired behavior is. When a user hits a resource page for a Work that is not yet published, what should happen?

My preference is 404.

@srerickson Even if they're an admin? They'd still be able to view the work version page, via the dashboard.

Yes, let's do 404 for all cases.

authors: awead rschenk srerickson


text:
some fixes I made so that templates.js would not crash on the client side

Got this error on Chrome, and only on the disney branch:
Uncaught DataCloneError: An object could not be cloned.
Related:

http://www.nowherenearithaca.com/2013/07/solved-chrome-web-workers-and.html
https://github.com/csantanapr/dapp-examples/issues/31

So I fixed it :shipit:
As for wrapping callbacks[e.data.signature] in a conditional, I was getting undefined is not a function errors as well... there's probably an underlying issue for that, but this works as a bandaid.

I see why it errored out, we're passing click functions when we parse alerts. This fixes it thanks :+1:

authors: julianlam psychobunny


text:
Add django-sslserver to development settings

https://github.com/teddziuba/django-sslserver
Gives the ability to use runserver with a self-signed ssl certificate, useful for some project cases where SSL is needed to use certain feature of the browser.

@pslobo what do you think?? seems useful do me..
@kapz how does the certificate generation work? it has to be manual??

@psychok7 the certification is generated automatically on the first run of runsslserver

I like the idea, will test it myself for a while and if it panes out i don't see why we shouldn't add to the project

@psychok7 Looks interesting indeed. This combined with Certbot container means full SSL support from dev to staging and production.

authors: kapz pslobo psychok7


text:
Spinner is not being removed from the terminal

I'm facing a problem using the pterm in our CLI, sometimes the spinner is not being removed from the terminal, as you can see below ("Getting plan...").
I've noticed that when we set "spinner.Success() or spinner.Fail()", it should clear the line in the terminal, but sometimes it doesn't work, apparently

Hi, this is the docs repo 😉
I'll move the issue to the main repo.

repo: pterm/docs


text:
Add RandomBigCat API

Add RandomBigCat API

[x] My submission is formatted according to the guidelines in the contributing guide
[x] My addition is ordered alphabetically
[x] My submission has a useful description
[x] The description does not have more than 100 characters
[x] The description does not end with punctuation
[x] Each table column is padded with one space on either side
[x] I have searched the repository for any relevant issues or pull requests
[x] Any category I am creating has the minimum requirement of 3 items
[x] All changes have been squashed into a single commit

Thank you!

authors: marcelscruz mossieur

repo: public-apis-dev/public-apis


text:
Added API of Audiomack

[x] My submission is formatted according to the guidelines in the contributing guide
[x] My addition is ordered alphabetically
[x] My submission has a useful description
[x] The description does not end with punctuation
[x] Each table column is padded with one space on either side
[x] I have searched the repository for any relevant issues or pull requests
[x] Any category I am creating has the minimum requirement of 3 items
[x] All changes have been [squashed][squash-link] into a single commit

Thanks for the contribution @Nirzak!
Does the API have a free-tier plan, please? I couldn't find anywhere if the API can be used for free.

Thanks for the contribution @Nirzak!
Does the API have a free-tier plan, please? I couldn't find anywhere if the API can be used for free.

Yes audiomack API is free. https://public-apis.io/audiomack-api you can the info from here

authors: Nirzak marekdano

repo: public-apis/public-apis


text:
Logout

What's the right way to logout the user? Explicitly expire the oidc_id_token cookie?

Good question.
Assuming a cooperative browser, yes. This would be appropriate for a logout link. Note that because of the way OpenID works, the user will simply be logged back in next time they visit the site, unless they also log out of the IdP as well (see the "single sign-out problem").
If this isn't desired behavior, you can force the user to go through the IdP again:

Modify the cookie validation code to always check for stored credentials under that sub (OpenID subject).
Delete a user's credentials from the credentials store when they log out.

Assuming a hostile/defective browser or stolen cookie, that alone won't do it, because a browser or other user agent could ignore cookie expiration and retain the cookie. It'll eventually stop working when the signed expiration time passes, but can be used until then. So we'd need to implement something suitable for a "log me out everywhere" scenario.
Some possibilities to deal with this:

Store a counter in the token cookie and in the credential store. Always check the cookie's counter value when validating the cookie. When a user logs out, increment the stored counter. Now cookies generated before the logout are invalid.
Every time a new cookie is generated, also generate a unique ID. Store it in the cookie and in the credential store. Always check the cookie's unique ID when validating the cookie. When a user logs out, delete all the stored unique IDs. Now cookies generated before the logout are invalid. This is similar to the counter approach.

The user may also selectively invalidate cookies by unique ID if you provide an interface for it. Each unique ID could be stored alongside a browser fingerprint, geolocation, etc. so that the user can see where they're logged in. For an example, see Google's Devices & Activity page.

Note that because of the way OpenID works, the user will simply be logged back in next time they visit the site

This is a problem with @check. It's okay for some views. In my application, I have some views that I want to be available either authenticated or anomymously. If the user is logged in, I want to show them additional information - at the very least an 'account' menu that includes their name. If the user is not logged in, I don't want to annoy them by sending them to Google, just to view this page.
As a developer, the use case for me here is that someone who is logged in and viewing an authenticated page can 'share' the page via Facebook etc., and then anyone who clicks through from Facebook etc. gets the smoothest possible user experience.
Anyway, back to the original question: I was referring to user-initiated logout, not app-initiated logout / premature session expiry. What I'm doing at the moment, and I think you said this approximately correct, is:
response = redirect(url_for('home_page'))
response.set_cookie(OIDC.id_token_cookie_name, expires=0)
return response

For completeness, here's my is_authenticated method, which I'm using in some places instead of @check:
def is_authenticated():
    """
    Is the user authenticated with OpenID Connect?
    """
    if request.cookies.get(OIDC.id_token_cookie_name, None) is None:
        # Otherwise OIDC gets a little confused
        return False
    else:
        return OIDC.authenticate_or_redirect() is None

I have just added an oidc.logout() function, which will ensure log outs for cooperating browsers by expiring and emptying the cookie.
I will look into adding OpenID Connect Single Logout, and also logout for non-cooperating browsers, in the near future.
Also, with the new version you will also get the ID token if your API does not require authentication.
To indicate this, the check function has been renamed to require_login with a backwards compatibility later for check.

Hi,
I'm pretty new with this stuff, but I succeeded to have a full logout calling end_session_endpoint url which is provided by OpenID connect configuration. In this way, the session is also cleaned from your openid provider so it doesn't matter if your cookie is valid or not.
https://openid.net/specs/openid-connect-session-1_0-17.html
I'm using keycloak as a oidc provider.

For keycloak the following worked for me -
@app.route('/logout')
@oidc.require_login
def logout():
    refresh_token = oidc.get_refresh_token()
    oidc.logout()
    keycloak_openid.logout(refresh_token)
    response = redirect(url_for('login'))
    return response

I used python-keycloak library to logout from keycloak, you can find more details here - https://github.com/marcospereirampj/python-keycloak

I have just added an oidc.logout() function, which will ensure log outs for cooperating browsers by expiring and emptying the cookie. I will look into adding OpenID Connect Single Logout, and also logout for non-cooperating browsers, in the near future.
Also, with the new version you will also get the ID token if your API does not require authentication. To indicate this, the check function has been renamed to require_login with a backwards compatibility later for check.

I have tried this recently, the logout still not working. I am using version 1.4.0.

authors: 1zg12 RangeVsRange SteelPangolin puiterwijk sacx skt7

repo: puiterwijk/flask-oidc


text:
Sample issue for learning

This is a sample issue for learning

Closing it

authors: pujasmint suwigyarathore

repo: pujasmint/git-intro


text:
Object with array of object not working as expected

Hi,
I'm trying to generate an Object hash which again includes an array of Object. What seems to be happening is if the value of an array of object element changes, it still returns the same object hash. But adding/removing elements from the array of object seems to be working fine. Is this something expected ? My implementation details below -
private getHash(filter: SearchFilter) {     return objectHash(filter, {       excludeKeys(key: string) {         if (key === 'pageSize' || key === 'pageNumber') {           return true;         }         return true;       },       respectType: true     });   }
Sample input/output:

Test one

Input => {"pageSize":48,"pageNumber":1,"filterCriterias":[],"sortCriterias":[{"sortColumn":"NeedByDate","sortOrder":"asc"},{"sortColumn":"Status","sortOrder":"asc"}]}
Output object hash => 535c3001aaae9307daae192e1467b64126937576

Test two
Input => {"pageSize":8,"pageNumber":1,"filterCriterias":[],"sortCriterias":[{"sortColumn":"NeedByDate","sortOrder":"desc"},{"sortColumn":"Status","sortOrder":"asc"}]}

Output object hash => 535c3001aaae9307daae192e1467b64126937576
Thanks,
Dilip

Is one of the return true;s in the excludeKeys function supposed to be a return false;? :)

Sorry, I was trying multiple things, so the copied getHash method code was wrong. I have updated it and double check as well. Issue seems to be genuine

@dilipsarkar There is a mismatch between the names in the code – the excludeKeys function uses filterCriteria and sortCriteria, the objects themselves use filterCriterias and sortCriterias (with an extra s at the end).
(Just in case you’re curious – the word is borrowed from Ancient Greek, so “criterion” is the singular and “criteria” is the plural, “criterias” is not really a thing in English :slightly_smiling_face:)

Thanks @addaleax
I think what you have pointed out is one part of the issue, with that rectified also it wasn't working as expected. Actually inside excludeKeys, I wanted to include keys only for filterCriterias and sortCriteria so I was returning true when those keys were matched. When I changed my implementation otherwise i.e. skip pageNumber and pageSize(code below), it seems to be working fine. It doesn’t look very convincing to me but that seems to be working.
private getHash(filter: SearchFilter) {
    return objectHash(filter, {
      excludeKeys(key: string) {
        if (key === 'pageNumber' || key === 'pageSize') {
          return true;
        }
        return false;
      }
    });
  }

Appreciate your help and also thanks for the additional information on "criteria", wasn’t aware of it. Will make the necessary changes according :)

@dilipsarkar Okay, great to hear that worked out for you! Sounds like the code does what you intend it to do :+1:

authors: addaleax dilipsarkar

repo: puleos/object-hash


text:
Switch capybara from poltergeist to headless-chrome

fixes #321

Coverage remained the same at 100.0% when pulling 1c867b3aac6b1ae70a4ecfb9f81ec8ef632c9c1f on issue/321-headless-chrome into 6c32413baae0569389284185f0c64f22bb4096ba on master.

authors: coveralls hackmastera

repo: pulibrary/pomegranate


text:
fix common cells include in fpnew

fpnew refers to wrong include file from common cells

Strange that other implementations do not complain about this. If I understood well, this directive should take care of the discrepancy:
https://github.com/pulp-platform/common_cells/blob/master/Bender.yml#L16
To be checked, but I think this propagates the include/ dir as a directory in which to search for includes, and in common_cells you have an include/common_cells subdir (https://github.com/pulp-platform/common_cells/tree/master/include/common_cells).

Ok, thanks, I will let you know

repo: pulp-platform/fpnew


text:
snitch_cluster: Add missing include in Bender file

Not sure about the correct fix but this helps me compile for modelsim
make bin/snitch_cluster.vsim

Else, the axi/typedef.svh is not foud

That shouldn't be necessary as the cluster already depends on axi which exports the include location. What problem are you running into?

I got a File not found from vlog when compiling snitch_cluster_wrapper.sv, but after cleaning and recompiling it works without the changes proposed. Probably an artifact from a previous error. Closing

repo: pulp-platform/snitch


text:
fix: update return type of every method in pulse/every.ts & update database method in Pulse class to be public

docs: update README.md with links to documentation and website
fix: update return type of every method in pulse/every.ts
fix: update database method in Pulse class to be public

:tada: This PR is included in version 1.1.7 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: pulsecron/pulse


text:
auth0.Connection::options.fieldsMap state is flaky.

Describe what happened
When running pulumi up I create an auth0.Connection with samlp strategy. On this connection object I create the saml connection's options.fieldsMap.
This is a JSON string. However the state of the field does not necessarily the same as the input I provided. I suspect this is an auth0 issue where it parse and serializes the response back, such that the final output state is an equivalent json object string but not the same exact string. This leads to an incessant diff loop for that state.
Currently the only way to correct it, is to change your input options.fieldsMap string to match the output state.
A solution would be to internally save the state as an object and check for equality of the object, not of the string representation.
Sample program
new auth.Connection('example, {
  // ...
  options: {
    fieldsMap: `{"name": "name", "email": "email@example.org"}`
  }
})

Log output
No response
Affected Resource(s)
No response
Output of pulumi about
n/a
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 @davidmdm. I'm sorry you're hitting this bug and I'm glad you found a workaround. Thanks for reporting this to us.

@iwahbe ,no worries! No need to be sorry.
I suspect its more an unfortunate result of the auth0 API returning a serialized version of the object that doesn't match the the string that we provide, and not really an issue on the pulumi side. However, we can probably fix this issue permanently here if we store the state as a JS object instead of a string.

authors: davidmdm iwahbe


text:
Wrong glue table format created for Iceberg extension

What happened?
Tried to deploy a glue catalog table with iceberg extension in pulumi but the table is created with wrong format. For Iceberg table, the partitions are hidden unlike with standard table, the partitions are S3 prefixes. Also when tried to access it says invalid format ( Not an issue with permissions verified).
def create_test_tables(self):
    self.t_temp_table_iceberg_pulumi = aws.glue.CatalogTable(
        resource_name="t_temp_table_iceberg_pulumi",
        name="t_temp_table_iceberg_pulumi",
        database_name=self.glue_catalog_iceberg_catalog_db.name,
        parameters={
            "table_type": 'ICEBERG',
            "format": "parquet"
        },
        storage_descriptor=aws.glue.CatalogTableStorageDescriptorArgs(
            columns=[
                aws.glue.CatalogTableStorageDescriptorColumnArgs(
                    name="col1",
                    type="string",
                ),
                aws.glue.CatalogTableStorageDescriptorColumnArgs(
                    name="col2",
                    type="double",
                ),
                aws.glue.CatalogTableStorageDescriptorColumnArgs(
                    comment="",
                    name="col3",
                    type="String",
                ),
                aws.glue.CatalogTableStorageDescriptorColumnArgs(
                    comment="",
                    name="col4",
                    type="Boolean",
                )
            ],
            location=f"s3://{self.curated_bucket_name}/facilities_osipi_data_iceberg/tables/t_temp_table_iceberg_pulumi",
        ),
        partition_keys=[
            aws.glue.CatalogTablePartitionKeyArgs(
                name="col1",
                type="",
                comment="",
            ),
            aws.glue.CatalogTablePartitionKeyArgs(
                name="col2",
                type="",
                comment="",
            )
        ],
    )

Attached the screenshots of the tables that were created thru pulumi "t_temp_table_iceberg_pulumi" and manually from Athena catalog "t_temp_table_iceberg_1".
DDL:
CREATE TABLE `t_temp_table_iceberg_1`
(
`col1` string,
`col2` double,
`col3` string,
`col4` BOOLEAN,
`col5` BOOLEAN
)
PARTITIONED BY(
col1,
col2
)
LOCATION 's3://test-dev.org-energy.ca/iceberg_tables/t_temp_table_iceberg_1'
TBLPROPERTIES (
  'table_type'='ICEBERG',
  'format'='parquet'
)

Expected Behavior
Provided above
Steps to reproduce
Provided above
Output of pulumi about
Provided above
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 @bharathkgit I'm not too familiar with the operation of glue tables.
I recreated the same table locally too and all the properties appear to be set in the UI as in the code. Which part of the table resource creation is incorrect compared to your originating source code?

Hey @danielrbradley , Thanks for checking this.
Following things that are in question ?

If you look at the screenshot for "t_temp_table_iceberg_pulumi", the columns col1 and col2 showing as unknown partitions and kind of duplicated in the table structure. vs the table "t_temp_table_iceberg_1" does not have duplicated columns col1 and col2.
For iceberg table, the partition columns should be part of the table vs when you create an external table on top of S3, the partition columns can be s3 prefixes or folders and does not need to be part of the table.
Which means, the partition columns for iceberg must be inside the file.

I also want to understand if the TBLPROPERTIES supplied in the DDL are supposed to be part of parameters or not , because the TBLPROPERTIES defines whether it is a iceberg table or not.

Please let me know if you have any further questions. Thanks in advance!!

@danielrbradley , any luck with the issue ?

I'm afraid I'm still not entirely clear on where exactly the behaviour is not matching expectation or if there's a setting that's being missed. It's likely that this would be an issues from the underlying terraform provider to which this provider bridges.
Perhaps one of these issues describes the behaviour you're seeing? https://github.com/hashicorp/terraform-provider-aws/issues?q=is%3Aissue+glue

authors: bharathkgit danielrbradley

repo: pulumi/pulumi-aws


text:
Regression in v5.43.0

What happened?
After upgrade from 5.42.0 to 5.43.0 my code stopped working when doing Application.get():
Diagnostics:
  pulumi:pulumi:Stack (python-dev):
    error: Program failed with an unhandled exception:
    Traceback (most recent call last):
      File "/Users/rhuan/code/python/infra/__main__.py", line 2, in <module>
        from functions.function import Permissions, function_deploy
      File "/Users/rhuan/code/python/infra/functions/function.py", line 34, in <module>
        from common_infra.app_registration import client_id, tenant_id
      File "/Users/rhuan/code/python/infra/common_infra/app_registration.py", line 6, in <module>
        app = Application.get("app-registration", object_id)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/Users/rhuan/code/python/dist/export/python/virtualenvs/python-default/3.11.6/lib/python3.11/site-packages/pulumi_azuread/application.py", line 1934, in get
        return Application(resource_name, opts=opts, __props__=__props__)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/Users/rhuan/code/python/dist/export/python/virtualenvs/python-default/3.11.6/lib/python3.11/site-packages/pulumi_azuread/application.py", line 1693, in __init__
        ApplicationArgs._configure(_setter, **kwargs)
    TypeError: ApplicationArgs._configure() missing 1 required positional argument: 'display_name'

Example
from pulumi_azuread import Application
object_id="something"
app = Application.get("app-registration", object_id)

Output of pulumi about
CLI
Version      3.90.1
Go Version   go1.21.3
Go Compiler  gc

Plugins
NAME          VERSION
azure-native  2.14.0
azuread       5.43.0
python        3.11.6
random        4.14.0

Host
OS       darwin
Version  14.0
Arch     arm64

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).

It looks like it's tracked in https://github.com/pulumi/pulumi/issues/14418

I think this issue is actually different than https://github.com/pulumi/pulumi/issues/14418.
The example is calling:
https://github.com/pulumi/pulumi-azuread/blob/41675f1d9ab6097b9a40e6ddede87183045bcd28/sdk/python/pulumi_azuread/application.py#L1804
Which calls the __init__ like:
https://github.com/pulumi/pulumi-azuread/blob/41675f1d9ab6097b9a40e6ddede87183045bcd28/sdk/python/pulumi_azuread/application.py#L1934
Which is this:
https://github.com/pulumi/pulumi-azuread/blob/41675f1d9ab6097b9a40e6ddede87183045bcd28/sdk/python/pulumi_azuread/application.py#L1685-L1694
The call to _configure here:
https://github.com/pulumi/pulumi-azuread/blob/41675f1d9ab6097b9a40e6ddede87183045bcd28/sdk/python/pulumi_azuread/application.py#L1693C13-L1693C58
Isn't taking into account that this is for a .get and the props are being passed in __props__.
In any case, https://github.com/pulumi/pulumi/pull/14427 has reverted the change that introduced _configure in the first place, which was released in v3.91.1. Once pulumi-azuread is updated to use the v3.91.1 codegen and a new version is released, this shouldn't be an issue.

authors: justinvp mikhailshilkov rhuanbarreto

repo: pulumi/pulumi-azuread


text:
Removed azuread:subscriptionId from readme

This is not a valid configuration point and pulumi will throw an exception if set.

Closed via https://github.com/pulumi/pulumi-azuread/commit/97220d3752e1b4f40a99298a789f8b51e64c3b6e


text:
How does the Delta table resource work?

Questions
In short, these are the questions I have (context below):

Can the Databricks Pulumi provider create the Delta log too when creating the table?
Is it possible to update table columns, properties and so on?

Context
Question 1: table creation
This is how I'm trying to create a table:
table_resource = table.Table(
    table_name,
    catalog_name=catalog,
    schema_name=schema,
    name=table_name,
    columns=[
        table.TableColumnArgs(
            name="col1", position=0, type_name="STRING", type_text="varchar(64)", comment="first column",
            type_json="{\"name\":\"col1\",\"type\":\"varchar(64)\",\"nullable\":true,\"metadata\":{}}",
        ),
        table.TableColumnArgs(
            name="col2", position=1, type_name="INT", type_text="int", comment="second column revised comment",
            type_json="{\"name\":\"col2\",\"type\":\"integer\",\"nullable\":true,\"metadata\":{}}",
        ),
    ],
    data_source_format="DELTA",
    table_type="EXTERNAL",
    storage_location=f"s3://<REDACTED>",
)

When run, this code does create the table in the catalog but it does not create the delta log, so the table is broken (it's not possible to insert data, it's not possible to query the table): this issue describes the same problem.
However, if I use something like df.write.format("delta").mode("overwrite").save("s3://<REDACTED>") to first write data to the s3 path, then everything works.
Is there a way to have Pulumi create the Delta log too, so that it's possible to write to the Delta table using its name instead of the path? (this comment suggests it's not possible...)
Question 2: table update
Once the table is created and operational (the delta log exists), I'm trying to update it by for instance adding a column. Pulumi does realize that the resource must be updated but pulumi up fails with
cannot update table: A table's Delta metadata can only be changed from a cluster or warehouse

which to me is not very clear as an error: is it because I'm doing something wrong or because the SDK is not able to update the resource?
Comments in this thread suggest that the provider cannot update the table: is it true?

Hi @gab-txt - thank you for raising this issue. Your questions touch on missing functionality for the Table (specifically Unity Catalog Table) resource in both the upstream Terraform provider (which this provider is based on) and the Databricks API. It appears that currently the API does not support Updates fully at this time.
Databricks Terraform provider maintainers decided to not officially support this resource and remove documentation for the time being due to issues during Create as well as Update. At Pulumi, we document every resource we find in the schema; we regret that in this case this resulted in unknowingly using a nonworkable resource. I will file an issue to ensure we add a disclaimer to the Table resource to this point.
Unfortunately this does sound as though the underlying API is fundamentally lacking here, and there's not much we can do on our end. As soon as this endpoint is fully supported, and the upstream provider implements the functionality, we will pull in those changes.

Hi @guineveresaenger, it's unfortunate that the Table resource is nonworkable, but it's good to know what is and isn't available for now.
Thanks for proposing to add a disclaimer to the current documentation, this could save a lot of time for the ones that want to try it 🙂

authors: gab-txt guineveresaenger

repo: pulumi/pulumi-databricks


text:
Wrong type for Config in ProjectSettingsModel

What happened?
There is wrong property type for Config in ProjectSettingsModel. Right now it's string while specfication assumets it's map.
That cause than when I try to use LocalWorkspace automation it crash on deserialization.
(Line: 5, Col: 3, Idx: 82) - (Line: 5, Col: 3, Idx: 82): Exception during deserialization

Example
Code that crashes:
var args = new LocalProgramArgs($"new-stack", pathToProject);
var stack = await LocalWorkspace.CreateOrSelectStackAsync(args);

Configuration Pulumi.yaml:
name: MyProject
runtime: dotnet
description: Persistence
config:
  pulumi-disable-default-providers:
  - kubernetes
  some-setting: dev

Output of pulumi about
I'm using NuGet package Pulumi.Automation Version="3.67.1"
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).

Thanks for opening hte issue @rosieks. It looks like there's a similar issue with the Node.js and Python Automation API SDKs.
These SDKs should look more like the Go SDK:
type Project struct {
	// ...
	Config map[string]ProjectConfigType `json:"config,omitempty" yaml:"config,omitempty"`
	// ...
}

type ProjectConfigItemsType struct {
	Type  string                  `json:"type,omitempty" yaml:"type,omitempty"`
	Items *ProjectConfigItemsType `json:"items,omitempty" yaml:"items,omitempty"`
}

type ProjectConfigType struct {
	Type        *string                 `json:"type,omitempty" yaml:"type,omitempty"`
	Description string                  `json:"description,omitempty" yaml:"description,omitempty"`
	Items       *ProjectConfigItemsType `json:"items,omitempty" yaml:"items,omitempty"`
	Default     interface{}             `json:"default,omitempty" yaml:"default,omitempty"`
	Value       interface{}             `json:"value,omitempty" yaml:"value,omitempty"`
	Secret      bool                    `json:"secret,omitempty" yaml:"secret,omitempty"`
}

@justinvp Any info when that might be fixed or how to workaround that? It's kind of blocking issue

Just to add. I think similar issue is with StackSettings as there might be only string provided and there is no way to set complex object.

authors: justinvp rosieks

repo: pulumi/pulumi-dotnet


text:
Schema does not detect changes at preview

When adding or removing SchemaPolicy in the policies arg of Schema, a preview does not detect any changes.
they seem applied during an update though :
Previewing update (integration):
     Type                 Name                  Plan
     pulumi:pulumi:Stack  services-integration

Resources:
    172 unchanged

Do you want to perform this update? yes
Updating (integration):
     Type                           Name                  Status       Info
     pulumi:pulumi:Stack            services-integration  running...   read aws:iam:Role integration-service-role
     Type                           Name                  Status      Info
     pulumi:pulumi:Stack            services-integration
     └─ services:API                api
 ~      └─ postgresql:index:Schema  api-db-schema         updated     [diff: ~policies]

Resources:
    ~ 1 updated
    171 unchanged

nvm, just updated to 2.4.0 and it seems fixed, sorry for the noise.

repo: pulumi/pulumi-postgresql


text:
Upgrade to jQuery 2.0

We should use the newest version of jQuery.
Since jQuery 2.x and higher don't support old versions of IE, we should check for those and give some kind of notice.

We should serve jQuery 2.x everywhere. Versions of IE that we'd need 1.x to support are already blacklisted for XSS reasons.

authors: evanp strugee


text:
Add non-transitive revdeps

In our pairing today, we figured out that we need different logic to compute test-only deps and depopts non-recursively.
This PR adapts the key logic from
https://github.com/ocaml/opam/blob/b3d2f5c554e6ef3cc736a9f97e252486403e050f/src/client/opamListCommand.ml#L238-L244 to compute these dependencies.
My preliminary local test indicates that this computes the exact same
set as the 3 shell script lines we currently run, but I've only run this for
a single package at the moment. So more thorough tests are in order to ensure the logic is right.
Contributes towards https://github.com/tarides/infrastructure/issues/297

This is a great clarifying commit. Thank you for crystallizing our learning from the pairing session as code. :)

Thanks for the review and for the pairing session! It was super clarifying. I especially appreciate your patience in explaining why depopts are not transitive :D.

authors: punchagan shonfeder

repo: punchagan/revdeps-prototype


text:
implemented batch uploads per @stuartromanek's sketch

Will close #363.
createViaUpload is a new boolean flag for pieces subclasses. It is on by default for images and files, and when it is on, the "new/add" button triggers the browser's file upload dialog directly, plus you can drag and drop to the manager modal.
You can enable it for other pieces too but they must directly possess a schema field of type attachment — not to be confused with a widget that refers to images or files.
If you do a big fat test, like dragging in a big folder of images, it will upload relatively quickly but be prepared for a large delay at save time. That's autocropping. The spinner is working properly during this time, although it would be a nice enhancement later to say something specific.
I also fixed some other UX issues:

Non-chooser managers had space set aside to display the current selection, which we've discussed won't be a thing because the selection will potentially be very large (too large, even, to display all at once) when working with bulk operations — it's not the same as choosing things for a slideshow.
The logic for adjusting the heights of the elements in a manager modal assumed the footer was not a child of the body, but it has been for a long time, which is why there's been non-reachable space at the bottom when scrolling a tall page of images etc. I fixed the math both for the body and for the chooser.
minSize constraints are shown to the user, and if you batch upload images that are too small you'll be told so. We could do it better, but this is a good iterative improvement.
The image chooser had two search fields... still! I'm not sure if this was a regression or a special case where it was never fixed. The latter seems likely because it has a custom template.

Hey @boutell , looking and feeling very awesome, 🍾
In testing around in apostrophe-boilerplate, noticed that regular files get a front-end error when uploading a single file, both via the button and drag-and-drop. Doesn't happen if you go the multi route or if you do it through Images.
Starts with
Uncaught TypeError: Cannot read property 'edit' of undefined at feedback (http://localhost:3000/modules/apostrophe-pieces/js/manager-modal.js:299:27)

Good catch! Fixed that bug.

Quieted that log. Stuart did you review the source code or should I set something up with Alex?

I did review it, nothing jumped out at me but by all means get more eyeballs in there

authors: boutell stuartromanek

repo: punkave/apostrophe


text:
Add support for SNI

Added two attributes to manage_binding defined type:
store
sslFlag
New-WebBinding now uses SslFlags parameter.
Templates updated to search for ssl bindings with host headers.
Example Usage:
iis::manage_binding { "${site_name}-443":
site_name              => $site_name,
protocol               => 'https',
port                   => '443',
host_header            => $site_name,
certificate_thumbprint => $cert_thumbprint,
store                  => 'WebHosting',
sslFlag                => '1',
require                => Sslcertificate[ "${site_name}" ],
}

The innards of this module are damaging to the soul. However, this change looks to be in line with the style of the module. Can you squash your commits down into one or two commits?

Will do and agreed. My soul hurts.

Rebased

@hathoward This needs the merge conflicts fixed, commits squashed then a rebase

authors: hathoward juniorsysadmin nibalizer

repo: puppet-community/puppet-iis


text:
Fix mysql connector containment

When using the mysql_connector download, the file is often times downloaded after the service is started.  This fix uses the contain function to make sure the mysql_connector class is contained in the install class, thus fixing dependancies.
It also updates the travis tests and the metadata.json to use the minimum versions of puppet that have the contain class.  This means that anyone still using Puppet Enterprise < 3.2 will not be able to use this module anymore, but that version has been long unsupported by Puppet Labs so this should not be an issue.

Hmm.. it looks like travis didnt see the PR.  The build does pass on my branch though: https://travis-ci.org/adamcrews/puppet-jira/builds/80906053

repo: puppet-community/puppet-jira


text:
[Bug]: Unable to bundle puppeteer script with wepack

Minimal, reproducible example
const puppeteer = require('puppeteer') // this is the code in puppeteer script

//webpack config
const path = require("path")

module.exports = {
  mode: 'none',
  target: 'node',
  entry:  path.resolve(__dirname, "lib/javascript/puppeteer.js"), // Replace 'your_script.js' with the name of your script file
  output: {
    filename: 'puppeteer_bundle.js',
    path: path.resolve(__dirname, 'public/diagnostics/packs/js')
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env'],
          },
        },
      },
    ],
  },
  resolve: {
    extensions: ['.js'],
  },
};

NODE VERSION 18.19.1
PUPPETEER VERSION 22.6.3

Error string
ERROR in ./node_modules/puppeteer/lib/cjs/puppeteer/puppeteer.js Module not found: Error: Can't resolve 'puppeteer-core/internal/node/PuppeteerNode.js' in '/home/nabin/Desktop/work/mindgym-diagnostics/node_modules/puppeteer/lib/cjs/puppeteer'  @ ./node_modules/puppeteer/lib/cjs/puppeteer/puppeteer.js 32:27-83  @ ./lib/javascript/puppeteer.js  ERROR in ./node_modules/puppeteer/lib/cjs/puppeteer/puppeteer.js Module not found: Error: Can't resolve 'puppeteer-core/internal/puppeteer-core.js' in '/home/nabin/Desktop/work/mindgym-diagnostics/node_modules/puppeteer/lib/cjs/puppeteer'  @ ./node_modules/puppeteer/lib/cjs/puppeteer/puppeteer.js 31:13-65  @ ./lib/javascript/puppeteer.js  ERROR in ./node_modules/puppeteer/lib/cjs/puppeteer/getConfiguration.js 50:62 Module parse failed: Unexpected token (50:62) File was processed with these loaders:  * ./node_modules/babel-loader/lib/index.js You may need an additional loader to handle the result of these loaders. |   }).search(); |   const configuration = result ? result.config : {}; >   configuration.logLevel = process.env['PUPPETEER_LOGLEVEL'] ?? process.env['npm_config_LOGLEVEL'] ?? process.env['npm_package_config_LOGLEVEL'] ?? configuration.logLevel ?? 'warn'; |   // Merging environment variables. |   configuration.defaultProduct = process.env['PUPPETEER_PRODUCT'] ?? process.env['npm_config_puppeteer_product'] ?? process.env['npm_package_config_puppeteer_product'] ?? configuration.defaultProduct ?? 'chrome';  @ ./node_modules/puppeteer/lib/cjs/puppeteer/puppeteer.js 33:30-62  @ ./lib/javascript/puppeteer.js
Bug behavior

[X] Flaky
[X] PDF

Background
I have been trying to build the script before deployment
Expectation
The script should have been built along with its dependencise
Reality
ERROR in ./node_modules/puppeteer/lib/cjs/puppeteer/puppeteer.js
Module not found: Error: Can't resolve 'puppeteer-core/internal/node/PuppeteerNode.js' in '/home/nabin/Desktop/work/mindgym-diagnostics/node_modules/puppeteer/lib/cjs/puppeteer'
@ ./node_modules/puppeteer/lib/cjs/puppeteer/puppeteer.js 32:27-83
@ ./lib/javascript/puppeteer.js
ERROR in ./node_modules/puppeteer/lib/cjs/puppeteer/puppeteer.js
Module not found: Error: Can't resolve 'puppeteer-core/internal/puppeteer-core.js' in '/home/nabin/Desktop/work/mindgym-diagnostics/node_modules/puppeteer/lib/cjs/puppeteer'
@ ./node_modules/puppeteer/lib/cjs/puppeteer/puppeteer.js 31:13-65
@ ./lib/javascript/puppeteer.js
ERROR in ./node_modules/puppeteer/lib/cjs/puppeteer/getConfiguration.js 50:62
Module parse failed: Unexpected token (50:62)
File was processed with these loaders:

./node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.
|   }).search();
|   const configuration = result ? result.config : {};

configuration.logLevel = process.env['PUPPETEER_LOGLEVEL'] ?? process.env['npm_config_LOGLEVEL'] ?? process.env['npm_package_config_LOGLEVEL'] ?? configuration.logLevel ?? 'warn';
|   // Merging environment variables.
|   configuration.defaultProduct = process.env['PUPPETEER_PRODUCT'] ?? process.env['npm_config_puppeteer_product'] ?? process.env['npm_package_config_puppeteer_product'] ?? configuration.defaultProduct ?? 'chrome';
@ ./node_modules/puppeteer/lib/cjs/puppeteer/puppeteer.js 33:30-62
@ ./lib/javascript/puppeteer.js

Getting this errror
Puppeteer configuration file (if used)
No response
Puppeteer version
22.6.3
Node version
18.19.1
Package manager
yarn
Package manager version
1.22.21
Operating system
Linux

See a working example from our tests https://github.com/puppeteer/puppeteer/blob/main/test/installation/assets/puppeteer/webpack/webpack.config.js (tests https://github.com/puppeteer/puppeteer/blob/main/test/installation/src/puppeteer-webpack.spec.ts)
The puppeteer-core/internal error indicates that the module module resolution is not working well in your setup. Generally, issues with third party software should not be reported here. Consider asking on StackOverflow or raising an issue with Webpack.

authors: NabinOjha OrKoN

repo: puppeteer/puppeteer


text:
[Feature]: Run tests directly without spinning up a test server, in an Angular and Jest.

Feature description
Run E2E tests in angular ,
ng e2e
This command invariably necessitates running ng serve beforehand, which typically consumes around 2 minutes.
It would be highly convenient for developers if tests could be run directly against an already running service.

This seems to be an issue pertaining to Angular.

This issue is related to @puppeteer/ng-schematics:puppeteer
async function executeE2ETest(   options: PuppeteerBuilderOptions,   context: BuilderContext ): Promise<BuilderOutput> {   let server: BuilderRun | null = null;   try {     message('\n Building tests 🛠 ... \n', context);     await executeCommand(context, [tsc`, '-p', 'e2e/tsconfig.json']);
server = await startServer(options, context);
const result = await server.result;

message('\n Running tests 🧪 ... \n', context);
const testRunnerCommand = getCommandForRunner(options.testRunner);
await executeCommand(context, testRunnerCommand, {
  baseUrl: result['baseUrl'],
});

message('\n 🚀 Test ran successfully! 🚀 ', context, 'success');
return {success: true};

} catch (error) {
message('\n 🛑 Test failed! 🛑 ', context, 'error');
if (error instanceof Error) {
return {success: false, error: error.message};
}
return {success: false, error: error as string};
} finally {
if (server) {
await server.stop();
}
}
} ng e2e` must start a server, this is a waste of time.
If ng e2e can test a exist server, that would be great.

Imho this is a duplicate of https://github.com/puppeteer/puppeteer/issues/12222.

authors: pfeileon zmpo


text:
Page throws timeout exception only in headless mode

Tell us about your environment:

Puppeteer version: puppeteer@next (latest commit)
Platform / OS version: macOS High Sierra 10.13.1
URLs (if applicable): http://www.sanident.it
Node.js version: v8.6.0

What steps will reproduce the problem?
  const browser = await puppeteer.launch({
    headless: true,
  });

  const page = await browser.newPage();
  await page.goto("http://www.sanident.it", {timeout: 10000});
  console.log(await page.content());

What is the expected result?
Promise does not throw "Navigation Timeout Exceeded" no matter if using headless or non-headless mode.
What happens instead?
Promise throws "Navigation Timeout Exceeded" ONLY in headless mode. In non-headless it works fine. This does not work also in v0.13.0 BUT IT WORKS in v0.12.0

I can confirm that this timeouts in headless and not headful mode. Perhaps the site does some kind of headless/automation sniffing and something is blocking the page from finishing?

+1

@zhanghuanchong and what was your waitOptions?

@nnnikolay I use nothing. This parameter is optional.
Some other people also recommend using:
page.click(selector, clickOptions)
await page.waitForNavigation()

Which works for me too.

@zhanghuanchong pretty sure that it works, but the question is what the options is in you waitOptions object?

@marijanlekic Were you able to resolve the issue?

@mcpwns
In this case {waitUntil: "networkidle2"} worked for me. I found out that this works for me the best in most situations.

Works fine for me on tip-of-tree f8cba455ba5d1bc82721e89fda037e86213b02cb:
const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const [page] = await browser.pages();
  await page.goto('http://www.sanident.it');
  console.log(page.url());
  await browser.close();
})();

I ended up on this thread because I was doing page.goto('localhost:3000') instead of page.goto('http://localhost:3000'). The protocol seems mandatory in headless mode.
Hope this helps

This should be documented somewhere.
In headless mode browser cache is PRESERVED, so you can't catch all of your precious requests!
But in 'headful' mode cache somehow gets reset.
Just do this:
const goto = async url => {
  const page = await browser.newPage()
  await page.setCacheEnabled(false) // <-- this one is a game changer
  await page.goto(url)
  return page
}

// somewhere
await goto('MY_URL:666')

Can confirm this with puppeteer 2.1.1
const puppeteer = require('puppeteer');
const url = 'https://www.youtube.com/channel/UCxhygwqQ1ZMoBGQM2yEcNug/videos';

async function run() {
  try {
    const browser = await puppeteer.launch({ headless: true });
    const page = await browser.newPage();
    await page.goto(url, { waitUntil: 'networkidle2' });
    await page.waitForSelector('#items');
    const html = await page.evaluate(() => document.body.innerHTML);
    // Throws TimeoutError when headless is set to true
  } catch (e) {
    console.log(e);
  }
}

run();

Some websites block headless useragent. You might try to change that.
await page.setUserAgent('Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36');
await page.goto('http://www.sanident.it/');

As a workaround:
    const browser = await puppeteer.launch({         headless: false,         args:['--headless']     });

Using puppeteer@10.4.0
@kirosc, have tried setting userAgent still no resolution. Facing the navigation timeout issue intermittently.
`       const browser = await puppeteer.launch({defaultViewport:null, headless:true})
const page = await browser.newPage()
await page.goto(RecLoginPageUrl)
await page.type(loginPageUsernameSelector, RecUsername,{delay:100})
await page.type(loginPagePasswordSelector, RecPassword,{delay:100})
await utility.waitAndClick(page,loginPageSubmitBtnSelector)
console.log("Clicked submit on Login page");
    await page.waitForNavigation({waitUntil:'load', timeout:60000})
    await page.click(mPowerSearchBtnSelector)
    console.log("Clicked mPower on Dashboard");

    await page.waitForNavigation({waitUntil:'load', timeout:60000})
    await utility.waitAndClick(page,v4SearchBtnSelector)
    console.log("Clciked Search btn on V4Search");

    await page.waitForNavigation({waitUntil:'networkidle0', timeout:60000})
    console.log("On V4 SRP");
    let loadtime =await page.evaluate(_=>{
        const {navigationStart, loadEventEnd} = performance.timing
        return Promise.resolve(loadEventEnd - navigationStart )
    })
    browser.close()
    return Promise.resolve(loadtime)`

In my case I forced the resolution I used in development and it worked normally
     const browser = await puppeteer. Launch({
                headless: true,
                defaultViewport: { width: 1280, height: 1600 },
                userDataDir: "./tmp",
        });

I can confirm, setting the defaultViewPort at launch solved my issue. Thanks @fclebio

authors: Namanmittal0007 VincentCharpentier aslushnikov ebidel fclebio john-doherty kirosc marijanlekic mcpwns nnnikolay sorxrob thiscompsciguy yyynnn zhanghuanchong


text:
When using css property flex extra page appears in PDF

Steps to reproduce

Puppeteer version: 1.19 +
Platform / OS version: mac 10.14.6
Node.js version: 10.11.0

What steps will reproduce the problem?

Use this HTML

Header of 50px

Page1 of 740px

Page2 of 790px

This is how it looks like

Print the pdf in landscape

const puppeteer = require('puppeteer');

(async () => {
    const browser = await puppeteer.launch({
        args: ['--disable-gpu']
    });

    let page = await browser.newPage();
    await page.goto('file:///Users/path-to-the-html-above.html');
    await page.pdf({path: 'hn.pdf', format: 'A4', landscape: true, printBackground: true});
    await browser.close();
})();

What is the expected result?
The PDF should have 2 pages - 1st page with 'header' and 'page1' blocks and 2nd page with 'page2' block
What happens instead?
An extra page is present due to one of the pages overflowing. In this attached pdf there is some margin between 2 pages causing the 2nd page to overflow. Sometimes this margin is on the second page.
w-1.19.pdf
extra-page.pdf

This used to work with version ~1.14.0.