text:
release 1.0.3

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-linter wolfv


text:
MNT: Re-rendered with conda-build 3.18.9, conda-smithy 3.5.0, and con…

…da-forge-pinning 2019.10.11

Checklist

[ ] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

source: gharchive/pull-request

authors: conda-forge-linter fhoehle

repo: conda-forge/tktable-feedstock

license_type: permissive

license_source: github-api


text:
Add tests

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

authors: conda-forge-linter jan-janssen

repo: conda-forge/votca-feedstock


text:
[BUG] requires_python ~= 3.6 generates incorrect python requirement

Describe the bug
I ran grayskull pypi wheel-filename and the python requirement generated was python >=3.6,<3.7.
The setup.cfg includes python_requires = ~= 3.6, which is equivalent to >=3.6,<4.
To Reproduce
Steps to reproduce the behavior:

Run grayskull pypi wheel-filename

Expected behavior
The python requirement generated should be >=3.6,<4 (or >=3.6,==3.*?)
Environment:

grayskull --version
1.1.0

Additional context
I tracked the issue to the generic_py_ver_to function.
Currently generic_py_ver_to({"requires_python": "~=3.6"}, config) == ">=3.6,<3.7 which is incorrect.

Yeah, indeed that is a bug, thanks for reporting it! Are you considering fixing it? I am asking that just to be aware :)

I'll give it a try :-)

source: gharchive/issue

authors: beenje marcelotrevisani

repo: conda-incubator/grayskull


text:
Create recipe from github tag

This is currently available: it allows one to use the latest release.
grayskull pypi https://github.com/confluentinc/confluent-kafka-python

:hand:  How can you create a recipe for a specific release version (with a tag preferably)?
:fire: Is there something like the following that could be used?
grayskull pypi https://github.com/{{ OWNER }}/{{ REPO }} --tag {{ TAG }}

Example:
OWNER="sugatoray"
REPO="genespeak"
TAG="v0.0.9"
grayskull pypi https://github.com/${OWNER}/${REPO} --tag ${TAG}

Notes
I see that the code tries to download the sdist package from this URL.
https://api.github.com/repos/{{ USER }}/{{ REPO }}/releases/latest

According to GitHub API docs the following returns the release information with a specific tag.
https://api.github.com/repos/{{ USER }}/{{ REPO }}/releases/tags/{{ TAG }}

Example
Here we look at the json output returned by GitHub API for genespeak repository. Both of the following two methods will yield the same output (release info for v0.0.9 as on 2022-04-26).

https://github.com/sugatoray/genespeak

Release: latest
https://api.github.com/repos/sugatoray/genespeak/releases/latest

Click to expand and see output

{
  "url": "https://api.github.com/repos/sugatoray/genespeak/releases/57632929",
  "assets_url": "https://api.github.com/repos/sugatoray/genespeak/releases/57632929/assets",
  "upload_url": "https://uploads.github.com/repos/sugatoray/genespeak/releases/57632929/assets{?name,label}",
  "html_url": "https://github.com/sugatoray/genespeak/releases/tag/v0.0.9",
  "id": 57632929,
  "author": {
    "login": "sugatoray",
    "id": 10201242,
    "node_id": "MDQ6VXNlcjEwMjAxMjQy",
    "avatar_url": "https://avatars.githubusercontent.com/u/10201242?v=4",
    "gravatar_id": "",
    "url": "https://api.github.com/users/sugatoray",
    "html_url": "https://github.com/sugatoray",
    "followers_url": "https://api.github.com/users/sugatoray/followers",
    "following_url": "https://api.github.com/users/sugatoray/following{/other_user}",
    "gists_url": "https://api.github.com/users/sugatoray/gists{/gist_id}",
    "starred_url": "https://api.github.com/users/sugatoray/starred{/owner}{/repo}",
    "subscriptions_url": "https://api.github.com/users/sugatoray/subscriptions",
    "organizations_url": "https://api.github.com/users/sugatoray/orgs",
    "repos_url": "https://api.github.com/users/sugatoray/repos",
    "events_url": "https://api.github.com/users/sugatoray/events{/privacy}",
    "received_events_url": "https://api.github.com/users/sugatoray/received_events",
    "type": "User",
    "site_admin": false
  },
  "node_id": "RE_kwDOGmamys4Db2ih",
  "tag_name": "v0.0.9",
  "target_commitish": "master",
  "name": "v0.0.9",
  "draft": false,
  "prerelease": false,
  "created_at": "2022-01-21T03:26:06Z",
  "published_at": "2022-01-21T03:27:46Z",
  "assets": [

  ],
  "tarball_url": "https://api.github.com/repos/sugatoray/genespeak/tarball/v0.0.9",
  "zipball_url": "https://api.github.com/repos/sugatoray/genespeak/zipball/v0.0.9",
  "body": "The first release after integrating with zenodo. No major changes.\n"
}

Release Tag: v0.0.9
https://api.github.com/repos/sugatoray/genespeak/releases/tags/v0.0.9

Click to expand and see output

{
  "url": "https://api.github.com/repos/sugatoray/genespeak/releases/57632929",
  "assets_url": "https://api.github.com/repos/sugatoray/genespeak/releases/57632929/assets",
  "upload_url": "https://uploads.github.com/repos/sugatoray/genespeak/releases/57632929/assets{?name,label}",
  "html_url": "https://github.com/sugatoray/genespeak/releases/tag/v0.0.9",
  "id": 57632929,
  "author": {
    "login": "sugatoray",
    "id": 10201242,
    "node_id": "MDQ6VXNlcjEwMjAxMjQy",
    "avatar_url": "https://avatars.githubusercontent.com/u/10201242?v=4",
    "gravatar_id": "",
    "url": "https://api.github.com/users/sugatoray",
    "html_url": "https://github.com/sugatoray",
    "followers_url": "https://api.github.com/users/sugatoray/followers",
    "following_url": "https://api.github.com/users/sugatoray/following{/other_user}",
    "gists_url": "https://api.github.com/users/sugatoray/gists{/gist_id}",
    "starred_url": "https://api.github.com/users/sugatoray/starred{/owner}{/repo}",
    "subscriptions_url": "https://api.github.com/users/sugatoray/subscriptions",
    "organizations_url": "https://api.github.com/users/sugatoray/orgs",
    "repos_url": "https://api.github.com/users/sugatoray/repos",
    "events_url": "https://api.github.com/users/sugatoray/events{/privacy}",
    "received_events_url": "https://api.github.com/users/sugatoray/received_events",
    "type": "User",
    "site_admin": false
  },
  "node_id": "RE_kwDOGmamys4Db2ih",
  "tag_name": "v0.0.9",
  "target_commitish": "master",
  "name": "v0.0.9",
  "draft": false,
  "prerelease": false,
  "created_at": "2022-01-21T03:26:06Z",
  "published_at": "2022-01-21T03:27:46Z",
  "assets": [

  ],
  "tarball_url": "https://api.github.com/repos/sugatoray/genespeak/tarball/v0.0.9",
  "zipball_url": "https://api.github.com/repos/sugatoray/genespeak/zipball/v0.0.9",
  "body": "The first release after integrating with zenodo. No major changes.\n"
}

Originally posted by @sugatoray in https://github.com/conda-incubator/grayskull/discussions/318

@marcelotrevisani
:tada: Conda-Forger App now supports recipe preparation from GitHub apart from PyPI (thanks to PR #346).

Conda-Forger App :zap: : https://tinyurl.com/conda-forger

authors: marcelotrevisani sugatoray


text:
Salesforce Connector - throwing - TimeoutException: Timed out waiting for a node assignment

Hello, i'm currently getting an error org.apache.kafka.common.errors.TimeoutException: Timed out waiting for a node assignment in the connector status after configuring a Salesforce Source Connector in Confluent Center > Connect Page.
This is my docker-compose.yml file:
`
version: '2'
services:
zookeeper:
image: confluentinc/cp-zookeeper:latest
ports:
- '31000:31000'
environment:
ZOOKEEPER_CLIENT_PORT: 2181
ZOOKEEPER_TICK_TIME: 2000
KAFKA_JMX_HOSTNAME: "localhost"
KAFKA_JMX_PORT: 31000
kafka:
# "-._,-'"-.,-'"-._,-'"-.,-'"-._,-'"-.,-'"-._,-'"-.,-'"-._,-     # An important note about accessing Kafka from clients on other machines:      # -----------------------------------------------------------------------     #     # The config used here exposes port 9092 for _external_ connections to the broker     # i.e. those from _outside_ the docker network. This could be from the host machine     # running docker, or maybe further afield if you've got a more complicated setup.      # If the latter is true, you will need to change the value 'localhost' in      # KAFKA_ADVERTISED_LISTENERS to one that is resolvable to the docker host from those      # remote clients     #     # For connections _internal_ to the docker network, such as from other services     # and components, use kafka:29092.     #     # See https://rmoff.net/2018/08/02/kafka-listeners-explained/ for details     # "-.,-'"-._,-'"-.,-'"-._,-'"-.,-'"-._,-'"-.,-'"-._,-'"-._,-
#
image: confluentinc/cp-enterprise-kafka:5.3.0
ports:
- '9092:9092'
- '31001:31001'
depends_on:
- zookeeper
environment:
KAFKA_BROKER_ID: 1
KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:29092,PLAINTEXT_HOST://localhost:9092
KAFKA_AUTO_CREATE_TOPICS_ENABLE: "true"
KAFKA_METRIC_REPORTERS: io.confluent.metrics.reporter.ConfluentMetricsReporter
KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 100
CONFLUENT_METRICS_REPORTER_BOOTSTRAP_SERVERS: kafka:29092
CONFLUENT_METRICS_REPORTER_ZOOKEEPER_CONNECT: zookeeper:2181
CONFLUENT_METRICS_REPORTER_TOPIC_REPLICAS: 1
CONFLUENT_METRICS_ENABLE: 'false'
CONFLUENT_SUPPORT_CUSTOMER_ID: 'anonymous'
KAFKA_JMX_HOSTNAME: "localhost"
KAFKA_JMX_PORT: 31001
schema-registry:
image: confluentinc/cp-schema-registry:latest
depends_on:
- zookeeper
- kafka
ports:
- '8081:8081'
- '31002:31002'
environment:
SCHEMA_REGISTRY_HOST_NAME: schema-registry
SCHEMA_REGISTRY_KAFKASTORE_CONNECTION_URL: zookeeper:2181
SCHEMA_REGISTRY_JMX_HOSTNAME: "localhost"
SCHEMA_REGISTRY_JMX_PORT: 31002
ksql-server:
image: confluentinc/cp-ksql-server:latest
depends_on:
- kafka
- schema-registry
ports:
- '31003:31003'
- '8088:8088'
environment:
KSQL_BOOTSTRAP_SERVERS: kafka:29092
KSQL_LISTENERS: http://0.0.0.0:8088
KSQL_KSQL_SCHEMA_REGISTRY_URL: http://schema-registry:8081
KSQL_KSQL_SERVICE_ID: asgard
KSQL_JMX_HOSTNAME: "localhost"
KSQL_JMX_PORT: 31003
KSQL_LOG4J_ROOT_LOGLEVEL: "INFO"
KSQL_LOG4J_LOGGERS: "org.apache.kafka.connect.runtime.rest=WARN,org.reflections=ERROR"
# --- Processing log config ---
KSQL_LOG4J_PROCESSING_LOG_BROKERLIST: kafka:29092
KSQL_LOG4J_PROCESSING_LOG_TOPIC: asgard_processing_log
KSQL_KSQL_LOGGING_PROCESSING_TOPIC_NAME: asgard_processing_log
KSQL_KSQL_LOGGING_PROCESSING_TOPIC_AUTO_CREATE: "true"
KSQL_KSQL_LOGGING_PROCESSING_STREAM_AUTO_CREATE: "true"
ksql-cli:
image: confluentinc/cp-ksql-cli:latest
depends_on:
- ksql-server
entrypoint: /bin/sh
tty: true
kafka-connect:
image: confluentinc/cp-kafka-connect:latest
ports:
- '8083:8083'
- '31004:31004'
environment:
CONNECT_BOOTSTRAP_SERVERS: "kafka:29092"
CONNECT_REST_PORT: 8083
CONNECT_GROUP_ID: compose-connect-group
CONNECT_CONFIG_STORAGE_TOPIC: docker-connect-configs
CONNECT_OFFSET_STORAGE_TOPIC: docker-connect-offsets
CONNECT_STATUS_STORAGE_TOPIC: docker-connect-status
CONNECT_KEY_CONVERTER: io.confluent.connect.avro.AvroConverter
CONNECT_KEY_CONVERTER_SCHEMA_REGISTRY_URL: 'http://schema-registry:8081'
CONNECT_VALUE_CONVERTER: io.confluent.connect.avro.AvroConverter
CONNECT_VALUE_CONVERTER_SCHEMA_REGISTRY_URL: 'http://schema-registry:8081'
CONNECT_INTERNAL_KEY_CONVERTER: "org.apache.kafka.connect.json.JsonConverter"
CONNECT_INTERNAL_VALUE_CONVERTER: "org.apache.kafka.connect.json.JsonConverter"
CONNECT_REST_ADVERTISED_HOST_NAME: "kafka-connect"
CONNECT_LOG4J_ROOT_LOGLEVEL: "INFO"
CONNECT_LOG4J_LOGGERS: "org.apache.kafka.connect.runtime.rest=WARN,org.reflections=ERROR"
CONNECT_CONFIG_STORAGE_REPLICATION_FACTOR: "1"
CONNECT_OFFSET_STORAGE_REPLICATION_FACTOR: "1"
CONNECT_STATUS_STORAGE_REPLICATION_FACTOR: "1"
CONNECT_PLUGIN_PATH: /usr/share/java,/usr/share/confluent-hub-components
KAFKA_JMX_HOSTNAME: "localhost"
KAFKA_JMX_PORT: 31004
depends_on:
- zookeeper
- kafka
- schema-registry
# Uncomment this bit if you want to automatically install the datagen and twitter connectors
# and set the datagen connector running
# command:
#   - bash
#   - -c
#   - |
#     confluent-hub install --no-prompt confluentinc/kafka-connect-datagen:0.1.1
#     confluent-hub install --no-prompt jcustenborder/kafka-connect-twitter:0.2.32
#     /etc/confluent/docker/run &
#     echo "Waiting for Kafka Connect to start listening on kafka-connect ⏳"
#     while [ $$(curl -s -o /dev/null -w %{http_code} http://kafka-connect:8083/connectors) -ne 200 ] ; do
#       echo -e $$(date) " Kafka Connect listener HTTP state: " $$(curl -s -o /dev/null -w %{http_code} http://kafka-connect:8083/connectors) " (waiting for 200)"
#       sleep 5
#     done
#     nc -vz kafka-connect 8083
#     echo -e "\n--\n+> Creating Connector"
#     curl -X POST http://kafka-connect:8083/connectors -H "Content-Type: application/json" -d '
#     {
#       "name": "datagen-pageviews",
#       "config": {
#         "connector.class": "io.confluent.kafka.connect.datagen.DatagenConnector",
#         "kafka.topic": "pageviews",
#         "quickstart": "pageviews",
#         "max.interval": 100,
#         "iterations": 10000000,
#         "tasks.max": "1"
#       }
#     }
#     '
#     sleep infinity
rest-proxy:
image: confluentinc/cp-kafka-rest:latest
depends_on:
- zookeeper
- kafka
- schema-registry
ports:
- '8082:8082'
- '31005:31005'
environment:
KAFKA_REST_HOST_NAME: rest-proxy
KAFKA_REST_BOOTSTRAP_SERVERS: 'kafka:29092'
KAFKA_REST_LISTENERS: "http://0.0.0.0:8082"
KAFKA_REST_SCHEMA_REGISTRY_URL: 'http://schema-registry:8081'
KAFKAREST_JMX_HOSTNAME: "localhost"
KAFKAREST_JMX_PORT: 31005
control-center:
image: confluentinc/cp-enterprise-control-center:latest
hostname: control-center
container_name: control-center
depends_on:
- zookeeper
- kafka
- schema-registry
- kafka-connect
- ksql-server
ports:
- "9021:9021"
environment:
CONTROL_CENTER_BOOTSTRAP_SERVERS: 'kafka:29092'
CONTROL_CENTER_ZOOKEEPER_CONNECT: 'zookeeper:2181'
CONTROL_CENTER_CONNECT_CLUSTER: 'kafka-connect:8083'
CONTROL_CENTER_KSQL_KSQLDB1_URL: "http://ksql-server:8088"
CONTROL_CENTER_KSQL_KSQLDB1_ADVERTISED_URL: "http://localhost:8088"
CONTROL_CENTER_SCHEMA_REGISTRY_URL: "http://schema-registry:8081"
CONTROL_CENTER_REPLICATION_FACTOR: 1
CONTROL_CENTER_INTERNAL_TOPICS_PARTITIONS: 1
CONTROL_CENTER_MONITORING_INTERCEPTOR_TOPIC_PARTITIONS: 1
CONFLUENT_METRICS_TOPIC_REPLICATION: 1
`

Is this relating to a particular demo in this repository?

Hi rmoff,
I used the docker-compose.yml from demo-scene/community-components-only/docker-compose.yml as my base yml file, i just added an image for confluent-control-center and configure a build setting to use dockerfile for kafka-connect image, so that other connectors such salesforce will be installed.
I was able to build  and deploy the services without issue and able to access to connectors in control center, however after configuring a Salesforce Connector in control center, the connector won't deploy due to an error TimeoutException: Timed out waiting for a node assignment
I'm hoping you can help me with my issue.
Thank you.
Regards,
Rico

Hi,
I'm going to close this here because it's not related to one of the demos. The best place for community support is on:
→ Slack group: http://cnfl.io/slack
or
→ Mailing list: https://groups.google.com/forum/#!forum/confluent-platform
Thanks :)

authors: erdelacruz rmoff

repo: confluentinc/demo-scene


text:
Travis trigger 포인트 변경 필요

현재 pull request 시, travis로 docker image 빌드함.
그러나 travis 정책에 따르면, pull request가 보내진 브랜치로 빌드하지 않음

링크: https://docs.travis-ci.com/user/pull-requests/

그래서 pull request 시 travis 실행이 아닌, develop, master로 push 시 빌드하는 것으로 변경할 필요 있음.

Develop, master로 Pull request 시:

Client test (=npm test)
Server test

Develop, master로 Push 시:

Client image build (=docker build)
Server image build
Mysql image build
Deploy (=sshpass

중간에 travis.yml 파일 변경했습니다. #35
그런데 작업 중인 브랜치에선 변경 전 파일이 있다면 현재 develop 브랜치에 있는 파일로 변경해야 합니다.
commit도 필수로 해야합니다.
왜냐하면, 이전 파일인 경우, travis가 곧바로 build & deploy 과정을 거치기 때문에, 개발 서버의 내용이 의도치 않게변경될 수 있습니다. (경험담)
유의해주세요! :)

license: MIT


text:
0.5.2 breaks in webpack

0.5.1 works fine.
After upgrading to 0.5.2 webpack fails to build with these errors:
Module not found: Error: Can't resolve './create-query-service' in '/Users/daniel/project/node_modules/@connectrpc/connect-query/dist/esm'
Did you mean 'create-query-service.js'?
BREAKING CHANGE: The request './create-query-service' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

ERROR in ../../node_modules/@connectrpc/connect-query/dist/esm/index.js 15:0-105
Module not found: Error: Can't resolve './create-query-functions' in '/Users/daniel/project/node_modules/@connectrpc/connect-query/dist/esm'
Did you mean 'create-query-functions.js'?
BREAKING CHANGE: The request './create-query-functions' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

ERROR in ../../node_modules/@connectrpc/connect-query/dist/esm/index.js 16:0-64
Module not found: Error: Can't resolve './create-unary-functions' in '/Users/daniel/project/node_modules/@connectrpc/connect-query/dist/esm'
Did you mean 'create-unary-functions.js'?
BREAKING CHANGE: The request './create-unary-functions' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

ERROR in ../../node_modules/@connectrpc/connect-query/dist/esm/index.js 17:0-39
Module not found: Error: Can't resolve './utils' in '/Users/daniel/project/node_modules/@connectrpc/connect-query/dist/esm'
Did you mean 'utils.js'?
BREAKING CHANGE: The request './utils' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

ERROR in ../../node_modules/@connectrpc/connect-query/dist/esm/index.js 18:0-66
Module not found: Error: Can't resolve './use-transport' in '/Users/daniel/project/node_modules/@connectrpc/connect-query/dist/esm'
Did you mean 'use-transport.js'?
BREAKING CHANGE: The request './use-transport' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

ERROR in ../../node_modules/@connectrpc/connect-query/dist/esm/index.js 19:0-56
Module not found: Error: Can't resolve './create-unary-hooks' in '/Users/daniel/project/node_modules/@connectrpc/connect-query/dist/esm'
Did you mean 'create-unary-hooks.js'?
BREAKING CHANGE: The request './create-unary-hooks' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

webpack 5.88.2 compiled with 20 errors in 19953 ms

Manually editing node_modules/@connectrpc/connect-query/package.json and removing "type"="module" solves the issue
the client is generated with target=ts and then built to an internal module with typescript as a dual ESM/CJS package
I'm pinning the version to 0.5.1 for now

Hi @dstaver, I'm sorry you ran into this problem. We've investigated moving to Node16 module resolution to catch these problems but ran into some downstream dependency problems. In the meantime, I have a fix for this specific problem and will get that released soon.

🚀 Released in 0.5.3

authors: dstaver paul-sachs

repo: connectrpc/connect-query-es


text:
Router can double-check onchain the validity of subgraph-provided data

Problem
One potential security issue of writing our off-chain software/applications to rely on subgraph data is the potential damage a subgraph indexer (assuming subgraphs are not decentralized, which they currently aren't) could do to the network.
Currently the only true attack vector that exists here (afaik) is creating a fake XCall that would be picked up by routers and sequencer and result in an execute on the destination. A rogue subgraph indexer could index a fake XCall event for a large transfer, potentially stealing those funds from 1 unlucky router.
Any/all griefing vectors just seem like they would minorly inconvenience the network (e.g. lying about router liquidity) and couldn't do any real damage.
The likelihood of this event occurring given current climate/arrangement/partnership with subgraphs is virtually zero, but this is worth considering as a piece of tech debt and a security concern we'll want to insulate our network against.
Additionally, it is worth noting that, in the short-term, this problem could potentially occur if a subgraph mapping bug is incidentally created during a future update.
Ideas to solve this
Two potential solutions here:
Have the sequencer double-check on-chain whether the origin transfer exists. If it doesn't, the router network is potentially getting duped by a fake XCall. Not sure what action, if any, should be taken here. Perhaps a requirement for this task is to have some kind of top-level alert system / fire alarm?
Having the router double-check. Makes more sense since every router should act as their own local validator, but adds a heavy RPC provider requirement. Doesn't scale well. Best solution is to have a configuration option for performing this double-check; one that should be set to true if the router has a good RPC provider for the job.

P2

out of scope

authors: LayneHaber alexwhte

repo: connext/monorepo


text:
[txservice] Fallback not falling back

We need to deeply check the working principle of ethers.fallbackprovider and our implementation.
https://github.com/ethers-io/ethers.js/blob/master/packages/providers/src.ts/fallback-provider.ts#L476
In ethers.fallbackprovider, all the providers should return the result even though it is an error.
so it can return successful results totally by this line.
https://github.com/ethers-io/ethers.js/blob/master/packages/providers/src.ts/fallback-provider.ts#L490
we created our SyncProvider by overriding JsonRpcProvider. so we need to deeply check again if it returns results even though it is an error when it throws.
https://github.com/connext/nxtp/blob/main/packages/txservice/src/shared/syncProvider.ts#L118
https://github.com/connext/nxtp/blob/main/packages/txservice/src/shared/syncProvider.ts#L151
https://github.com/connext/nxtp/blob/main/packages/txservice/src/shared/syncProvider.ts#L155

In ethers.fallbackprovider, all the providers should return the result even though it is an error.
so it can return successful results totally by this line.

Yeah, I had the same concern a while back. But if you scan up a few lines, you should have your answer there:
https://github.com/ethers-io/ethers.js/blob/eb432aa1f44ad2cc268d000b266eae9b03db1d17/packages/providers/src.ts/fallback-provider.ts#L482
So, ethers is catching any errors I'm throwing in the SyncProvider send method. It throws the first error it gets back if all of the providers respond with an error.

authors: jakekidd wanglonghong

repo: connext/nxtp


text:
🛑 degelite.org is down

In 90966ea, degelite.org (https://degelite.org) was down:

HTTP code: 520
Response time: 7684 ms

Resolved: degelite.org is back up in 4c27886.

repo: constructions-incongrues/status


text:
🛑 anomouresbingo.partouze-cagoule.fr is down

In 295c23b, anomouresbingo.partouze-cagoule.fr (https://anomouresbingo.partouze-cagoule.fr) was down:

HTTP code: 502
Response time: 153 ms

Resolved: anomouresbingo.partouze-cagoule.fr is back up in 2fbcca4.


text:
🛑 artcomptantpourrien.constructions-incongrues.net is down

In 2f7020a, artcomptantpourrien.constructions-incongrues.net (https://artcomptantpourrien.constructions-incongrues.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: artcomptantpourrien.constructions-incongrues.net is back up in f9cd58b.

Resolved: artcomptantpourrien.constructions-incongrues.net is back up in 9c56d7d.

Resolved: artcomptantpourrien.constructions-incongrues.net is back up in d3a3526.


text:
🛑 thisisradioclash.org is down

In e4bf922, thisisradioclash.org (https://thisisradioclash.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: thisisradioclash.org is back up in a02d5d9.


text:
🛑 portainer.pastis-hosting.net is down

In 5238188, portainer.pastis-hosting.net (https://portainer.pastis-hosting.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: portainer.pastis-hosting.net is back up in aa7f3e3 after 2 hours, 3 minutes.


text:
🛑 arrachetoiunoeil.com is down

In a6015e6, arrachetoiunoeil.com (https://arrachetoiunoeil.com) was down:

HTTP code: 500
Response time: 13587 ms

Resolved: arrachetoiunoeil.com is back up in f9825fc after 54 minutes.


text:
fsGroup are not applied, when user-namespaces are enabled

Description
With latest rc5 it's not possible anymore, to use the spec.securityContext.fsGroup parameter together with spec.hostUsers: true. It seems, the parameter is just ignored.
Steps to reproduce the issue

deploy containerd2 rc.5 with latest kubelet
start a pod with hostUsers: true and fsGroup: 999
check inside of the pod the groups: id

Describe the results you received and expected
I would expect the following output within the pod (tested with prometheus container):
/prometheus $ id
uid=65534(nobody) gid=65534(nobody) groups=999,65534(nobody)

But get the following instead:
/prometheus $ id
uid=65534(nobody) gid=65534(nobody)

What version of containerd are you using?
containerd github.com/containerd/containerd/v2 v2.0.0-rc.5 05ee43a5fd671da57f60d760d11a4c7bb15c22bb
Any other relevant information
Exactly the same setup is working as expected with containerd2 rc.4
Show configuration if it is related to CRI plugin.
No response

@mathias-ioki I can't repro with that containerd version, latest main or other points in the history either. It always works as expected
Can you, please:

Provide a detailed step-by-step repro? Think more of a script than instructions to a human (not just things like "create a pod with this field", but also add pod yaml with what you want. The same for other steps). Try to not leave things out, unless it is an inconvenience to put them here. This saves a lot of time for people trying to debug it, having a repro is all for these bugs.
Can you please check if the same happens without userns in your setup?
Can you share which linux kernel and which runc/crun version you are using?

@rata thx for your answer. The important thing is indeed to test it together with user-namespaces. Without user-namespaces everything works fine and there is no issue.
Steps to reproduce:

Install containerd in version v2.0.0-rc.5
I'm using pretty much the default config, except for:

default_runtime is configured to use crun
SystemdCgroup = true
nri is disabled

Deploy CNI plugins (required to make use of user-namespaces)
Deploy kubelet with enabled user namespacesfeatureGates:
  UserNamespacesSupport: true

Deploy the following pod (minimal example)apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostUsers: false
  securityContext:
    fsGroup: 900
  containers:
    - name: nginx
      image: nginx:mainline-alpine-slim

Check the group assignments inside the podcrictl exec -ti $(crictl ps -q --name nginx) id

Expected result: group-id 900 is part of the groups list
Received result: group-id 90 is * not* part of the groups list
Versions I'm using:

kernel version: tested with 6.5.0-21-generic and 6.8.0-45-generic
runc/crun version: tested with crun 1.15 and 1.17
CNI version:  tested with 1.5.1 and 1.6.0
I'm using a standalone kubelet on the same node, tested with 1.30.2 and 1.31.1

In the end, I see the issue only with containerd v2.0.0-rc.5, no matter if I change the versions of the other components. As soon as I switch back to containerd v2.0.0-rc.4 and keep all other services as they are, it's working as expect.
I did also a test with runc v1.2.0-rc.3 together with containerd v2.0.0-rc.5 right now. It's also not working, but this time the pod doesn't even come up, as there are filesystem permission issues in the container.
Same here: As soon as I switch back vom rc.5 to rc.4, it's working again.

@mathias-ioki thanks! I was trying with userns, I think maybe I mixed up rc.4 and rc.5 when testing? I'm unsure.
Now I can repro. It is already fixed in main, though, so that is great :)
The thins is, this commit was added in rc5: ee0ed75d648aca5bce1b3e94b9216bbd2fb8cc3b. That completely changed how the userns was created. Before that commit, runc was creating the userns, after that commit, containerd is creating it and runc joins it. What was missing is the setting to allow to set groups, that was fixed here 347423a114982700af57f13dde7dd83b35b30b23, that didn't made it into rc.5. With that commit, the setgroups works fine, and that fixes this issue too. That is why in main it wasn't happening.
While I was there, I had a look at: https://pkg.go.dev/syscall#SysProcAttr to see if there is any other setting we might be missing. I think we are fine, although runc is using setsid() and we are not, I think it is fine, as runc will run it when creating the container (it doesn't matter it is joining an already created userns, IIUC).
I think we are fine, then, with the settings for the userns. But I'll just cc @fuweid (that wrote the PR to make containerd the one that creates the userns).
@fuweid in PR https://github.com/containerd/containerd/pull/10607 we missed the setgroups setting (it's not deny by default, I think, but as in golang the bools are false by default, it caused that to be deny by default). That is already fixed in main here: 347423a114982700af57f13dde7dd83b35b30b23. I was checking https://pkg.go.dev/syscall#SysProcAttr to see if we missed something else, and I think we are fine. I was checking the runc code, in nsexec.c, that is what creates the namespaces, and I think we are fine.
Can you have a look too, just in case we are missing some other setting?
@mathias-ioki thanks a lot for the report! Feel free to have a look you too, in case you find something! :)
After that, I think we can close this issue, it is fixed in main already :)

@rata thank you for the feedback and the detailed explanation! I've just tested the latest nightly build and can confirm that it's working fine. I can't reproduce the mentioned issue with nightly. If nothing else is missing, we can close the issue.

Awesome, thanks! Yes, please close the issue (I'm not a maintainer here :))
Please continue testing this if you can and cc me in any issues with userns that you find :)

authors: mathias-ioki rata

repo: containerd/containerd


text:
Can't compile Python modules from containerd API .proto files

I'm trying to generate working Python modules from the containerd API .proto files as to be found here: https://github.com/containerd/containerd/tree/release/1.3/api (API version 1.3; same for API 1.2). These .proto files contain references to containerd API proto files, such as in api/events/container.proto:
import weak "github.com/containerd/containerd/protobuf/plugin/fieldpath.proto";

This import is actually located in ./protobuf/plugin/fieldpath.proto, as opposed to (vendor/)github.com/containerd/.... A simple -I ... does not work in this context, as the import uses a "github"-absolute path, whereas the corresponding sources aren't located inside the vendor branch. The Python grpc protocol compiler resolves such import paths in form of chopping down the full import path into parts and then searching its -I ... include directories.
Simply copying over the sources inside vendor/github.com/... will cause runtime errors when trying to use the generated Python modules: this is because the grpc compiler considers the same containerd API .proto file in two locations (paths) to be separate instances. In consequence we get duplicate modules which unfortunately now try to register with grpc for the same protocol element names. Consequently, the GRPC Python runtime thus throws an error and terminates.
How can I correctly get this resolved when using python3 -m grpc.tools.protoc ...?

After some more work on automatically taking only the necessary .proto files for the API and a few dependencies, rewriting problematic import aliases in this process, and ensuring to strategically place dependency .protos taking into account which ones are satisfyable at runtime by PyPI packages, I got this finally working on Ubuntu arm64 as well as amd64.

https://github.com/siemens/pycontainerd upstream fixes PR sent.
no need for any changes/support in the containerd project.

The difficulty in producing working Python gRPC API packages is due to dependencies and aliasing. While this doesn't matter to Golang where (almost) everything ends up in a single binary anyway, it creates a lot of friction for Python package(r)s. That's because there are PyPI grpcio and protobuf packages. Previously there was unwanted vendoring for these, which for some strange reasons didn't trigger runtime issues on some OS/package versions on amd64, but then triggered them fatally on arm64.


text:
cmd/ctr: stablize output of snapshot tree

Preserves the order of the tree output between each execution. Slightly
refactored the behavior to be more "object oriented".
Signed-off-by: Stephen J Day stephen.day@docker.com

Codecov Report

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

@@           Coverage Diff           @@
##           master    #1914   +/-   ##
=======================================
  Coverage   47.29%   47.29%
=======================================
  Files          89       89
  Lines        8830     8830
=======================================
  Hits         4176     4176
  Misses       3968     3968
  Partials      686      686

Flag
Coverage Δ

#linux
50.66% <ø> (ø)
:arrow_up:

#windows
42.24% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

LGTM

authors: codecov-io crosbymichael stevvooe


text:
fix stats for no-stream/stream

fixing https://github.com/containerd/nerdctl/issues/1198
Signed-off-by: fahed dorgaa fahed.dorgaa@gmail.com

The CPU usage shown in nerdctl stats seems still too much larger than what is shown in systemd-cgtop, but we can fix it in a separate PR.
I'll open an issue.

https://github.com/containerd/nerdctl/issues/1240
@fahedouch

nerdctl stats shows too much CPU usage than actual #1240
@fahedouch

thanks for opening this @AkihiroSuda

authors: AkihiroSuda fahedouch

repo: containerd/nerdctl


text:
Add support for CDI devices to device flag

This change adds support for specifying fully-qualified CDI device names in the --device flag. This allows the Container Device Interface (CDI) to be used to inject devices into container being run.
This mirrors the support recently added to ctr (see https://github.com/containerd/containerd/pull/8525) and under review for the Docker CLI (see https://github.com/docker/cli/pull/4084).
Note that this assumes that the CLI is used to inject devices and additional work would be required for other mechanisms such as compose files.

/cc @mikebrow
Do you know who should have a look at this? Changes are similar to https://github.com/containerd/containerd/pull/8525.

Needs rebase

Sorry, needs another rebase

ping @elezar

I will look into this today.

For the first the question I would have is whether the testdata/cdi directory is NOT accessible in some way when running rootless.

This might be being fixed in:

https://github.com/containerd/nerdctl/pull/3213

For Docker compatibility, we would need to enable the cdi feature that has been available in Docker since v25. We would also need to configure the Docker daemon to use the same CDI folder as for the tests.

Yes, you can update /etc/docker/daemon.json and sudo systemctl restart docker here
https://github.com/containerd/nerdctl/blob/0c3c28a829d64ca0f8007a86299a9b28c533e7bb/.github/workflows/test.yml#L225

Needs rebase

@elezar Do you plan to rebase this ?

@elezar Do you plan to rebase this ?

Yes, I do need to get to it. I have been focussing on a security issue of late. I will pick this up again in the next couple of days.

CI failing

Needs rebase

Moved to v2.1 milestone

authors: AkihiroSuda elezar


text:
Bump version to 1.10.0

This version includes a new GICv3 for macOS and a new API for using qcow2 disks based on the imago crate. I think these changes justify bumping the minor number too.

LGTM!

authors: slp tylerfanelli

repo: containers/libkrun


text:
Questions about naming of pulled images

(From #1112.)
AFAICT the outcome of #1085, apart from pulling the right image, which is clearly correct, is that pulled name@sha256:digest images are named in the storage as name:none (where none is an actual tag string, not “missing”, and the digest not recorded). (I can now confidently refactor the code to do this inside the imageParts abstraction without breaking anything, but that exposes how irregular the code doing this is.)

Is using the explicit none tag  Is that intentional? If so, why is it necessary?
Is dropping the digest and not recording it in the storage intentional? If so, why is it necessary? (Looking at Image.RepoDigests, it forms a series of name@digest values, all with the same Image.image.Digest value — but a single image (single image ID == config digest) can exist with multiple different manifest digests. Shouldn’t the original values be recorded when pulling, and reproduced in RepoDigests in podman inspect?)

Everyone has been deferring this to @baude .

Also maybe @nalind for the questions about recording original pulled digests in c/storage.

The none tag being used is more or less what docker shows.  Realistically, I think the tag is supposed to be blank.  In docker, iirc, if the tag is blank, then it renders  in output.  I can relook at this upon return from PTO if you like ... the none for now however is on purpose.
The second point you raise looks like a bug.  Can you paste an example of whats missing/what should be there and I will look to fix it.

(Enjoy your PTO; this can absolutely wait.)

The none tag being used is more or less what docker shows.

Where?

Realistically, I think the tag is supposed to be blank. In docker, iirc, if the tag is blank, then it renders in output. I can relook at this upon return from PTO if you like ... the none for now however is on purpose.

I suspect that this is strongly related to the second point actually - e.g. Docker, when pulling an image, always records a digest reference (whether pulling by tag, digest, or “all tags”), but records a tagged reference only if a tag is known (pulling by tag, or “all tags”). It’s not that a tag is “blank” when pulling by digest (which would still be different from having a none string indistinguishable from an actual :none tag), it’s that there is no tagged version of the name recorded at all.

The second point you raise looks like a bug. Can you paste an example of whats missing/what should be there and I will look to fix it.

E.g. see the “@digest” cases in  TestRefNamesFromPossiblyUnqualifiedName, the digest the user used to pull the image is not recorded by libpod at all; and it is not recorded by storage.Image either AFAICS, because storage.Digest (and storage.Image.BigDataDigests[storage.ImageDigestBigDataKey]) can only store one value.  (@nalind am I missing anything?) That is a problem because…
… a single image (single config digest) can be pulled many times from many places, with many different manifest digests (e.g. depending on how the compressed version of the layers changes as the compression implementation changes).  Docker records every single name@digest reference which was actually used, and shows them all in docker inspect’s RepoDigests. As described above, Image.RepoDigests tries to compose similar results without actually having the name@digest pairs (and may thus return name@digest references which never existed at the registries).

@baude @mtrmac @nalind, ping.

@baude @mtrmac @nalind Lets revit this,  Is this worth having a bluejeans session to discuss?

sure, anytime

@mtrmac @baude Whats going on with this issue?

@baude What is the state of this Issue now?

Per @mtrmac we have removed most if not all cases of the literal :none tag.
I think we're good to close.

(Our matching logic for ImageParts is still a problem, but we can replace that at a later date)

authors: baude mheon mtrmac rhatdan vrothberg

repo: containers/libpod


text:
troubleshooting: fix useradd no-log-init argument

--log-no-init should be --no-log-init
# useradd --log-no-init -u 99999000 -g users newuser
useradd: unrecognized option '--log-no-init'
Usage: useradd [options] LOGIN
       useradd -D
       useradd -D [options]

Options:
  -b, --base-dir BASE_DIR       base directory for the home directory of the
                                new account
  -c, --comment COMMENT         GECOS field of the new account
  -d, --home-dir HOME_DIR       home directory of the new account
  -D, --defaults                print or change default useradd configuration
  -e, --expiredate EXPIRE_DATE  expiration date of the new account
  -f, --inactive INACTIVE       password inactivity period of the new account
  -g, --gid GROUP               name or ID of the primary group of the new
                                account
  -G, --groups GROUPS           list of supplementary groups of the new
                                account
  -h, --help                    display this help message and exit
  -k, --skel SKEL_DIR           use this alternative skeleton directory
  -K, --key KEY=VALUE           override /etc/login.defs defaults
  -l, --no-log-init             do not add the user to the lastlog and
                                faillog databases
  -m, --create-home             create the user's home directory
  -M, --no-create-home          do not create the user's home directory
  -N, --no-user-group           do not create a group with the same name as
                                the user
  -o, --non-unique              allow to create users with duplicate
                                (non-unique) UID
  -p, --password PASSWORD       encrypted password of the new account
  -r, --system                  create a system account
  -R, --root CHROOT_DIR         directory to chroot into
  -P, --prefix PREFIX_DIR       prefix directory where are located the /etc/* files
  -s, --shell SHELL             login shell of the new account
  -u, --uid UID                 user ID of the new account
  -U, --user-group              create a group with the same name as the user
  -Z, --selinux-user SEUSER     use a specific SEUSER for the SELinux user mapping

/approve
/ok-to-test

Thanks @manics for you PR.  But you must sign it.
git commit -a -s --amend
git push --force

Patch LGTM

@rhatdan done.

Saving the planet since this PR is not causing the test to fail, merging manually.

/lgtm

/hold

unfortunately the tests need to be fixed ...

@baude, this isn't something for the submitor @manics to worry about right?  It's unrelated to this PR me thinks.

Yes unrelated.

@cevich Is this related to the crun issues you were talking about yesterday?

yes

/lgtm

/hold cancel

authors: TomSweeneyRedHat baude cevich manics mheon rhatdan


text:
Fix output message for "podman start" command.

Fix output message for "podman start" command: it prints short container ID instead of full one.
Signed-off-by: Boris Klimenko 2@borisklimenko.ru

/assign @vrothberg

/ok-to-test

Changes LGTM, I'll leave it to others to decide on the output change.
Tests aren't happy, but I don't think it's related to this PR.

I'll leave it to others to decide on the output change.
To be clear - all the other actions with containers return full ID now, and only "podman start" with stopped container returns id from CLI. For example:
root@das:~/repos# #container stopped root@das:~/repos# podman start 9a575db48901 9a575db48901 root@das:~/repos# #container already started on previous step root@das:~/repos# podman start 9a575db48901 9a575db48901410d333c4f844c3fa5cdc2257520e941c7b30de6955110ff95ae

Thanks for contributing, @dasmfm!
Can you elaborate why this change is needed? The commit message states that this is a "fix" and I wonder if there's a bug. One way or another, the commit message should be more verbose and explain the motivation to perform the change, so future generations can understand what happened.

@vrothberg change commit message, and I already described reasons here: https://github.com/containers/libpod/pull/4270#issuecomment-542550680

thanks for the patch.  The code LGTM.
Could you please move the explanation to a new line in the commit message?
The first line should be a concise description of the change itself, with more details included in the body.  I'd suggest something like:
start: print full container ID

Now the "podman start" command prints the full ID and has the same
behaviour as other commands.

@giuseppe sure, done.

Sure, LGTM
/lgtm

authors: TomSweeneyRedHat dasmfm giuseppe jwhonce mheon vrothberg


text:
Allow security-opts to be parsed even if container is --privileged

Signed-off-by: Daniel J Walsh dwalsh@redhat.com

lint if biting you @rhatdan

These validation errors have nothing to do with this PR.
@mheon PTAL

LGTM

Force merging.

authors: TomSweeneyRedHat rhatdan


text:
core: add support setting for MTU on macvlan interface from netavark config

Netavark config accepts MTU as network option so allow users to
configure the same for macvlan interface.
See https://github.com/containernetworking/plugins/blob/master/plugins/main/macvlan/macvlan.go#L181
Follow up PR to: https://github.com/containers/netavark/pull/111
Closes: https://github.com/containers/netavark/issues/152

@Luap99 @mheon @baude This should close MTU setup for macvlan.

LGTM but can you add a test?

Sure adding a test.

@Luap99 Merge me please newly added test verifies the change.

/lgtm

repo: containers/netavark


text:
Outdated container examples

Bug description
Our container images use an outdated image (fedora eln), and we should instead point to upstream examples which have tests: https://gitlab.com/bootc-org/examples
Operating system
mac m1
Version
next (development version)
Steps to reproduce
No response
Relevant log output
No response
Additional context
No response

Closed by https://github.com/containers/podman-desktop-extension-bootc/pull/222

https://github.com/containers/podman-desktop-extension-bootc/pull/222 merged, closing.

authors: cdrage vrothberg


text:
Open source | Fix markup on volume updating page

fixed in v1.0.7-rc.4

repo: containerum/ui


text:
the --namespace arg in helm template doesn't affect maesh-mesh and maesh-controller pdb

We install all helm-charts with
helm template <path/to/chart> --name <name> --namespace=<namespace> | kubectl apply -f -

To pass the --namespace value to the chart, there is build-in variable, called .Release.Namespace.
In all objects in the helm-chart this value is used by all k8s objects instead of the PDB-definition for maesh-mesh and maesh-controller.
This PR solve this issue:
https://github.com/containous/maesh/pull/256

Closed by #256

authors: bavarianbidi dtomcej

repo: containous/maesh


text:
Add Support for subPath in data volumeMount

If the PVC is requesting a shared PV it would be nice to not give traefik full root level access to the volume. (Useful if the PVC is accessing a nfs volume, for example)
This would add the option to limit traefik to an arbitrary subPath on a volume.

@Jawastew Thanks for your contribution
Could you please rebase and bump chart version.

Done. I hope I did it correctly, this is my first open source pull request :)

As the PR comes from an organization, our bot, due to a weird limitation from GitHub, is not able to merge this pull request.

authors: Jawastew ldez mmatur

repo: containous/traefik-helm-chart


text:
Content-Type "text/event-stream" not propagated properly with version 1.1.0-rc3

Hello,
The Content-Type "text/event-stream" seems not to be propagated properly with version 1.1.0-rc3
Here is my test case:
I use a simple python server like that one:
from flask import Response
from flask import Flask
app = Flask(__name__)

@app.route('/hello')
def hello():
    return Response("Hello\n", mimetype='text/event-stream')

if __name__ == "__main__":
    app.run(host='0.0.0.0', port=8085)

when calling the application without traefik, the content type is 'text/event-stream' as expected:
root@9a41b8a25543:/oca# curl -i localhost:8085/hello
HTTP/1.0 200 OK
Content-Type: text/event-stream; charset=utf-8
Content-Length: 6
Server: Werkzeug/0.11.10 Python/2.7.9
Date: Tue, 08 Nov 2016 15:17:54 GMT

Hello
root@9a41b8a25543:/oca#

but when I use traefik in between to redirct port 8085 to 80, the Content-Type then become 'text/plain'.
root@9a41b8a25543:/oca# curl -i localhost:80/hello
HTTP/1.1 200 OK
Date: Tue, 08 Nov 2016 15:22:55 GMT
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked

Hello

I also tested with the fix #592 and this is not working either  (but this case was working with version 1.1.0-rc2 which doesn't contains fix #592 )
Notice that other Content-type seems to work fine. for instance:
...
return Response("Hello\n", mimetype='application/json')
...

is working fine
root@9a41b8a25543:/oca# curl -i localhost:80/hello
HTTP/1.1 200 OK
Content-Length: 6
Content-Type: application/json
Date: Tue, 08 Nov 2016 15:26:04 GMT
Server: Werkzeug/0.11.10 Python/2.7.9

Not sure yet, but I think this is not working when "Content-Type" contains also the charset like that:
"text/event-stream; charset=utf-8"

I'll close the issue due to inactivity but feel free to re-open if needed.

authors: git-oca ldez

repo: containous/traefik


text:
Fixes formatting issue in documentation

Thanks for calling it out in #75 @OldhamMade - and sorry for taking quite some time to actually do anything about it :wink:
Fixes #75.

Pull Request Test Coverage Report for Build 800ac27be43dd7547dc11ef7e89aaf32c99dbe97-PR-84

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

Totals

Change from base Build f1977feea79a82ca33a353af1de139137d3ce33b:
0.0%

Covered Lines:
108

Relevant Lines:
136

💛  - Coveralls

authors: coveralls floriank


text:
Accessing dynamic routes posts with App Router and Notion

Hi,
I can't access my notion posts (404 error) with the following dependencies and the App router
"next-contentlayer": "0.3.2",
"contentlayer": "0.3.2",
"react": "18.2.0",
"react-dom": "18.2.0",
I still can fetch the content of the html in the home page

but when I go in localhost:3000/posts/id, I got a 404 error.
// app/page.tsx
import Link from "next/Link";
import { compareDesc, format, parseISO } from "date-fns";
import { allPosts, Post } from "contentlayer/generated";

function PostCard(post: Post) {
  return (

        <Link
          href={post.url}
          className="text-blue-700 hover:text-blue-900 dark:text-blue-400"
        >
          {post.title}
        </Link>

      <time dateTime={post.date} className="mb-2 block text-xs text-gray-600">
        {post.date && format(parseISO(post.date), "LLLL d, yyyy")}
      </time>

*]:mb-3 [&>*:last-child]:mb-0"
        dangerouslySetInnerHTML={{ __html: post.body.html }}
      />

  );
}

export default function Home() {
  const posts = allPosts
    .filter((post) => post.date !== undefined)
    .sort((a, b) =>
      compareDesc(new Date(a.date as string), new Date(b.date as string))
    );

  return (

        Next.js + Contentlayer Example

      {posts.map((post, idx) => (
        <PostCard key={idx} {...post} />
      ))}

  );
}

//app/posts/[slug]page.tsx
import Head from "next/head";
import Link from "next/link";
import { format } from "date-fns";
import { allPosts } from "contentlayer/generated";

const PostLayout = ({ params }: { params: { slug: string } }) => {
  console.log(params);
  const post = allPosts.find((post) => post._id === params.slug);

  // If post is not found, render a "Post not found" message
  if (!post) {
    return
Post is not found
;
  }

  return (
    <>

        <title>{post.title}</title>

          <Link href="/">

              Home

          </Link>

{post.title}

          <time dateTime={post.date} className="text-sm text-slate-600">
            {format(new Date(post.date ?? "1970-01-01"), "LLLL d, yyyy")}
          </time>

    </>
  );
};

export default PostLayout;

//.contentlayer/generated/Post/_index.mjs
// NOTE This file is auto-generated by Contentlayer

import _23486c01Af13_473dB303_4f27098bb180 from './_23486c01-af13-473d-b303-4f27098bb180.json' assert { type: 'json' }
import _2051e64aEe51_4704_86be_32895862d1ca from './_2051e64a-ee51-4704-86be-32895862d1ca.json' assert { type: 'json' }
import dd74f7ac_6958_4173B58aCbba2d570967 from './dd74f7ac-6958-4173-b58a-cbba2d570967.json' assert { type: 'json' }

export const allPosts = [_23486c01Af13_473dB303_4f27098bb180, _2051e64aEe51_4704_86be_32895862d1ca, dd74f7ac_6958_4173B58aCbba2d570967]

When I go to http://localhost:3001/posts/23486c01-af13-473d-b303-4f27098bb180 , I've got a  404 error
Thanks for helping me out

Problem solved:
I had to remove the  element within  Link

repo: contentlayerdev/contentlayer


text:
Adding a roll back feature with some refactoring

You can rollback it like this.
cf blue-green-rollback appName version (e.g. g1 or g2)

After the rollback, the application won't stop for debugging.
Please review and accept this pull request.

Sorry for this mistake. I try to send pull request for folked repository

Please forget or remove this pull request.

repo: contraband/autopilot

license_source: bigquery


text:
Reexports from CTDirect

@PierreMartinon shouldn't we reexport OCPInit (and maybe some other things) from CTDirect.jl?

Hi there. To clarify on the current state of the initialization:

OCPInit is the one creating the generic initialization structure (ie. functions) and is in CTBase. It should be reexported from CTDirect, I'll need to check. This method call has been made optional in most cases, passing directly the arguments e.g. init=sol instead of init=OCPInit(sol). Ideally at some point it will become a purely internal function ?
DOCP_initial_guess takes such an OCPInit and builds the (vector) initial guess for the discretized problem. It is currently nor exported since it is not normally called by the user: the init is rather passed to solve(), or directTranscription() / setDOCPInit() if you want to interact with the NLP problem directly.

I have the same question about being purely internal in another package and I don't have the answer.

I just checked, CTBase.OCPInit() is exported in CTDirect.

@PierreMartinon shouldn't we reexport OCPInit (and maybe some other things) from CTDirect.jl?

So, @PierreMartinon, yes or no?

I just checked, CTBase.OCPInit() is exported in CTDirect.

o_O

It is OptimalControlInit now, no?

Yup

authors: PierreMartinon jbcaillau ocots


text:
🛑 MPS - CAMUNDA is down

In 3314df2, MPS - CAMUNDA ($MPS_CAMUNDA) was down:

HTTP code: 503
Response time: 573 ms

Resolved: MPS - CAMUNDA is back up in bc29689 after 6 minutes.

repo: conuti-das/status-lfrcs


text:
🛑 MPS - TESTPROCESS is down

In ebf7796, MPS - TESTPROCESS ($TESTPROCESS_URL) was down:

HTTP code: 200
Response time: 686 ms

Resolved: MPS - TESTPROCESS is back up in ff572f5 after 6 minutes.


text:
🛑 MPS - TESTPROCESS is down

In 6924b78, MPS - TESTPROCESS ($TESTPROCESS_URL) was down:

HTTP code: 200
Response time: 628 ms

Resolved: MPS - TESTPROCESS is back up in 0c367d0 after 1 hour, 18 minutes.


text:
🛑 MPS - TESTPROCESS is down

In d450407, MPS - TESTPROCESS ($TESTPROCESS_URL) was down:

HTTP code: 200
Response time: 547 ms

Resolved: MPS - TESTPROCESS is back up in aa485ea after 2 hours, 42 minutes.


text:
🛑 MPS - TESTPROCESS is down

In c2b62d1, MPS - TESTPROCESS ($TESTPROCESS_URL) was down:

HTTP code: 200
Response time: 847 ms

Resolved: MPS - TESTPROCESS is back up in 90d9472 after 11 hours, 44 minutes.

repo: conuti-das/status-nbsap


text:
Generating Changelog When Multiple Tags Available

For the past month I've been looking into an issue that was filed against semantic-release-gitlab-notifier by @bahmutov - https://gitlab.com/hutson/semantic-release-gitlab-notifier/issues/1
@bahmutov describes a workflow where semantic-release-gitlab (the tool he uses for generating new releases for a GitLab-based project) is invoked only when a new tag is created on the master branch of his repository. His goal is to collect several commits into the master branch, and then, when he's ready to publish a new version of his package to the npm registry, he tags the master branch with a tag beginning with the word release.
You can see the tag pattern used to invoke the deploy stage of his CI pipeline here.
The semantic-release-gitlab tool correctly generates a new version based on the commits since the last semantically valid tag, correctly ignoring the release tag created manually by @bahmutov.
However, when semantic-release-gitlab invokes conventional-gitlab-releaser (my fork of conventional-github-releaser) to generate release notes, it fails.
It comes down to the call to conventionalChangelog, from within conventional-gitlab-releaser, which fails to return a changelog. Therefore, there's nothing to post to GitLab.
Based on my testing so far, it seems the transform function is matching against the manually created release tag, using the manually created release tag as the version of the latest commit, and that is causing conventional-changelog-writer to fail to generate a changelog.
If I modify the transform function for conventional-gitlab-releaser to match only the semantically valid version tag created by semantic-release-gitlab the changelog is generated correctly, and a release note is posted to GitLab.
I have a pending merge request against conventional-gitlab-releaser that demonstrates the required change - https://gitlab.com/hutson/conventional-gitlab-releaser/merge_requests/1/diffs
I haven't accepted it yet because I'm not quite sure what the purpose of the transform function is, or whether my change is the best approach.
I wanted to get your input before proceeding.

Hi @hbetts , I have sent you an invite to the team. Let me know if you need any help.

Thank you @stevemao. I was able to get setup quite easily.

Closed by #34

authors: hbetts stevemao


text:
google cloud compute engine tf setup for gpu size 4

This includes:

the configs for experiments on Compute Engine, Google Cloud GPU 4-32 nodes
new docker builds across that setup to fix the CUDA_VISIBLE_DEVICES bug
(mostly) complete experimental data for the size 4 runs (all except for quicksilver)
updated build script to install drivers and nccl fast socket to the VM
adding base modules, with us-central1-c selected as the zone (how I got the GPU)

I was originally just going to test tonight, and felt fairly confident in the configs and decided to do full runs (5 iters, up to 15 mins each) for each confidently working. The entire experiment was just under 2 hours. We have a custom terraform setup and VM image that spins up in minutes (granted there is availability) and provides a fully working flux cluster with singularity, oras, and our application containers. The bugs (that I think were present across any experiments that use Singularity and drivers) were hard to figure out, but I'm separating that from the setup itself, which I've very happy with. I'll state again that these custom terraform deploys are the fastest and easiest ways to deploy infrastructure on Google Cloud, and probably on AWS and Azure if we had decided to use them. With all my testing and debugging of different VMs, it has been so easy to bring up and down entire new clusters! Points of discussion before moving on to size 8:

if the configs look ok, generally. We can discuss them in this first consolidated file (making comparison easy) and I'll move into subsequent sized directories.
I think we should remove any applications that cannot use GPU (e.g., amg - I don't see we are getting improved data from the CPU setup, so it's just burning money. The one variation might be that this setup has the nccl fast socket installed, but if it's only for GPU (and we aren't using them) no point.
For OSU, the cuda worked for the point to point benchmarks. I ran D D and H H, and H H was much better. I have results for both but I'd like to suggest we do H H.
I checked GPU utilization for all apps - we hit all 8, consistently, and (it appears) well! :partying_face:
The only two that didn't work perfectly were OSU (expected, because I had issue with all reduce before) and quicksilver. Quicksilver, akin to all reduce, had the error that "smelled like MPI not cuda aware." It's such a slow running app I didn't want to wait minutes to see if it would continue running.
Lammps didn't run for the larger problem size (pooped out toward the end) but was ok for the smaller one. So (I think) we should be OK moving forward.
I ran the single-node benchmarks with and without sudo. I think we should run with sudo (and I'll nix the without).
For mixbench, I suggest we leave out the little -n. The wrapper seems to be working as expected, and when I remember testing this on larger clusters having -n doesn't scale well (it starts to take a really long time).

Let's discuss the above. When we are happy with decisions I'll move on to the other 3 cluster sizes.

Answering some of my comments above:

if the configs look ok, generally. We can discuss them in this first consolidated file (making comparison easy) and I'll move into subsequent sized directories.

These were derived from the equivalent GPU setups on other clouds, and should be OK. Someone said my amg params were off, but I confirmed this is what was used on cyclecloud.

I think we should remove any applications that cannot use GPU (e.g., amg - I don't see we are getting improved data from the CPU setup, so it's just burning money. The one variation might be that this setup has the nccl fast socket installed, but if it's only for GPU (and we aren't using them) no point.

AMG is now using GPU, and didn't work at the larger problem size on 4 nodes. I'll test the larger problem size on the larger cluster, and worst case do the slightly smaller size.

For OSU, the cuda worked for the point to point benchmarks. I ran D D and H H, and H H was much better. I have results for both but I'd like to suggest we do H H.

We are doing all three. D D is the worst, H H is slightly less offensive, and without GPU is the best.

I checked GPU utilization for all apps - we hit all 8, consistently, and (it appears) well! 🥳

:muscle:

The only two that didn't work perfectly were OSU (expected, because I had issue with all reduce before) and quicksilver. Quicksilver, akin to all reduce, had the error that "smelled like MPI not cuda aware." It's such a slow running app I didn't want to wait minutes to see if it would continue running.

I waited over 10 minutes and didn't see progress, saved the output file and moved on. I won't be running this for larger sizes.

I ran the single-node benchmarks with and without sudo. I think we should run with sudo (and I'll nix the without).

We will be running them with sudo

For mixbench, I suggest we leave out the little -n. The wrapper seems to be working as expected, and when I remember testing this on larger clusters having -n doesn't scale well (it starts to take a really long time).

I will be leaving out little N.
I added back in the multi-gpu-models, which appear to actually work and output final results (and have great GPU utilization) despite some error messages at the end.
I'm also removing empty data directories and .gitkeep files for this PR (chore/cleanup).

repo: converged-computing/performance-study


text:
[Question / Feature-request] - improve ignoredGroups with wildcard

licenseTools {
    ignoredGroups = setOf("com.foo.",
            "com.foo.android.bar",
            "com.foo.android",
            "com.foo.bar")
}

Is there a way to filter every groups which begin with "com.foo" ?
like :
licenseTools {
    ignoredGroups = setOf("com.foo.*")
}

Hi, @mirecalu
I would like to know in what case you would like to use the wild card.
(e.g. Ignoring androidx libraries, or inhouse libraries ...)

Hi @kazyApp,
The case would like to igore inhouse libraries.
We have many inhouse libraries, so it could be nice to create a filter in the gradle conf to avoid adding "skip" on every inhouse lib into the yml file.
What do you think ?

authors: kazyApp mirecalu

repo: cookpad/LicenseToolsPlugin


text:
PlaysInline does not work on iOS for Vimeo vidoes

Current Behavior
I have playsInline={true} set for all of our videos in our Ionic React app (we use Vimeo for all of our vidoes). If I enable autoplay, the videos play inline immediately on Android, which is perfect. However, on iOS, the video loads and then goes full screen immediately. If I change autoplay to false, on both iOS and Android, the video goes full screen when you press play.
Expected Behavior
I expect the video to play inline as requested.
Steps to Reproduce

Set Vimeo videos as playsInline={true} in an Ionic React app.
Set playing={true}
View the video on Android, note that it plays inline
View the video on iOS, note that it opens full screen
Change playing={false}
View the video on iOS or Android
Press play
Note the video opens full screen

Environment

URL attempting to play: Mobile app
Browser: N/A
Operating system: iOS

Other Information
N/A

the docs mention it's all lowercase playsinline. could you try that out?

authors: bounddigital luwes

repo: cookpete/react-player


text:
Update Pocketbase automatic please

Update Pocketbase automatic please

repo: coollabsio/coolify


text:
Ignore vendor folder for linter

Hi @coopnorge/developer-productivity
in one of the legacy projects, techdocs workflows start catching the vendor folders for the linting and ofc its breaks.
We cannot delete the vendor folder since it's cupeled with internal integration tests.
Workflow output:
**vendor**/github.com/spaolacci/murmur3/README.md
**vendor**/github.com/philhofer/fwd/README.md:6 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2]

Is there a way to configure folders for exclude?

We are using https://github.com/dorny/paths-filter to drive what files are validated. I'm not sure if this actions has support for excluding files. We still want to validate all markdown files written by us, not only the ones in the docs/ directory. Here is a snippet of the current implementation:
https://github.com/coopnorge/github-workflow-techdocs/blob/5ed11418d390a9af2a8ddb0d6af16f492627fa12/.github/workflows/techdocs.yaml#L43-L54
A while back we also decided that we should stop vendoring dependencies to avoid these cases. Version locking should be enough.
The easiest fix here is to stop vendoring.

authors: LinMAD nhhagen

repo: coopnorge/github-workflow-techdocs


text:
Portraits are added twice

@thebardsrc When using the Join event the portraits are added twice, not sure why.
Also they are not added to the PortraitHolder anymore, but to the positions themselves. Maybe that's intended, not sure.

When using the Join event the portraits are added twice, not sure why.

Hm I didn't see that myself in testing, but i'll check it out

Also they are not added to the PortraitHolder anymore, but to the positions themselves. Maybe that's intended, not sure.

Custom portrait scenes were being added to the position themselves, I copied  how that that method with the new PlainPortrait scene.

ohhh ok. so I dug through more, because you really had me confused with that PortraitHolder statement because I didn't remember touching anything about that... It got removed from the code entirely during one of the initial Godot 4 conversion changes
which, honestly, is most of the change i wanted to make to begin with, I want them in a node like PortraitHolder for the character sorting and other things. so, perfect, it's already there, I just have to put them back on it

authors: Jowan-Spooner thebardsrc

repo: coppolaemilio/dialogic


text:
fix(lang) Brazilian Portuguese

Backpack (en_US) → Mochila (pt_BR)
Description or log

[x] In fact, I translated the entire file from the scratch since the previous translation was really poor.

Username, profile link or ID
Diego R. V. - @MinecraftForge i18n Proofreader - Crowdin

@wenlfs @eduardogomesv Could you comment on this PR?

@asiekierka I may write down and explain all the errors in previous translations, if necessary.

authors: DaDodger asiekierka

repo: copygirl/WearableBackpacks

license: mit


text:
Some Warnings of missing States in API

Describe the bug
I get some Warnings of missing datapoint from my roborock S7 Max Ultra. See the screenshot from the logs below.
To Reproduce
Steps to reproduce the behavior:

on every request (every 10 seconds) of the running adapter

Expected behavior
no Warning of missing datapoints ;-)
Screenshots & Logfiles

Versions:

Adapter version: v0.6.4
JS-Controller version: 5.0.19
Node version: 18.20.2
Operating system: debian 12

Additional context

Would you try the latest dev version from here https://github.com/copystring/ioBroker.roborock/tree/dev and try again?

The dev version works without any warnings

Thanks for testing. I'll make a new release with these changes when I find the time.


text:
CORE-7844 increase stability of the config update endpoint

When a config request is sent with the section set to "corda.messaging" nearly all components in the system will respond to this config change. This will cause the HttpGateway to go down bringing down the HttpServer. This will close all the connections open from http clients. this means a response is not received by the client for the request. To avoid this in tests we swallow the UniRestException thrown for put /config and does not retry the PUT, Previously the test would retry which caused multiple messaging config events to be sent to the RPC worker.
Separately the RPC pattern when sending config to the db worker will also fail due to repartition exceptions thrown by the RPC messaging pattern as a result of the messaging config being updated. A tmp solution is added to return the config posted by the client aswell as a success response.
A better solution might be to not bother waiting for a response from the db worker for config updates and immediately return 202 Accepted to the client always https://r3-cev.atlassian.net/browse/CORE-7930

This is definitely a workaround rather than a full fix. The main change here is that we'll return failure if the request never made it off the RPC worker, otherwise we'll return success - even if we never hear back from the other side. However, because the config get endpoint goes from a local cache, it remains possible to work out what the current applied config is.

Let's try this and see if we see any improvements.

repo: corda/corda-runtime-os


text:
Rnestler/iron handler

Not yet ready for merging but replaces #28 and actually builds and works with nightly. Does not build with stable/beta yet:
src/main.rs:6:1: 6:24 error: unstable feature

src/main.rs:6 #![feature(box_syntax)]

              ^~~~~~~~~~~~~~~~~~~~~~~

note: this feature may not be used in the beta release channel

error: aborting due to previous error

Could not compile `coredump-status`.

I cleaned up the branch. I think it's ready to merge now. @schmijos or @dbrgn care to review?

repo: coredump-ch/spaceapi


text:
could not send notification via notifier

Description of Problem / Feature Request
I'm having trouble with Clair not running properly and scans failing.  I'm seeing the following in the logs:
{"Event":"running database migrations","Level":"info","Location":"pgsql.go:216","Time":"2019-06-17 00:12:40.064040"}
{"Event":"database migration ran successfully","Level":"info","Location":"pgsql.go:223","Time":"2019-06-17 00:12:40.080581"}
{"Event":"starting main API","Level":"info","Location":"api.go:52","Time":"2019-06-17 00:12:40.080818","port":6060}
{"Event":"sender configured","Level":"info","Location":"notifier.go:66","Time":"2019-06-17 00:12:40.081369","sender name":"webhook"}
{"Event":"notifier service started","Level":"info","Location":"notifier.go:82","Time":"2019-06-17 00:12:40.081418","lock identifier":"d25f1fd3-e4c2-4d76-ac52-ee320c21ba8c"}
{"Event":"starting health API","Level":"info","Location":"api.go:85","Time":"2019-06-17 00:12:40.081648","port":6061}
{"Event":"updater service started","Level":"info","Location":"updater.go:83","Time":"2019-06-17 00:12:40.081701","lock identifier":"dd6530b0-8111-4ece-aad6-d22e3ace648f"}
{"Event":"found and locked a notification","Level":"info","Location":"notifier.go:143","Time":"2019-06-17 00:12:40.100891","notification name":"8daee2be-5526-4668-badb-f33fc99e0948"}
{"Event":"could not send notification via notifier","Level":"error","Location":"notifier.go:173","Time":"2019-06-17 00:12:41.263063","error":"got status 404, expected 200/201","notification name":"8daee2be-5526-4668-badb-f33fc99e0948","sender name":"webhook"}
{"Event":"waiting before retrying to send notification","Level":"info","Location":"notifier.go:163","Time":"2019-06-17 00:12:41.263257","attempts":2,"duration":1000000000,"max attempts":3,"notification name":"8daee2be-5526-4668-badb-f33fc99e0948","sender name":"webhook"}
{"Event":"could not send notification via notifier","Level":"error","Location":"notifier.go:173","Time":"2019-06-17 00:12:42.402846","error":"got status 404, expected 200/201","notification name":"8daee2be-5526-4668-badb-f33fc99e0948","sender name":"webhook"}
{"Event":"waiting before retrying to send notification","Level":"info","Location":"notifier.go:163","Time":"2019-06-17 00:12:42.402957","attempts":3,"duration":2000000000,"max attempts":3,"notification name":"8daee2be-5526-4668-badb-f33fc99e0948","sender name":"webhook"}
{"Event":"could not send notification via notifier","Level":"error","Location":"notifier.go:173","Time":"2019-06-17 00:12:44.541459","error":"got status 404, expected 200/201","notification name":"8daee2be-5526-4668-badb-f33fc99e0948","sender name":"webhook"}
{"Event":"giving up on sending notification : max attempts exceeded","Level":"info","Location":"notifier.go:157","Time":"2019-06-17 00:12:44.541570","max attempts":3,"notification name":"8daee2be-5526-4668-badb-f33fc99e0948","sender name":"webhook"}
{"Event":"found and locked a notification","Level":"info","Location":"notifier.go:143","Time":"2019-06-17 00:12:44.647041","notification name":"988cd314-feca-4f2f-ab8f-2afb225ba5f4"}
{"Event":"could not send notification via notifier","Level":"error","Location":"notifier.go:173","Time":"2019-06-17 00:12:44.786604","error":"got status 404, expected 200/201","notification name":"988cd314-feca-4f2f-ab8f-2afb225ba5f4","sender name":"webhook"}
{"Event":"waiting before retrying to send notification","Level":"info","Location":"notifier.go:163","Time":"2019-06-17 00:12:44.786711","attempts":2,"duration":1000000000,"max attempts":3,"notification name":"988cd314-feca-4f2f-ab8f-2afb225ba5f4","sender name":"webhook"}
{"Event":"could not send notification via notifier","Level":"error","Location":"notifier.go:173","Time":"2019-06-17 00:12:45.924866","error":"got status 404, expected 200/201","notification name":"988cd314-feca-4f2f-ab8f-2afb225ba5f4","sender name":"webhook"}
{"Event":"waiting before retrying to send notification","Level":"info","Location":"notifier.go:163","Time":"2019-06-17 00:12:45.924947","attempts":3,"duration":2000000000,"max attempts":3,"notification name":"988cd314-feca-4f2f-ab8f-2afb225ba5f4","sender name":"webhook"}
{"Event":"could not send notification via notifier","Level":"error","Location":"notifier.go:173","Time":"2019-06-17 00:12:48.062954","error":"got status 404, expected 200/201","notification name":"988cd314-feca-4f2f-ab8f-2afb225ba5f4","sender name":"webhook"}
{"Event":"giving up on sending notification : max attempts exceeded","Level":"info","Location":"notifier.go:157","Time":"2019-06-17 00:12:48.063065","max attempts":3,"notification name":"988cd314-feca-4f2f-ab8f-2afb225ba5f4","sender name":"webhook"}
{"Event":"found and locked a notification","Level":"info","Location":"notifier.go:143","Time":"2019-06-17 00:12:48.146751","notification name":"425a91f2-61d9-402f-99e2-19160a8fee31"}

Not sure if that's a red herring or not.  I have it running in K8s and it previously was working.  From the client side (ci/cd pipeline) I'm getting:
line 516, in send\n    raise
 ConnectionError(e, request=request)\nrequests.exceptions.ConnectionError: HTTPConnectionPool(host=\'clair.example.com\', port=60
60): Max retries exceeded with url: /v1/layers (Caused by NewConnectionError(\'<urllib3.connection.HTTPConnection object at 0x7fef74ee104
8>: Failed to establish a new connection: [Errno 110] Operation timed out\',))\n'

Expected Outcome
Clair to be up and scans to work
Actual Outcome
Seeing errors and scans are failing
Environment
Running in K8s

Clair version/image: v2.08, v2.0.7, v2.0.6
Clair client name/version: ???
Host OS: Docker, CI/CD
Kernel (e.g. uname -a): Docker / ???
Kubernetes version (use kubectl version): v1.13.6
Helm version (use helm version): v2.13.1
Network/Firewall setup: open

Alright so it ends up that traffic was not getting to clair.  Once that was fixed clair seems to be working.  It means that this error message is polluting the logs to the point its hard to find other things in the logs.
Can someone point me in the direction of what I need to look into.  But Clair seems to be working properly, or at least scanning and creating reports.

Any suggestions?

repo: coreos/clair


text:
v1.2.0_coreos.1 image has invalid signature

I've just tried deploying to AWS using kube-aws and the v1.2.0_coreos.1 image. After waiting a while I logged in and found the kubelet.service was failing to start due to invalid signature from openpgp. Change the service file to use v1.2.0_coreos.0 image and it signature verification worked.
Also tried deleting the cached quay.io public key, but the freshly downloaded one failed signature verification too.
Also note, this was with the beta release channel.

\cc @aaronlevy

@bharrisau can you give it another try? There was an issue on our end with the image build, but should be resolved.

This is odd -- I've successfully pulled this image yesterday and ran a cluster and conformance tests. This morning I spin up a new alpha machine and rkt fetch fails.
I'm going to build a new image using the same code repo. It will created an image with a slightly different hash and i'll overwrite the current tag. Expect the tag to not be available for a few minutes during this.

i have to confirm
Mar 29 21:23:41 192.168.1.171 kubelet-wrapper[978]: run: openpgp: invalid signature: hash tag doesn't match

Can't remember the path. I just did
find / -name "*hyperkube*"  2>/dev/null
sudo rm [path to file]

@bharrisau i deleted key, but still see Mar 29 22:44:09 192.168.1.170 kubelet-wrapper[1845]: run: openpgp: invalid signature: hash tag doesn't match

I can confirm the signature is still broken, we are working with the quay team to figure out what is going on.
@lukasz-bielinski You shouldn't need to force downloading the quay keys as that won't change (anytime soon at least). Once you have a key for a prefix, I believe rkt will stop automatically fetching a new signing key. This is akin to the trust-on-first-use principal that ssh uses. You can force downloading a new key for a given name prefix by explicitly trusting it: rkt trust --prefix quay.io/coreos/hyperkube
You can also manually delete keys in the trust store at /etc/rkt/trustedkeys/prefix.d

Just tried checking the sigs manually. Both v1.2.0_coreos.1 and v1.2.0_coreos.0 are signed with 799D33BC which is the Quay ACI converter. But the signature is failing for the .1 image.
I haven't been able to work out how to confirm that the Quay image I'm getting from https://quay.io/c1/aci/quay.io/coreos/hyperkube/v1.2.0_coreos.1/aci/linux/amd64/ has the correct tag fafaa6371fdd. Maybe it hasn't changed over yet? None of the hashes I'm running on the file match the contents.

Signature validation error is:
gpg: Signature made Tue Mar 29 19:33:48 2016 UTC using RSA key ID 799D33BC
gpg: BAD signature from "Quay.io ACI Converter (ACI conversion signing key) <support@quay.io>" [unknown]

The signature timestamp looks correct - a couple of hours ago. I'll leave it to the CoreOS and Quay.io teams.

Although we have not found the root cause of this, re-building and pushing eventually seemed to fix things. Closing this issue, please re-open it if you are seeing the same problem.

authors: aaronlevy bharrisau colhom lukasz-bielinski pbx0

repo: coreos/coreos-kubernetes


text:
migrate from semaphore to jenkins

 Issue by bcwaldon
Thursday Aug 06, 2015 at 22:25 GMT
Originally opened as https://github.com/coreos-inc/auth/issues/359

@bcwaldon out of curiosity, why switch from semaphore to jenkins?

@heckj Hi, Joe!
We have had a lot of issues with all hosted CI systems, not just semaphore, when it comes to automating docker builds. We haven't found something that provides a good experience around the multi-step build/test/publish process, where multiple calls to a docker daemon are required.
Semaphore, for example, doesn't actually have a public docker environment. One of our developers has been blessed with some special power to create projects with a "beta" docker environment. We're also still stuck writing a bash script, which is what I'm used to with Jenkins, but now I have no idea what I can trust to be on the build slave and I have no real power to debug and fix it when I run into issues (docker running hosts out of space, for example).
We are more than capable of running Jenkins, we just haven't had the time to get it properly configured. We have it running dex functional tests in our private instance, but ideally this is visible to the public.

Here here. I've resorted to the same with my projects of which build dockers in composition (+ release triggers).

@bcwaldon Hey Brian! Thanks - makes sense.
I still haven't shifted to building docker (or other container) images for anything I'm building directly yet. Are the relevant scripts in this repo? I'm kind of curious to see what you're doing and how you're doing it, just to keep up a bit. Or can you point me at a sample GIST or somethat that has the rough script?

@heckj :This is the Jenkins build script gist - all sub-scripts mentioned are in the root level of the repo:
https://gist.github.com/bobbyrullo/84cd5f0f24f68b1f3175

we're using travis for the foreseeable future.

authors: JasonGiedymin bcwaldon bobbyrullo ericchiang heckj

repo: coreos/dex


text:
Fixed some typos and terms for cfssl doc

/cc @robszumski

LGTM

authors: kayrus robszumski

repo: coreos/docs


text:
docs/os: add hardening guide for CoreOS

Many people have asked for best practices for hardening CoreOS. This
documents some of the basic practices to check out when considering
CoreOS.

LGTM, I'm not sure what our markdown renderer is gonna do to those headings touching the paragraphs. I can fix if needed.

authors: philips robszumski


text:
example: added "root secure" deployment yaml

Allows deploying in clusters with PodSecurityPolicy enforcing
runAsNonRoot without getting the following error:
“Error: container has runAsNonRoot and image has non-numeric
user (etcd-operator), cannot verify user is non-root”
Please read https://github.com/coreos/etcd-operator/blob/master/CONTRIBUTING.md#contribution-flow

lgtm @qvicksilver thanks!

authors: hexfusion qvicksilver

repo: coreos/etcd-operator


text:
example: use released version of operator

@djMax

lgtm

ref https://github.com/coreos/etcd-operator/issues/777#issuecomment-280070780


text:
Gauges about total key counters are always reporting 0

Hello, I am working on monitoring etcd using prometheus. I am currently using version 2.2.1, but all the gauge counters for key numbers are always returning 0. I have keys set by fleet and I have also tried to set keys manually, but the numbers are not changing.
Example:
# HELP etcd_storage_keys_total Total number of keys.
# TYPE etcd_storage_keys_total gauge
etcd_storage_keys_total 0
# HELP etcd_storage_put_total Total number of puts seen by this member.
# TYPE etcd_storage_put_total counter
etcd_storage_put_total 0
# HELP etcd_storage_range_total Total number of ranges seen by this member.
# TYPE etcd_storage_range_total counter
etcd_storage_range_total 0
# HELP etcd_storage_txn_total Total number of txns seen by this member.
# TYPE etcd_storage_txn_total counter
etcd_storage_txn_total 0
# HELP etcd_store_expires_total Total number of expired keys.
# TYPE etcd_store_expires_total counter
etcd_store_expires_total 468

The only counter reporting is the expired one.
Am I missing somenthing? From the code, I can see you are increasing these counters on put.

After some digging, the problem is that storage metrics are updated just for v3 API.
I think it would be really nice to have these values also for v2 API, which is the most used right now (AFAIK).
Something like
# HELP etcd_v2_storage_keys_total Total number of keys (v2).
# TYPE etcd_v2_storage_keys_total gauge (v2)
etcd_v2_storage_keys_total 0
# HELP etcd_v2_storage_put_total Total number of puts seen by this member (v2).
# TYPE etcd_v2_storage_put_total counter (v2)
etcd_v2_storage_put_total 0
# HELP etcd_v2_storage_range_total Total number of ranges seen by this member (v2).
# TYPE etcd_v2_storage_range_total counter (v2)
etcd_v2_storage_range_total 0
# HELP etcd_storage_txn_total Total number of txns seen by this member. (v2)
# TYPE etcd_storage_txn_total counter (v2)
etcd_v2_storage_txn_total 0
# HELP etcd_v2_store_expires_total Total number of expired keys (v2).
# TYPE etcd_v2_store_expires_total counter (v2)
etcd_v2_store_expires_total 468

What do you think?

@crisidev They are useful metrics for sure. So we added them to new store. We will not actively work on v2 store unfortunately.
We will make the metrics more clear: https://github.com/coreos/etcd/issues/3833

Look; we have tons of users on v2 -- I'm sitting next to @crisidev right now -- and they care about, you know, backwards compatibility.
v3 will be ready soon, sure, but it will be super useful for monitoring for current v2 users as they migrate  -- things like fleet, say. Adding them as tags ({version="2"}) means they can be deprecated as time moves on.
It'd be good to do. If it needs to be a PR from someone else, eg, "help wanted" tag, fine.

I completely stand with @barakmich as this product is used by a lot of people, which might be not switching immediately to v3. Monitoring is nice and important guys ;)

@barakmich We need to make the metrics clear (maybe adding tag or prefix). That includes in #3833.We do not need to care about backward compatibility right now since the whole metrics endpoint is still pretty experimental.
I am closing this since it is already covered by #3833.
@crisidev Adding more metrics to v2 store is a totally separate issue. You probably should open up another issue for it.

authors: barakmich crisidev xiang90

repo: coreos/etcd


text:
etcdctl 2.2.3 updatedir fails without extraneous argument.

As of 2.2, etcdctl updatedir seems to want another argument, but it doesnt do anything with it.
To reproduce:
etcdctl setdir /foo -ttl 60
etcdctl  updatedir /foo -ttl 90

Error:  value required
If at an interactive console, this will wait on stdin for the value, ctrl-d will end that and cause the failure. If in a non-interactive context, it will fail immediately with the message.
Im not very famliar with the etcd code, but it seems like these 4 lines at the end of the pasted code fragment below should be removed.
func updatedirCommandFunc(c *cli.Context, ki client.KeysAPI) {
if len(c.Args()) == 0 {
handleError(ExitBadArgs, errors.New("key required"))
}
key := c.Args()[0]
value, err := argOrStdin(c.Args(), os.Stdin, 1)
if err != nil {
handleError(ExitBadArgs, errors.New("value required"))
}
...

@mhenniges You need two arguments <key> <value> for updatedir command.

@mhenniges etcd does not support partial update. You can only update both value and ttl at same time. You can do a read and then compare and awap to update if you want do atomic partial update.

The value seems ignored in any case for updatedir though, so im not sure why it would be required...My colleague described this issue better than i did in https://github.com/coreos/etcd/issues/4145; I'll just watch the progress over there.

@mhenniges Sorry. I misunderstood your original one. Let's track this in #4145.

authors: gyuho mhenniges xiang90


text:
Documentation: run etcd with Container Linux Config

This is the official way of doing in Container Linux

https://github.com/coreos/docs/blob/master/etcd/getting-started-with-etcd.md#setting-up-etcd
https://github.com/coreos/container-linux-config-transpiler/blob/master/doc/getting-started.md

I will try this out sometime next week.
This does not need to be in etcd repo, but we definitely need docs to run etcd in Container Linux.
/cc @heyitsanthony @crawford

Will address this in https://github.com/coreos/docs/issues/1062.


text:
pkg/transport: fix a data race in TestWriteReadTimeoutListener

We cannot access test.T async which causes the data race.
Change to use select to coordinate the access of test.T.

LGTM

Does this fix #3576 ?


text:
etcd-tester: fix wrong error checking

Hash method returns either (nil, err) or (Hash, nil).
The current error checking is wrong. It only needs to check
the error is either nil or non-nil.
This causes panic in https://github.com/coreos/etcd/issues/4463
by allowing the case when resp is nil, but err is not nil.

/cc @xiang90 Please review and thanks for reporting.

LGTM


text:
NEWS: add v3.0.7

/cc @heyitsanthony @xiang90
Anything else to backport?
##### Bug fixes

- [GH6253](https://github.com/coreos/etcd/pull/6253): discovery: reject IP address records in SRVGetCluster
- [GH6267](https://github.com/coreos/etcd/pull/6267): wal: fix CRC corruption on writes following write tears
- [GH6309](https://github.com/coreos/etcd/pull/6309): etcdserver: allow zero kv index for cluster upgrade
- [GH6310](https://github.com/coreos/etcd/pull/6310): wal: use page buffered writer for writing records

#6284 and #6269?

Ok just backported.

lgtm

@heyitsanthony Let's do release this afternoon. Hopefully we can include patches for quote-parsing bug in etcdctl.

authors: gyuho heyitsanthony xiang90


text:
lessor: extend leases on promote if expires will be rate limited

/cc @gyuho

LGTM. This is much better. Thanks!
Can we trigger semaphore again?
Don't know why it didn't trigger.

Failing on CI due to flakey test fixed in #8159. Merging.

authors: gyuho heyitsanthony


text:
fleetctl: increase default sleep time from 2 to 4 seconds

As fleetctl start sometimes needs to wait up to 4 seconds until systemd active states get confirmed, we need to increase the defaultSleepTime from 2 to 4 seconds. Otherwise, a simple "fleetctl start" could sometimes fail with timeout.
Also reduce total running time of all tests, to avoid crash of functional tests resulted by the global timeout 600 secs.

Duh, this change is not necessary at all. "fleetctl start" already works just fine.
The issue is only a misleading error message. I'll create another PR to fix the message.

repo: coreos/fleet


text:
[discuss] core api naming

Hi,
the current Client interface is in fact a facade to create clients for etcd functionalities so I'm wondering if it could make sense to:

rename Client to Etcd or JEtcd
add Client suffix to the client so we match the getter names get*Client

Something like:
Etcd etcd = Etcd.builder().build();
KVClient kvClient = etcd.getKVClient();

A similar naming can be found in Orbitz's consul client

rename Client to Etcd or JEtcd
I don't we need to have etcd keyword in any of the interface. Since it is quite obvious that you are using a java client for etcd. I don't user will gain additional clarity from the etcd keyword.
add Client suffix to the client so we match the getter names get*Client
I would like jetcd api naming to match that of the go client. In go client, there aren't any client suffix. In this way, the user from go to java or vice versa should have a consistent experience.
Also getKVClient() already tell the user the return object will be a client. I am not sure if Client in KVClientbuys additional clarity for user.

authors: fanminshi lburgazzoli

repo: coreos/jetcd


text:
WIP: Pin dependencies for the 0.5 release branch

cc @coreos/team-monitoring

Want to bump k8s version we test against in master first to 1.18 and bring that commit here.

lgtm

You will also need to run the tests on 1.17 like we did here: #476

Yep, waiting for master PR to merge first to bring that commit in only figured out we do not test against 1.18 when I was editing the README, hence the WIP :)

Decided to merge this first, to unblock CMO stuff, as 1.18 in master is taking a bit longer. @dgrisonnet @brancz this just pins deps PTAL, thanks!

authors: brancz dgrisonnet lilic

repo: coreos/kube-prometheus


text:
340 add code examples

closes #340

currenty branched from game visu branch, once that one is merged, this PR will be opened :+1:

The page is now scrollable. Would prefer it not exceed the window height
Also, as seen in the following image, the code editor itself extends too far to the bottom. IMO either dont force the example cards and code editor to have the same height, or just extend the actual code editor aswell.

hm, i styled this on a 1080p monitor and it looked fine and it still looks fine on my laptop :thinking: , what res do you currently use ?

The page is now scrollable. Would prefer it not exceed the window height
Also, as seen in the following image, the code editor itself extends too far to the bottom. IMO either dont force the example cards and code editor to have the same height, or just extend the actual code editor aswell.

hm, i styled this on a 1080p monitor and it looked fine and it still looks fine on my laptop 🤔 , what res do you currently use ?

1920x1080, browser used is firefox

repo: corewar-teamprojekt/corewar


text:
Space in Windows username

My Environment

[x] Windows 7 or below (not truly supported due to EOL)

I have found little error when someone has a space in username and so has path to default dir like C:\Users\firstname second\AppData\Roaming
Everything seems to be ok until you type nvm use 4.4.7 -> error exit 1 C:\Users\firstname is not command etc..
Solution install nvm eg. C:\nvm. Just dont use space

Duplicate of #41.

authors: AntiCZ coreybutler

repo: coreybutler/nvm-windows