add OIDC  to  Kong in K8

How to add OIDC from source to running Kong pod in k8
luarocks install kong-oidc

Hey @yasir2000,
Just thought I'd share a couple resources I found helpful for this.

The Kong documentation for "Installing the plugin" has an option for manually installing the plugin by source. It involves copying the source into the image and then adding the plugin location to the environment variable LUA_PATH. What it doesn't mention is installing dependencies required by the plugin.
In this repo, the Dockerfile used for tests will copy the repo into the image, set the LUA_PATH variable and install the dependencies. A few of those dependencies are just for tests. You shouldn't need them.

When testing, I used a Dockerfile like this but you may want to tweak the copy command so only the required files are included.
ARG KONG_BASE_TAG
FROM kong${KONG_BASE_TAG}

USER root

ENV LUA_PATH ${LUA_PATH};/usr/local/kong-oidc/?.lua;;
RUN luarocks install lua-resty-openidc 1.6.0
COPY . /usr/local/kong-oidc

USER kong

I've only tested this in vanilla Docker but I don't suspect you'll have problems in K8s.

Hey @yasir2000,
Just thought I'd share a couple resources I found helpful for this.

The Kong documentation for "Installing the plugin" has an option for manually installing the plugin by source. It involves copying the source into the image and then adding the plugin location to the environment variable LUA_PATH. What it doesn't mention is installing dependencies required by the plugin.
In this repo, the Dockerfile used for tests will copy the repo into the image, set the LUA_PATH variable and install the dependencies. A few of those dependencies are just for tests. You shouldn't need them.

When testing, I used a Dockerfile like this but you may want to tweak the copy command so only the required files are included.
ARG KONG_BASE_TAG
FROM kong${KONG_BASE_TAG}

USER root

ENV LUA_PATH ${LUA_PATH};/usr/local/kong-oidc/?.lua;;
RUN luarocks install lua-resty-openidc 1.6.0
COPY . /usr/local/kong-oidc

USER kong

I've only tested this in vanilla Docker but I don't suspect you'll have problems in K8s.

My question, is how to to follow with this deployment inside a running POD container? do I have to rerun Docker file with new commands or I can do this while container running

Hmm... that's a good question. If you're looking for a way to add the plugin without restarting Kong, I'm not entirely sure it's possible. Kong loads the plugins listed in KONG_PLUGINS on startup.
However, if you're ok with restarting the instance, you might be able to get that to work with just the regular Kong image. Here's 4 things you'd need to do.

Add the source code to the container's file system. I'd recommend using some kind of volume or mount so the plugin's source code is persistent.
Set environment variable LUA_PATH to include the plugin. Hopefully you can set this in your deployment configuration.
Set environment variable KONG_PLUGINS to include oidc. For example KONG_PLUGINS=bundled,oidc. Hopefully you can do this in your deployment configuration as well.
This one seems a little more tricky to me. You'd need to run luarocks install lua-resty-openidc 1.6.0 before the Kong process starts. Without adding a new startup script, I'm guessing your best bet will be to modify the startup command. However, the newer Kong images run with user kong instead of root but the LuaRocks installation requires root access. That's why you see me swapping the users up in the Dockerfile. There are probably some ways to get around this by setting the user to root in your deployment config and then using sudo -u kong ... to run the docker-entrypoint.sh as kong. I use Alpine which doesn't include sudo so that would be another installation that has to happen. Alternatively, there might be an option for mounting the lua-resty-openidc dependency as well but that's unchartered territory for me.

Hopefully there's something helpful here for you. Cheers 🙂

Problem @ghunteranderson is that am using bitnami image and helm charts https://bitnami.com/stack/kong/helm which I had to redeploy to set user 0 or root. Now that I have new deployment with root access, i tried to install on pod directly but that didnt pull new plugins even with restart Kong so i managed to create a pv, now i have to create mount point, bind it via configmap to pod, then put source inside it and deploy the Dockerfile with kubectl -f, my image already have dependencies lua-resty,...etc

Thanks for sending the helm chart over @yasir2000. If you can give a little time to test out a few approaches with that helm chart, I'll try to get something working.

Am now for 14 days on this task infact :) so the smoother and quicker things are to come to happy ending, the louder I shout of it, it's a nice tricky stuff. I tried so so many ways to inject this config:

Krew Plugins - kubectl ssh -d -u root -n kong -c kong kong-6cdff875b7-dnx5h -- /bin/bash
kubectl exec --user root kong-6cdff875b7-dnx5h -c kong -- /bin/bash
Podman
And many other tools, yet I had to rebuild with root because bitnami's image is 1001 (anonymous built). Now I have rooted container, but still even after following all :
https://github.com/nokia/kong-oidc
Didn't list the new plugin at admin api,

So the next is to follow your steps above to get an image upped with the source in separate path (now its inside /opt/bitnami/kong/openresty/luajit/share/lua/5.1/kong/plugins and edited /opt/bitnami/kong/conf/kong.conf
plugins section)
Will say HOORAY once its there in listed plugins.

Now am in the middle way @ghunteranderson , I created , mounted and bound a pv with source inside it /mnt/data/kong-config/kong-oidc-master/ next is to do something in that pod to luarocks install lua-resty-openidc 1.6.0 but without rebuilding the image with new Dockerfile

This is my existing deployment yaml:
kind: Deployment
apiVersion: apps/v1
metadata:
  name: kong
  namespace: kong
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/instance: kong
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: kong
    helm.sh/chart: kong-3.0.1
  annotations:
    deployment.kubernetes.io/revision: '1'
    meta.helm.sh/release-name: kong
    meta.helm.sh/release-namespace: kong
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/component: server
      app.kubernetes.io/instance: kong
      app.kubernetes.io/name: kong
  template:
    metadata:
      creationTimestamp: null
      labels:
        app.kubernetes.io/component: server
        app.kubernetes.io/instance: kong
        app.kubernetes.io/managed-by: Helm
        app.kubernetes.io/name: kong
        helm.sh/chart: kong-3.0.1
      annotations:
        checksum/configmap-kong: 0e4f2471170bd86586fd5ec5ad2593bff656df939f49ec74239e032758fcea07
    spec:
      volumes:
        - name: health
          configMap:
            name: kong-scripts
            defaultMode: 493
      containers:
        - name: kong
          image: 'docker.io/bitnami/kong:2.2.0-debian-10-r33'
          ports:
            - name: http-proxy
              containerPort: 8000
              protocol: TCP
            - name: https-proxy
              containerPort: 8443
              protocol: TCP
            - name: http-admin
              containerPort: 8001
              protocol: TCP
            - name: https-admin
              containerPort: 8444
              protocol: TCP
          env:
            - name: KONG_ADMIN_LISTEN_ADDRESS
              value: <IP_ADDRESS>
            - name: KONG_DATABASE
              value: postgres
            - name: KONG_PG_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: kong-postgresql
                  key: postgresql-password
            - name: KONG_PG_HOST
              value: kong-postgresql
            - name: KONG_PG_USER
              value: kong
          resources: {}
          volumeMounts:
            - name: health
              mountPath: /health
          livenessProbe:
            exec:
              command:
                - /bin/bash
                - '-ec'
                - /health/kong-container-health.sh
            initialDelaySeconds: 120
            timeoutSeconds: 5
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 6
          readinessProbe:
            exec:
              command:
                - /bin/bash
                - '-ec'
                - /health/kong-container-health.sh
            initialDelaySeconds: 30
            timeoutSeconds: 5
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 6
          lifecycle:
            preStop:
              exec:
                command:
                  - /bin/sh
                  - '-c'
                  - kong quit
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: IfNotPresent
          securityContext:
            runAsUser: 0
            runAsNonRoot: false
        - name: kong-ingress-controller
          image: 'docker.io/bitnami/kong-ingress-controller:0.10.0-debian-10-r68'
          command:
            - bash
            - '-ec'
            - /health/ingress-container-start.sh
          ports:
            - name: http-health
              containerPort: 10254
              protocol: TCP
          env:
            - name: CONTROLLER_KONG_ADMIN_URL
              value: 'http://<IP_ADDRESS>:8001'
            - name: CONTROLLER_PUBLISH_SERVICE
              value: kong/kong
            - name: CONTROLLER_INGRESS_CLASS
              value: kong
            - name: CONTROLLER_ELECTION_ID
              value: kong-ingress-controller-leader-kong
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.namespace
          resources: {}
          volumeMounts:
            - name: health
              mountPath: /health
          livenessProbe:
            httpGet:
              path: /healthz
              port: http-health
              scheme: HTTP
            initialDelaySeconds: 120
            timeoutSeconds: 5
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 6
          readinessProbe:
            httpGet:
              path: /healthz
              port: http-health
              scheme: HTTP
            initialDelaySeconds: 30
            timeoutSeconds: 5
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 6
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: IfNotPresent
          securityContext:
            runAsUser: 0
            runAsNonRoot: false
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      dnsPolicy: ClusterFirst
      serviceAccountName: kong
      serviceAccount: kong
      securityContext: {}
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    app.kubernetes.io/component: server
                    app.kubernetes.io/instance: kong
                    app.kubernetes.io/name: kong
                namespaces:
                  - kong
                topologyKey: kubernetes.io/hostname
      schedulerName: default-scheduler
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  revisionHistoryLimit: 10
  progressDeadlineSeconds: 600

I have a useful configMap

Could that be useful to add a new script from the repo:

@chance2021 That worked for me ! Thanks

@MalikEljaouadi how did you executed the docker build ? mine is not finding the prebuildfs and rootfs folders :/

Yes I executed the docker build ! but first you need to pull the repo of Bitnami Kong (https://github.com/bitnami/bitnami-docker-kong) and override its Dockerfile with this image. and if you are stuck with it you can use the image that Ihave provided in the Dockerhub (https://hub.docker.com/repository/docker/malekeljaouadi/bitnami-kong-with-oidc) and it is working fine!

@MalikEljaouadi how did you executed the docker build ? mine is not finding the prebuildfs and rootfs folders :/

Yes I executed the docker build ! but first you need to pull the repo of Bitnami Kong (https://github.com/bitnami/bitnami-docker-kong) and override its Dockerfile with this image. and if you are stuck with it you can use the image that Ihave provided in the Dockerhub (https://hub.docker.com/repository/docker/malekeljaouadi/bitnami-kong-with-oidc) and it is working fine!

@MalikEljaouadi how did you executed the docker build ? mine is not finding the prebuildfs and rootfs folders :/

Yes I executed the docker build ! but first you need to pull the repo of Bitnami Kong (https://github.com/bitnami/bitnami-docker-kong) and override its Dockerfile with this image. and if you are stuck with it you can use the image that Ihave provided in the Dockerhub (https://hub.docker.com/repository/docker/malekeljaouadi/bitnami-kong-with-oidc) and it is working fine!

Hi @MalikEljaouadi, i tried to create a helm build based on your provided image i.e malekeljaouadi/bitnami-kong-with-oidc and also added the kong-oidc plugin as extraEnvVars according to your above provided Values.yaml file. I am still not able to see OIDC plugin in konga.
Here are my custom Values.yaml configs:
image:
  repository: malekeljaouadi/bitnami-kong-with-oidc
  tag: "latest"
  pullPolicy: IfNotPresent

admin:
  enabled: true
  type: LoadBalancer
  annotations: {}
  labels: {}

  http:
    enabled: true
    servicePort: 8001
    containerPort: 8001
    parameters: []

  tls:
    enabled: false
    servicePort: 8444
    containerPort: 8444
    parameters:
      - http2

  ingress:
    enabled: true
    ingressClassName: kong
    hostname: admin.kongproxy.me
    annotations:
       external-dns.alpha.kubernetes.io/hostname: admin.kongproxy.me
    path: /

image:
 repository: kong/kong-gateway
 tag: "2.7"
 pullPolicy: IfNotPresent

env:
  database: "postgres"
  pg_user: "kong"
  pg_password: "kong"
  pg_database: "kong"
  ph_host: "kong-postgresql"
  admin_api_uri: "http://admin.kongproxy.me"
  admin_gui_url: "http://manager.kongproxy.me"

manager:
  enabled: true
  type: LoadBalancer
  annotations: {}
  labels: {}

  http:
    enabled: true
    servicePort: 8002
    containerPort: 8002
    parameters: []

  tls:
    enabled: false
    servicePort: 8445
    containerPort: 8445
    parameters:
      - http2

  ingress:
    enabled: true
    ingressClassName: kong
    hostname: manager.kongproxy.me
    annotations:
       external-dns.alpha.kubernetes.io/hostname: manager.kongproxy.me
    path: /

enterprise:
  enabled: true
  vitals:
    enabled: true

postgresql:
  enabled: true
  image:
    registry: docker.io
    repository: bitnami/postgresql
    tag: 11.16.0-debian-11-r5
  auth:
    username: kong
    password: kong
    database: kong
    postgresPassword: test123
    existingSecret: ""
    usePasswordFiles: false
  architecture: standalone
kong:
  extraEnvVars:
  - name: KONG_LOG_LEVEL
    value: "debug"
  - name: KONG_PLUGINS
    value: "bundled,oidc"

Can you please look into the config and mention anything that i am doing wrong? I want to integrate kong with keycloak as ID provider on custom app. Hoping for a reply soon

@chance2021 can you please look into it as well, btw i am not using bitnami/kong but kong/kong helm chart image, would it make any difference?

This is the values file that I have used to deploy it with the Helm chart
image:
  repository: malekeljaouadi/bitnami-kong-with-oidc
  tag: latest
  pullPolicy: IfNotPresent
  debug: false
database: postgresql
replicaCount: 1
postgresql:
  enabled: true
  image:
    registry: docker.io
    repository: bitnami/postgresql
    tag: 13.8.0-debian-11-r12
  auth:
    username: kong
    password: "kong"
    database: kong
    postgresPassword: "kong"
    usePasswordFiles: false
  architecture: standalone
kong:
  extraEnvVars:
  - name: KONG_LOG_LEVEL
    value: "debug"
  - name: KONG_PLUGINS
    value: "bundled,oidc"
  livenessProbe:
    enabled: false
  readinessProbe:
    enabled: false
service:
  type: ClusterIP
  exposeAdmin: true
ingressController:
  enabled: true
  image:
    registry: docker.io
    repository: bitnami/kong-ingress-controller
    tag: 2.5.0-debian-11-r19
    digest: ""
    pullPolicy: IfNotPresent
  livenessProbe:
    enabled: false
  readinessProbe:
    enabled: false


Frequency modulation (FM)

How to modulate one waveform/track with another to achieve FM(Freq. Modulation)?

Currently this library doesn't support any sound processing. It can only play loaded sounds. There are some plans however to add support for low-levelish PCM access, around which sound processing could be built.


Provide more C# .NET Core samples for armhf

Exploring more of the sample functions in the store I would like to see more .NET Core for armhf.
Following Alex Ellis' and Scott Hanselman's great posts I would like to see similar examples available in the store.

Hello World - C#
NodeInfo - C#
Suggestions? (I'm willing to work on any, just need ideas)

I've got Hello World working locally and would be happy to submit.

Is there something we can do that makes sense for .NET Core over Go or Python etc?

From a user-perspective the store is about images that can be used to explore OpenFaaS - so we already have NodeInfo in Node - adding it in C# is OK for community.md listings but might be confusing in the store.

Whatever makes the most sense.
I would like to come up with something to contribute to the store, but I'm better at implementation than ideas. I ported an environment example over and added to Docker Hub - https://hub.docker.com/r/ovation22/func-environment-armhf/.
I'll continue to try to think of a good example for the store.


Github testing

Description
Start cleaning up the GitHub test flow
Issues Resolved
[List any existing issues this PR resolves]
Check List

[ ] All tests pass.
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable

@jeffbyrnes Could you give this another look?  Thanks


ERROR failed to spawn chain runtime: relayer error: RPC error to endpoint

Running Hermes 1.6.0. This error appears only when doing 2 hermes calls:

hermes start
hermes clear packets

Calling 1) or 2) works fine. You can test it like this: run 1) hermes start and then call 2) a couple of times hermes --config ./config.toml clear packets --chain uni-6 --channel channel-721 --port wasm.juno1uvflayc34fs9r3tzcausztks2058ecpt5kqtzf3sz5kwnu7fjtfqn7zmtj
Then you get this error:

ERROR failed to spawn chain runtime: relayer error: RPC error to endpoint https://juno-testnet-rpc.polkachu.com/: serde parse error: expected value at line 1 column 1

For testing use this config.toml:
# Description of the parameters below can be found here: https://hermes.informal.systems/documentation/configuration/description.html
# The global section has parameters that apply globally to the relayer operation.
[global]

# Specify the verbosity for the relayer logging output. Default: 'info'
# Valid options are 'error', 'warn', 'info', 'debug', 'trace'.
log_level = 'info'

# Specify the mode to be used by the relayer. [Required]
[mode]

# Specify the client mode.
[mode.clients]

# Whether or not to enable the client workers. [Required]
enabled = true

# Whether or not to enable periodic refresh of clients. [Default: true]
# This feature only applies to clients that underlie an open channel.
# For Tendermint clients, the frequency at which Hermes refreshes them is 2/3 of their
# trusting period (e.g., refresh every ~9 days if the trusting period is 14 days).
# Note: Even if this is disabled, clients will be refreshed automatically if
#      there is activity on a connection or channel they are involved with.
refresh = true

# Whether or not to enable misbehaviour detection for clients. [Default: true]
misbehaviour = true

# Specify the connections mode.
[mode.connections]

# Whether or not to enable the connection workers for handshake completion. [Required]
enabled = true

# Specify the channels mode.
[mode.channels]

# Whether or not to enable the channel workers for handshake completion. [Required]
enabled = true

# Specify the packets mode.
[mode.packets]

# Whether or not to enable the packet workers. [Required]
enabled = true

# Parametrize the periodic packet clearing feature.
# Interval (in number of blocks) at which pending packets
# should be periodically cleared. A value of '0' will disable
# periodic packet clearing. [Default: 100]
clear_interval = 0 # set to 0, for requeueing packets as defined below in `tx_confirmation`

# Whether or not to clear packets on start. [Default: true]
clear_on_start = true

# Toggle the transaction confirmation mechanism.
# The tx confirmation mechanism periodically queries the `/tx_search` RPC
# endpoint to check that previously-submitted transactions
# (to any chain in this config file) have been successfully delivered.
# If they have not been, and `clear_interval = 0`, then those packets are
# queued up for re-submission.
# If set to `false`, the following telemetry metrics will be disabled:
# `acknowledgment_packets_confirmed`, `receive_packets_confirmed` and `timeout_packets_confirmed`.
# [Default: false]
tx_confirmation = true

# Auto register the counterparty payee on a destination chain to
# the relayer's address on the source chain. This can be used
# for simple configuration of the relayer to receive fees for
# relaying RecvPacket on fee-enabled channels.
# For more complex configuration, turn this off and use the CLI
# to manually register the payee addresses.
# [Default: false]
auto_register_counterparty_payee = false

# The REST section defines parameters for Hermes' built-in RESTful API.
# https://hermes.informal.systems/rest.html
[rest]

# Whether or not to enable the REST service. Default: false
enabled = true

# Specify the IPv4/6 host over which the built-in HTTP server will serve the RESTful
# API requests. Default: <IP_ADDRESS>
host = '<IP_ADDRESS>' # need to set this to `<IP_ADDRESS>` to allow external access within docker! check here: https://github.com/informalsystems/hermes/issues/3592#issuecomment-1712645510

# Specify the port over which the built-in HTTP server will serve the restful API
# requests. Default: 3000
port = 3000

# The telemetry section defines parameters for Hermes' built-in telemetry capabilities.
# https://hermes.informal.systems/telemetry.html
[telemetry]

# Whether or not to enable the telemetry service. Default: false
enabled = true

# Specify the IPv4/6 host over which the built-in HTTP server will serve the metrics
# gathered by the telemetry service. Default: <IP_ADDRESS>
host = '<IP_ADDRESS>' # need to set this to `<IP_ADDRESS>` to allow external access within docker! check here: https://github.com/informalsystems/hermes/issues/3592#issuecomment-1712645510

# Specify the port over which the built-in HTTP server will serve the metrics gathered
# by the telemetry service. Default: 3001
port = 3001

[telemetry.buckets.latency_submitted]
start = 500
end = 20000
buckets = 10

[telemetry.buckets.latency_confirmed]
start = 1000
end = 30000
buckets = 10

[[chains]]
id = 'elgafar-1'
type = 'CosmosSdk'
rpc_addr = 'https://rpc.elgafar-1.stargaze-apis.com:443' # 'https://stargaze-rpc.polkachu.com:443' 'https://rpc.elgafar-1.stargaze-apis.com:443'
grpc_addr = 'http://grpc-1.elgafar-1.stargaze-apis.com:26660' # 'http://stargaze-grpc.polkachu.com:13790' # 'http://grpc-1.elgafar-1.stargaze-apis.com:26660'
rpc_timeout = '10s'
account_prefix = 'stars'
key_name = 'stargaze_ark_relayer'
store_prefix = 'ibc'
default_gas = 40000
max_gas = 1500000
gas_multiplier = 1.3
max_msg_num = 10
max_tx_size = 4194304 # 4MiB
clock_drift = '60s'
max_block_time = '30s'
memo_prefix = 'Powered by Ark Protocol'
# trusting_period = '1209599s' # 14 days (unbonding period) minus 1 sec
# address_type = { derivation = 'cosmos' }

[chains.event_source]
mode = 'push'
url = 'wss://rpc.elgafar-1.stargaze-apis.com:443/websocket' # 'wss://stargaze-rpc.polkachu.com:443/websocket' 'wss://rpc.elgafar-1.stargaze-apis.com:443/websocket'
batch_delay = '500ms'

[chains.trust_threshold]
numerator = '1'
denominator = '3'

[chains.gas_price]
price = 0.04
denom = 'ustars'

[chains.packet_filter]
policy = 'allow'
list = [
  # Stargaze ICS721 channels
  # IMPORTANT: do NOT change comments for each channel below! `create-channels.sh` does a search and replace!
  ## ICS721 with rate limiter outgoing proxy (managed by Ark)
  ['wasm.stars165fr5j3ea0dk5yr5sr4h8uw76z5fd34lpnqc2x80ya9xkx9u0k3qjrqpzq', 'channel-589'], # CHANNEL_1_STARGAZE_TO_JUNO, channel-721
  ['wasm.stars165fr5j3ea0dk5yr5sr4h8uw76z5fd34lpnqc2x80ya9xkx9u0k3qjrqpzq', 'channel-590'], # CHANNEL_1_STARGAZE_TO_TERRA, channel-354
]

[[chains]]
id = 'uni-6'
rpc_addr = 'https://uni-rpc.reece.sh:443' # 'https://juno-testnet-rpc.polkachu.com:443' # 'https://uni-rpc.reece.sh:443' #'https://rpc.uni.junonetwork.io:443' 'http://juno.rpc.t.stavr.tech:1067'
grpc_addr = 'http://juno-testnet-grpc.polkachu.com:12690' # 'http://juno.grpc.t.stavr.tech:504'
# BACKUP:
# rpc_addr = 'https://uni-rpc.reece.sh:443'
# grpc_addr = 'http://<IP_ADDRESS>:9090'
rpc_timeout = '10s'
account_prefix = 'juno'
key_name = 'juno_ark_relayer'
store_prefix = 'ibc'
default_gas = 4500
max_gas = 800000
gas_multiplier = 1.5
max_msg_num = 10
max_tx_size = 4194304 # 4MiB
clock_drift = '60s'
max_block_time = '30s'
memo_prefix = 'Powered by Ark Protocol'
# trusting_period = '2419199s' # 28 days (unbonding period) minus 1 sec
# address_type = { derivation = 'cosmos' }

[chains.event_source]
mode = 'push'
url = 'wss://uni-rpc.reece.sh:443/websocket'
# url = 'wss://rpc.uni.junonetwork.io/websocket'
# url = 'wss://juno-testnet-rpc.polkachu.com:443/websocket' # not supported by :( answer here: https://discord.com/channels/888644988584460369/954902712401661993/1051772830112546896
# url = 'wss://http://juno.rpc.t.stavr.tech:1067/websocket' # not supported
batch_delay = '500ms'

[chains.trust_threshold]
numerator = '1'
denominator = '3'

[chains.gas_price]
price = 0.0045
denom = 'ujunox'

[chains.packet_filter]
policy = 'allow'
list = [
  # Juno ICS721 channels
  # IMPORTANT: do NOT change comments for each channel below! `create-channels.sh` does a search and replace!
  ## ICS721 with rate limiter outgoing proxy (managed by Ark)
  ['wasm.juno1uvflayc34fs9r3tzcausztks2058ecpt5kqtzf3sz5kwnu7fjtfqn7zmtj', 'channel-721'], # CHANNEL_1_JUNO_TO_STARGAZE, channel-589
  ['wasm.juno1uvflayc34fs9r3tzcausztks2058ecpt5kqtzf3sz5kwnu7fjtfqn7zmtj', 'channel-722'], # CHANNEL_1_JUNO_TO_TERRA, channel-353
]

[[chains]]
id = 'pisco-1'
rpc_addr = 'https://terra-testnet-rpc.polkachu.com:443'
grpc_addr = 'http://terra-testnet-grpc.polkachu.com:11790'
# check URLs on deployed terra node here: https://deploy.cloudmos.io/deployments
# rpc_addr = 'https://v6o9a68htpb370gnm6qps5o5ok.ingress.europlots.com'
# grpc_addr = 'http://provider.europlots.com:30583' # check public port mapping for internal port 9090 defined on cloudmos.io
rpc_timeout = '20s'
account_prefix = 'terra'
key_name = 'terra_ark_relayer'
store_prefix = 'ibc'
default_gas = 15000
max_gas = 600000
gas_multiplier = 1.3
max_msg_num = 30
max_tx_size = 100000 # 1k
clock_drift = '45s'
max_block_time = '10s'
memo_prefix = 'Powered by Ark Protocol'
# trusting_period = '288000s'
# address_type = { derivation = 'cosmos' }

[chains.event_source]
mode = 'push'
url = 'wss:///pisco-rpc.terra.dev:443/websocket'
# url = 'ws://terra-testnet-rpc.polkachu.com:443/websocket' # not supported by polkachu, answer here: https://discord.com/channels/888644988584460369/954902712401661993/1051772830112546896
batch_delay = '500ms'

[chains.trust_threshold]
numerator = '1'
denominator = '3'

[chains.gas_price]
price = 0.15
denom = 'uluna'

[chains.packet_filter]
policy = 'allow'
list = [
  # Terra ICS721 channels
  # IMPORTANT: do NOT change comments for each channel below! `create-channels.sh` does a search and replace!
  ## ICS721 with rate limiter outgoing proxy (managed by Ark)
  ['wasm.terra1luhy2ngj7y0lqy3vjek3xm777pywptzzea0sc5ymu4pmafjrn07s5rlmxt', 'channel-353'], # CHANNEL_1_TERRA_TO_JUNO, channel-722
  ['wasm.terra1luhy2ngj7y0lqy3vjek3xm777pywptzzea0sc5ymu4pmafjrn07s5rlmxt', 'channel-354'], # CHANNEL_1_TERRA_TO_STARGAZE, channel-590
]

Thanks for the report! Can you please re-run the command that failed with the --debug=rpc flag and post the logs here?
eg.
hermes --debug=rpc --config ./config.toml clear packets --chain uni-6 --channel channel-721 --port wasm.juno1uvflayc34fs9r3tzcausztks2058ecpt5kqtzf3sz5kwnu7fjtfqn7zmtj

Thanks for the report! Can you please re-run the command that failed with the --debug=rpc flag and post the logs here?
eg.
hermes --debug=rpc --config ./config.toml clear packets --chain uni-6 --channel channel-721 --port wasm.juno1uvflayc34fs9r3tzcausztks2058ecpt5kqtzf3sz5kwnu7fjtfqn7zmtj

Here we go:
2023-10-13T20:27:57.281928Z  INFO ThreadId(01) running Hermes v1.6.0+1c1cf02
2023-10-13T20:27:57.283746Z DEBUG ThreadId(01) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "de361d46-3b8b-4fb1-8d24-1046c7dced11",
  "method": "status",
  "params": null
}
2023-10-13T20:27:57.484373Z DEBUG ThreadId(01) Incoming response: {"jsonrpc":"2.0","id":"de361d46-3b8b-4fb1-8d24-1046c7dced11","result":{"node_info":{"protocol_version":{"p2p":"8","block":"11","app":"0"},"id":"0d194f5236a420147b05d9556ac0cf928c36e647","listen_addr":"<IP_ADDRESS>:11756","network":"pisco-1","version":"0.37.2","channels":"40202122233038606100","moniker":"hello-terra-testrelay","other":{"tx_index":"on","rpc_address":"tcp://<IP_ADDRESS>:11757"}},"sync_info":{"latest_block_hash":"2B6CD648B9355F4A7294779B49892618C0A35FCAEB01314A97737B608464BE24","latest_app_hash":"6B403B26E89CAA0893D18E496F3573AC027A960C4E66231D62B39E567EB3543E","latest_block_height":"7873519","latest_block_time":"2023-10-13T20:27:50.456001077Z","earliest_block_hash":"F9A088A259FC93FED2B053BEB5C097DEC0B3984D975D5E23C882795D9F2AB2E6","earliest_app_hash":"48D600F209AAA3EA64A18444CD99B3E24EA1E65F4DC1925055BA36C424A0724E","earliest_block_height":"6660741","earliest_block_time":"2023-07-25T13:58:54.797854271Z","catching_up":false},"validator_info":{"address":"99281AC70CA77998969E24A595363E81BCF6FFCE","pub_key":{"type":"tendermint/PubKeyEd25519","value":"L1HjhqkxoL+lVG3hgZSR2ktUoil3aJvyxpUNWHSDNkE="},"voting_power":"0"}}}
2023-10-13T20:27:57.487989Z DEBUG ThreadId(04) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "1578544c-7f58-4721-b61a-a20b7c07a586",
  "method": "abci_query",
  "params": {
    "path": "store/ibc/key",
    "data": "6368616E6E656C456E64732F706F7274732F7761736D2E7465727261316C756879326E676A3779306C717933766A656B33786D37373770797770747A7A656130736335796D7534706D61666A726E30377335726C6D78742F6368616E6E656C732F6368616E6E656C2D333534",
    "prove": false
  }
}
2023-10-13T20:27:57.611200Z DEBUG ThreadId(04) Incoming response: {"jsonrpc":"2.0","id":"1578544c-7f58-4721-b61a-a20b7c07a586","result":{"response":{"code":0,"log":"","info":"","index":"0","key":"Y2hhbm5lbEVuZHMvcG9ydHMvd2FzbS50ZXJyYTFsdWh5Mm5najd5MGxxeTN2amVrM3htNzc3cHl3cHR6emVhMHNjNXltdTRwbWFmanJuMDdzNXJsbXh0L2NoYW5uZWxzL2NoYW5uZWwtMzU0","value":"CAMQARpUCkV3YXNtLnN0YXJzMTY1ZnI1ajNlYTBkazV5cjVzcjRoOHV3NzZ6NWZkMzRscG5xYzJ4ODB5YTl4a3g5dTBrM3FqcnFwenESC2NoYW5uZWwtNTkwIg5jb25uZWN0aW9uLTQwOSoIaWNzNzIxLTE=","proofOps":null,"height":"7873519","codespace":""}}}
2023-10-13T20:27:57.730925Z DEBUG ThreadId(04) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "f48d17d7-3934-43aa-b27f-6f3270219aec",
  "method": "abci_query",
  "params": {
    "path": "store/ibc/key",
    "data": "636C69656E74732F30372D74656E6465726D696E742D3435322F636C69656E745374617465",
    "prove": false
  }
}
2023-10-13T20:27:57.789098Z DEBUG ThreadId(04) Incoming response:
<title>429 Too Many Requests</title>

429 Too Many Requests

nginx/1.18.0 (Ubuntu)

ERROR supervisor error: relayer error: RPC error to endpoint https://terra-testnet-rpc.polkachu.com/: serde parse error: expected value at line 1 column 1

Seems like hermes start is doing to many requests. Can I change this?

I guess rate limiter gets into account. Depending in what state hermes is ERROR link initialization failed during channel counterparty verification: failed during a query to chain 'pisco-1': RPC error to endpoint https://terra-testnet-rpc.polkachu.com/: serde parse error: expected value at line 1 column 1 also pops up:
2023-10-13T21:00:53.341733Z  INFO ThreadId(01) running Hermes v1.6.0+1c1cf02
2023-10-13T21:00:53.475585Z DEBUG ThreadId(01) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "6eae7c17-c9b3-40d8-9b4e-9e7e977876cd",
  "method": "status",
  "params": null
}
2023-10-13T21:00:53.688969Z DEBUG ThreadId(01) Incoming response: {"jsonrpc":"2.0","id":"6eae7c17-c9b3-40d8-9b4e-9e7e977876cd","result":{"node_info":{"protocol_version":{"p2p":"8","block":"11","app":"0"},"id":"0d194f5236a420147b05d9556ac0cf928c36e647","listen_addr":"<IP_ADDRESS>:11756","network":"pisco-1","version":"0.37.2","channels":"40202122233038606100","moniker":"hello-terra-testrelay","other":{"tx_index":"on","rpc_address":"tcp://<IP_ADDRESS>:11757"}},"sync_info":{"latest_block_hash":"6F1941D76C211BCF05126C858C4078DAD527D48DBB6AADA36C25123E852BCAFE","latest_app_hash":"D7E6B3E73D400D35B15627EDD7C2066E355972C1358E9615B7A72500FBA9D585","latest_block_height":"7873863","latest_block_time":"2023-10-13T21:00:42.670667975Z","earliest_block_hash":"F9A088A259FC93FED2B053BEB5C097DEC0B3984D975D5E23C882795D9F2AB2E6","earliest_app_hash":"48D600F209AAA3EA64A18444CD99B3E24EA1E65F4DC1925055BA36C424A0724E","earliest_block_height":"6660741","earliest_block_time":"2023-07-25T13:58:54.797854271Z","catching_up":false},"validator_info":{"address":"99281AC70CA77998969E24A595363E81BCF6FFCE","pub_key":{"type":"tendermint/PubKeyEd25519","value":"L1HjhqkxoL+lVG3hgZSR2ktUoil3aJvyxpUNWHSDNkE="},"voting_power":"0"}}}
2023-10-13T21:00:54.473440Z DEBUG ThreadId(04) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "7d842725-b8c5-4f7b-86b1-bc5cafe53626",
  "method": "abci_query",
  "params": {
    "path": "store/ibc/key",
    "data": "6368616E6E656C456E64732F706F7274732F7761736D2E7465727261316C756879326E676A3779306C717933766A656B33786D37373770797770747A7A656130736335796D7534706D61666A726E30377335726C6D78742F6368616E6E656C732F6368616E6E656C2D333534",
    "prove": false
  }
}
2023-10-13T21:00:54.594741Z DEBUG ThreadId(04) Incoming response: {"jsonrpc":"2.0","id":"7d842725-b8c5-4f7b-86b1-bc5cafe53626","result":{"response":{"code":0,"log":"","info":"","index":"0","key":"Y2hhbm5lbEVuZHMvcG9ydHMvd2FzbS50ZXJyYTFsdWh5Mm5najd5MGxxeTN2amVrM3htNzc3cHl3cHR6emVhMHNjNXltdTRwbWFmanJuMDdzNXJsbXh0L2NoYW5uZWxzL2NoYW5uZWwtMzU0","value":"CAMQARpUCkV3YXNtLnN0YXJzMTY1ZnI1ajNlYTBkazV5cjVzcjRoOHV3NzZ6NWZkMzRscG5xYzJ4ODB5YTl4a3g5dTBrM3FqcnFwenESC2NoYW5uZWwtNTkwIg5jb25uZWN0aW9uLTQwOSoIaWNzNzIxLTE=","proofOps":null,"height":"7873864","codespace":""}}}
2023-10-13T21:00:54.719752Z DEBUG ThreadId(04) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "16f53224-729d-4d9d-9646-6b40b4cebc59",
  "method": "abci_query",
  "params": {
    "path": "store/ibc/key",
    "data": "636C69656E74732F30372D74656E6465726D696E742D3435322F636C69656E745374617465",
    "prove": false
  }
}
2023-10-13T21:00:54.776200Z DEBUG ThreadId(04) Incoming response: {"jsonrpc":"2.0","id":"16f53224-729d-4d9d-9646-6b40b4cebc59","result":{"response":{"code":0,"log":"","info":"","index":"0","key":"Y2xpZW50cy8wNy10ZW5kZXJtaW50LTQ1Mi9jbGllbnRTdGF0ZQ==","value":"CisvaWJjLmxpZ2h0Y2xpZW50cy50ZW5kZXJtaW50LnYxLkNsaWVudFN0YXRlEoEBCgllbGdhZmFyLTESBAgBEAMaBAiAnDEiBAiA6kkqAghzMgA6BwgBEP+ltgNCGQoJCAEYASABKgEAEgwKAgABECEYBCAMMAFCGQoJCAEYASABKgEAEgwKAgABECAYASABMAFKB3VwZ3JhZGVKEHVwZ3JhZGVkSUJDU3RhdGVQAVgB","proofOps":null,"height":"7873864","codespace":""}}}
2023-10-13T21:00:54.778287Z DEBUG ThreadId(01) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "0d691d1c-9274-442d-93a7-5c892046b7b3",
  "method": "status",
  "params": null
}
2023-10-13T21:00:54.938875Z DEBUG ThreadId(01) Incoming response: {"jsonrpc":"2.0","id":"0d691d1c-9274-442d-93a7-5c892046b7b3","result":{"node_info":{"protocol_version":{"p2p":"8","block":"11","app":"0"},"id":"89736cec483dd94ad946bb7325eeac9a1528f8e7","listen_addr":"tcp://<IP_ADDRESS>:26656","network":"elgafar-1","version":"0.34.29","channels":"40202122233038606100","moniker":"node1","other":{"tx_index":"on","rpc_address":"tcp://<IP_ADDRESS>:26657"}},"sync_info":{"latest_block_hash":"DA1BA44F24A288C7AF1A542C1341AFE534296026FF24D231EA07F1CB86B00AD7","latest_app_hash":"049FA764DA37CF3E7CF687EF9E4803E76C29BDFEF288A043595748CE21A25FCF","latest_block_height":"7181141","latest_block_time":"2023-10-13T21:00:47.873739366Z","earliest_block_hash":"3AB6080592AE56BDA8EE56123894F09D913EB2FFCD1232839462971C8FFE8B2F","earliest_app_hash":"E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855","earliest_block_height":"1","earliest_block_time":"2022-07-06T18:44:13.502116971Z","catching_up":false},"validator_info":{"address":"CBC8C35D0E967D267D50C745A74BE75F6BDFCDDF","pub_key":{"type":"tendermint/PubKeyEd25519","value":"TYVkCMsi+nGR9i8Hyimz8lb0tIQRZBWFNnUfF20ufgw="},"voting_power":"50125017"}}}
2023-10-13T21:00:54.940853Z DEBUG ThreadId(04) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "a1dd87a9-dff8-46a2-8cc1-3a924b93e794",
  "method": "abci_query",
  "params": {
    "path": "store/ibc/key",
    "data": "6368616E6E656C456E64732F706F7274732F7761736D2E7465727261316C756879326E676A3779306C717933766A656B33786D37373770797770747A7A656130736335796D7534706D61666A726E30377335726C6D78742F6368616E6E656C732F6368616E6E656C2D333534",
    "prove": false
  }
}
2023-10-13T21:00:55.063477Z DEBUG ThreadId(04) Incoming response: {"jsonrpc":"2.0","id":"a1dd87a9-dff8-46a2-8cc1-3a924b93e794","result":{"response":{"code":0,"log":"","info":"","index":"0","key":"Y2hhbm5lbEVuZHMvcG9ydHMvd2FzbS50ZXJyYTFsdWh5Mm5najd5MGxxeTN2amVrM3htNzc3cHl3cHR6emVhMHNjNXltdTRwbWFmanJuMDdzNXJsbXh0L2NoYW5uZWxzL2NoYW5uZWwtMzU0","value":"CAMQARpUCkV3YXNtLnN0YXJzMTY1ZnI1ajNlYTBkazV5cjVzcjRoOHV3NzZ6NWZkMzRscG5xYzJ4ODB5YTl4a3g5dTBrM3FqcnFwenESC2NoYW5uZWwtNTkwIg5jb25uZWN0aW9uLTQwOSoIaWNzNzIxLTE=","proofOps":null,"height":"7873864","codespace":""}}}
2023-10-13T21:00:55.063773Z DEBUG ThreadId(08) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "2ee13776-a48c-4852-84a3-521f55fec070",
  "method": "abci_query",
  "params": {
    "path": "store/ibc/key",
    "data": "6368616E6E656C456E64732F706F7274732F7761736D2E73746172733136356672356A33656130646B357972357372346838757737367A35666433346C706E716332783830796139786B783975306B33716A7271707A712F6368616E6E656C732F6368616E6E656C2D353930",
    "prove": false
  }
}
2023-10-13T21:00:55.198893Z DEBUG ThreadId(08) Incoming response: {"jsonrpc":"2.0","id":"2ee13776-a48c-4852-84a3-521f55fec070","result":{"response":{"code":0,"log":"","info":"","index":"0","key":"Y2hhbm5lbEVuZHMvcG9ydHMvd2FzbS5zdGFyczE2NWZyNWozZWEwZGs1eXI1c3I0aDh1dzc2ejVmZDM0bHBucWMyeDgweWE5eGt4OXUwazNxanJxcHpxL2NoYW5uZWxzL2NoYW5uZWwtNTkw","value":"CAMQARpUCkV3YXNtLnRlcnJhMWx1aHkybmdqN3kwbHF5M3ZqZWszeG03NzdweXdwdHp6ZWEwc2M1eW11NHBtYWZqcm4wN3M1cmxteHQSC2NoYW5uZWwtMzU0Ig5jb25uZWN0aW9uLTU5NyoIaWNzNzIxLTE=","proofOps":null,"height":"7181141","codespace":""}}}
2023-10-13T21:00:55.318743Z DEBUG ThreadId(08) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "d6b2730c-1e18-4c09-83f7-8b2b5e5d18ec",
  "method": "abci_query",
  "params": {
    "path": "store/ibc/key",
    "data": "6368616E6E656C456E64732F706F7274732F7761736D2E73746172733136356672356A33656130646B357972357372346838757737367A35666433346C706E716332783830796139786B783975306B33716A7271707A712F6368616E6E656C732F6368616E6E656C2D353930",
    "prove": false
  }
}
2023-10-13T21:00:55.458099Z DEBUG ThreadId(08) Incoming response: {"jsonrpc":"2.0","id":"d6b2730c-1e18-4c09-83f7-8b2b5e5d18ec","result":{"response":{"code":0,"log":"","info":"","index":"0","key":"Y2hhbm5lbEVuZHMvcG9ydHMvd2FzbS5zdGFyczE2NWZyNWozZWEwZGs1eXI1c3I0aDh1dzc2ejVmZDM0bHBucWMyeDgweWE5eGt4OXUwazNxanJxcHpxL2NoYW5uZWxzL2NoYW5uZWwtNTkw","value":"CAMQARpUCkV3YXNtLnRlcnJhMWx1aHkybmdqN3kwbHF5M3ZqZWszeG03NzdweXdwdHp6ZWEwc2M1eW11NHBtYWZqcm4wN3M1cmxteHQSC2NoYW5uZWwtMzU0Ig5jb25uZWN0aW9uLTU5NyoIaWNzNzIxLTE=","proofOps":null,"height":"7181141","codespace":""}}}
2023-10-13T21:00:55.458358Z DEBUG ThreadId(04) Outgoing request: {
  "jsonrpc": "2.0",
  "id": "00fd73df-6b00-482c-b94e-5325947cd4ee",
  "method": "abci_query",
  "params": {
    "path": "store/ibc/key",
    "data": "6368616E6E656C456E64732F706F7274732F7761736D2E7465727261316C756879326E676A3779306C717933766A656B33786D37373770797770747A7A656130736335796D7534706D61666A726E30377335726C6D78742F6368616E6E656C732F6368616E6E656C2D333534",
    "prove": false
  }
}
2023-10-13T21:00:55.584325Z DEBUG ThreadId(04) Incoming response:
<title>429 Too Many Requests</title>

429 Too Many Requests

nginx/1.18.0 (Ubuntu)

ERROR link initialization failed during channel counterparty verification: failed during a query to chain 'pisco-1': RPC error to endpoint https://terra-testnet-rpc.polkachu.com/: serde parse error: expected value at line 1 column 1

Sometime I also get an ERROR channel wasm.terra1luhy2ngj7y0lqy3vjek3xm777pywptzzea0sc5ymu4pmafjrn07s5rlmxt/channel-354 does not exist on chain pisco-1: RPC error to endpoint https://terra-testnet-rpc.polkachu.com/: serde parse error: expected value at line 1 column 1
Which is quite misleading, since channel does exist!

Sometime I also get an ERROR channel wasm.terra1luhy2ngj7y0lqy3vjek3xm777pywptzzea0sc5ymu4pmafjrn07s5rlmxt/channel-354 does not exist on chain pisco-1: RPC error to endpoint https://terra-testnet-rpc.polkachu.com/: serde parse error: expected value at line 1 column 1
Which is quite misleading, since channel does exist!

Agreed, that's a very misleading error message, we'll fix it.

Seems like hermes start is doing to many requests. Can I change this?

Are you connecting to a public node? If so then there is not much that Hermes can do. I mean we could rate limit the requests that Hermes performs but that would totally kill performance. In general, one cannot expect to be able to operate a relayer using a public node, and should instead use a private, appropriately configured, node.

Seems like hermes start is doing to many requests. Can I change this?

Are you connecting to a public node? If so then there is not much that Hermes can do. I mean we could rate limit the requests that Hermes performs but that would totally kill performance. In general, one cannot expect to be able to operate a relayer using a public node, and should instead use a private, appropriately configured, node.

Yes, connecting to a public node - so not locally. It would be great for having a rate limit flag. Imo, better having a lower performance - than not relaying anything at all.


In case of erroneous publication in the private register, a record remains about the published module

zpm: USER>
zpm: USER>repo -n registry -r -url https://52773b-67379046.labs.learning.intersystems.com/registry/ -user tech -pass demo
zpm: USER>find
(Local Cache) Namespace-local module registry.:
registry https://52773b-67379046.labs.learning.intersystems.com/registry/:
zpm: USER>
zpm: USER>blocksexplorer publish
[blocksexplorer]        Reload START
[blocksexplorer]        Reload SUCCESS
[blocksexplorer]        Module object refreshed.
[blocksexplorer]        Validate START
[blocksexplorer]        Validate SUCCESS
[blocksexplorer]        Compile START
[blocksexplorer]        Compile SUCCESS
[blocksexplorer]        Activate START
[blocksexplorer]        Configure START
[blocksexplorer]        Configure SUCCESS
[blocksexplorer]        Activate SUCCESS
[blocksexplorer]        Package START
Module exported to:
/tmp/dirHMbrdX/blocksexplorer-2.2.1/
Module package generated:
/tmp/dirHMbrdX/blocksexplorer-2.2.1.tgz
[blocksexplorer]        Package SUCCESS
[blocksexplorer]        Register START
[blocksexplorer]        Register SUCCESS
[blocksexplorer]        Publish START
[blocksexplorer]        Publish FAILURE - ERROR #5001: Publishing module, authorization required.
ERROR #5001: Publishing module, authorization required.
zpm: USER>
zpm: USER>find
(Local Cache) Namespace-local module registry.:
blocksexplorer 2.2.1
registry https://52773b-67379046.labs.learning.intersystems.com/registry/:
zpm: USER>

an error will occur during installation, and load - If for some reason it does not get up, the entry about the module in the list will remain.
do I suggest enabling transactions? for install, load and publish

if no Exception then good TCOMMIT
and if there is an error, then TROLLBACK

fixed


Fix cmsincrby method annotation  in ClientInterface

coverage: 77.637%. remained the same when pulling d99bd3b2d7b963ad87923acec4d95d42b8177665 on vjik:patch-1 into dd64569e063390a6eae2d0e18b2f71190c4c11ab on predis:v2.x.


Revising the BrightID Strategy

For context:

As approved by @bonustrack

Changes proposed in this pull request:

Revise the current "brightid" strategy to use Official Registries created by BrightID for snapshot while preserving backward compatibility
Change the "brightid" strategy description to better guide DAOs that need a private registry
Add a new example for the new use case

I'm not very familiar with how snapshot works under the hood, so my implementation might not be best practices, feel free to change the details as long as it matches the following workflow:

This PR will stay a draft until we finished the work on a frontend site for the Official Registry (so regular users can use it properly), and add its link to the strategy description.

The frontend site is finished, currently under internal testing, you can view the source code here: https://github.com/SongADAO/songaday-idchain-registration

SongADAO had finished a frontend site for registering with the official BrightID contract: https://idchain.songadao.org/idchain-registration/
Souce code is available here: https://github.com/SongADAO/songaday-idchain-registration
Technically anyone can implement a similar site for their DAO, or just snapshot users in general.

@ChaituVR I've updated the branch with a version that passes yarn test --strategy=brightid --more=500, please take a look.


Bug 1933779: Support InstallPlan steps upgrading existing ClusterIP Services.

If a ClusterIP-type Service manifest omits the immutable spec field
"ClusterIP", a value is selected automatically when the Service is
created. The catalog operator can patch existing Service resources if
the updated manifest either omits "ClusterIP" or sets "ClusterIP" to
the same value as that of the existing Service.

The retest bot was spinning out because one of the (non-prow) upstream tests hit a flake, and /retest doesn't restart those. Putting a temporary hold to reduce bot spam until the upstream retest finishes.
/hold

/hold cancel

(Patch-Manager) met criteria, approve.

The test failures don't appear connected to this change. I looked at the historical success rate for the 4.5 test job and it's been very low at least as far back as last September and the 4.6+ test jobs are significantly better.


package.json missing lint script .

What is the issue ??
The steps to contribute to project in contributing.md include step  npm run lint but this script is missing in package.json
How To Reproduce bug ??
Steps to reproduce the behavior:

Run npm run lint from your terminal in  the cloned  project  directory on your host machine .

Expected behavior
On running script npm run lint Eslint should lint files successfully without giving errors .
Screenshot

Desktop Environment

OS: Ubuntu 20.04.2 LTS

@saurabhmehta1601 are you LGM-SOC'21 Participant?

No , I'm someone who is new to open source . Sorry , I didn't know this is part of some private event . Can I participation ??

No , I'm someone who is new to open source . Sorry , I didn't know this is part of some private event . Can I participation ??

of course, you can @saurabhmehta1601 open source is for all.


reduce staging puma threads

reduce the number of db connections for staging
Review checklist

[ ] First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
[ ] If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
[ ] If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
[ ] Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

speak now or i'm going to merge this one as the staging connections are at their limits.


Request for license attribution - Skyra Project/Skyra

Hello there,
You may know me as one of the core maintainers / co-owners of the Skyra discord bot (https://github.com/skyra-project/skyra) and core maintainer to the Sapphire project
I was recently made aware of this repository through a contributor to the Sapphire Project who was gracious enough to suggest adding this project to our list of recommended examples (https://github.com/sapphiredev/sapphire-slashies/pull/31). As things go with these kind of processes it is my job to vet the suggestions by looking through the repository in question.
While doing just this, I noticed that many things of this repository are very strongly based on that of Skyra, clearly showing that the basic ideas are generally copied over.
Examples are:

The exact setup of the files on the root
The commit message that is used for Crowdin
The general structure of the README

Logo and badges centered followed by Development -> Requirements & Options and then a header A note regarding self-hosting ...

https://github.com/RTByte/rtbyte/blob/master/.vscode/settings.json referencing the .yarn folder for Yarn v3, despite this project using NPM as package manager.
https://github.com/RTByte/rtbyte/blob/master/src/arguments/channelName.ts and other files being a 1:1 copy

That all said, I would like to formally ask you to add proper license attribution to this repository. Failure to do so will force me to issue a DMCA takedown notice through https://support.github.com/contact/dmca-takedown. Please comply to this request within 7 standard days of this issue being created
You can add proper license attribution by adding a file called THIRD_PARTY_LICENSES to the root of your project with the full content of https://github.com/skyra-project/skyra/blob/main/LICENSE.

Hey @Favna,
I decided to sort this out right away instead of later this weekend as I mentioned during on conversation on Discord.
I've made a couple changes (shown above) that should cover all the third-party attributions in the code. Please let me know if I missed anything, or if any further changes would need to be made. I also took the opportunity to remove the unnecessary inclusion of .yarn in https://github.com/RTByte/rtbyte/blob/master/.vscode/settings.json - thanks for pointing that out!
With the content of the README being different but still following a similar outline and layout, I'll definitely take the time to rewrite it over the next few weeks in good faith. This may however take some time - hope that's alright.
Apologies again for not already having proper license attribution! Thanks for submitting this right away and for being understanding during our interaction over Discord.


added pec

Pondicherry Engineering College - PEC  and now the name changed to Puducherry Technological University (PTU)
Please find the website of the  university https://ptuniv.edu.in/

@coddinginjava I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host pec.edu not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


Dynamic programming on Subsequences using python

Can you please assign this issue to me under the label of the hacktoberfest-accepted label? I would like to work on it.

Please assign this issue to me. I have been working with dynamic programing for a while now, would love to test my skills out on this issue.


The plugin stops working if editor is left idle for a few days

I often hit the following problem when I leave an instance of vim open but inactive for a few days in one of my tmux tabs and then return back to it and try to navigate to a sibling pane (e.g. with <Ctrl-j>):
Error detected while processing function <SNR>23_TmuxWinCmd..<SNR>23_TmuxAwareNavigate..<SNR>23_TmuxCommand..<SNR>23_TmuxOrTmateExecutable..<SNR>23_StrippedSystemCall:
line    1:
E484: Can't open file /tmp/vmyH93K/29
Error detected while processing function <SNR>23_TmuxWinCmd..<SNR>23_TmuxAwareNavigate..<SNR>23_TmuxCommand:
line    2:
E484: Can't open file /tmp/vmyH93K/30
Press ENTER or type command to continue

Looks like the plugin opens some temporary files which are then removed from underneath it if the editor is left inactive for some period of time.
My Vim version is 7.4, OS is Linux, the version of vim-tmux-navigator is latest (i.e. recently pulled from github via Vundle).

Hi @dorserg, the temp file listed above is a tmux socket (I'm guessing). The plugin itself doesn't open any files. I'm guessing your tmux session / server got out of sync and the plugin hit that. We don't cache any values either so I'm guessing this is not the plugin directly, but not sure exactly why you hit this.

Thanks for the prompt answer!
So you're guessing this happens when the tmux itself gets out of sync with the server -- in which case all of the open tmux tabs / vim instances in them would be affected, right? However what I observe is, when I'm actively working in one tab but leave another tab idle for, say, two days, vim instance in the "active" tab keeps working completely fine, but an instance in the "idle" tab experiences the problem. It's true, however, that if I don't connect to the server at all for two days, all of the tabs get affected. Note also that if I exit vim and try to navigate between panes via tmux itself, everything works fine.
I'd be happy to help you debug this problem further. Does the plugin have any knobs I could turn to, say, produce more verbose logging? Any other pointers to help investigate?
Re failed sockets: does the plugin check whether a socket is valid or broken before using it? If it doesn't, can we add checks/retries/debug logging?

After some digging I think I have found the root cause. The tmux socket file format, /tmp/tmux-.../default, didn't match the format of the files from my logs. Also, looking at the plugin source code, we failed even prior to parsing/using the socket, somewhere inside a simple system(...) command.
It turns out system command requires access to a temporary directory (which I guess Vim creates on startup), and if that directory is removed (as is the case on my server where a periodic cron job cleans up stale /tmp files), any system call will fail. The design that

requires access to a tmp directory in case of even very simple "echo-only" commands and
relies on that tmp directory always being present and doesn't try to recreate a new one in case of failure

is quite surprising if you ask me, but that's the way it is. So my workaround is to let Vim use a tmp dir that is not affected by periodic cleanups, e.g. let $TMPDIR = $HOME."/tmp".

Thanks for looking into this, and for sharing a solution.


RuntimeError: copy_if failed to synchronize: cudaErrorAssert: device-side assert triggered

when i was running my own dataset, the following problem arised:
Traceback (most recent call last):
File "run_self_training_ner.py", line 752, in
main()
File "run_self_training_ner.py", line 681, in main
model, global_step, tr_loss, best_dev, best_test = train(args, train_dataset, model_class, config, tokenizer, labels, pad_token_label_id)
File "run_self_training_ner.py", line 353, in train
loss.backward()
File "/anaconda3/envs/bond/lib/python3.7/site-packages/torch/tensor.py", line 150, in backward
torch.autograd.backward(self, gradient, retain_graph, create_graph)
File "/anaconda3/envs/bond/lib/python3.7/site-packages/torch/autograd/init.py", line 99, in backward
allow_unreachable=True)  # allow_unreachable flag
RuntimeError: copy_if failed to synchronize: cudaErrorAssert: device-side assert triggered
Are there any specific requirements for the data format, such as the sentence length?

Sorry to bother, something is wrong with my data path. Now it works.


Run Travis-CI in OSX in addition to Ubuntu

It would be nice to have some sort of automatic testing for OSX to help with troubleshooting for Macs. Here is the documentation for OSX testing through Travis-CI, and here is the documentation for testing on multiple operating systems. It looks like including testing for both should be pretty straightforward.

check the OSX distributions on travis here.

Check out the techniques used here for mac OSX builds. And also perhaps here.

Installing miniconda from the command line might be a solution to getting a reasonable python environment going on OSX.

WARNING: job 621 passed the CI but it looks like realizeCascades did not run properly.  Why??

WARNING: job 621 passed the CI but it looks like realizeCascades did not run properly. Why??

When ROOT output file isn't created at all it seems to pass!!?, that's a bug.

This error comes up on OSX builds. Tried to use the work-around listed in the post.

When ROOT output file isn't created at all it seems to pass!!?, that's a bug.

Shoot. I think this is an oversight on my part. If I run the python script directly I definitely get an error code if the python script fails. Working on a fix now.

@villaa Okay, just fixed this on develop.

When ROOT output file isn't created at all it seems to pass!!?, that's a bug.

I think I now have the OSX compile "working" but still getting a segfault error (only on OSX):  [/usr/lib/system/libsystem_platform.dylib] _sigtramp (no debug info)
Trying to debug this but this thread suggests an X11 issue and the linked issue suggests it could be because ROOT itself or Qt were not compiled with X11 (XQuartz).
I don't know what's with this problem because I'm not even using graphics at all, so why should all this stuff matter?

Still having  some odd segfaults for OSX. Time to bring out the big guns: gdb. I installed with brew like brew install gdb
What ensued was basically a 4 hour code-signing debacle because Mac is annoying. In any case these instructions  eventually worked. Yes, TWO reboots were required.

Update: even after installing and signing gdb am having a lot of trouble correctly running it.  When I finally  get the executable correctly instrumented (I used -g -O0 flag and ran gdb on the original executable NOT the one made with a sudo make command) the gdb program hangs with something like:
Note: this version of macOS has System Integrity Protection.
Because `startup-with-shell' is enabled, gdb has worked around this by
caching a copy of your shell.  The shell used by "run" is now:
    /Users/villaa/Library/Caches/gdb/bin/sh
[New Thread 0x1703 of process 3447]
[New Thread 0x2803 of process 3447]

Instead I'm using lldb because of this snarky post.

while debugging found that the regex library I use to read the input files seems to be failing on OSX, and the behavior is different on Linux.
the library include is: #include<regex.h> and the object I'm using is in src/cascadeProd.c and is of type regex_t and the function regcomp used for the matching is not producing any  matches on OSX (although it is on Linux).

this  is the regular expression i'm playing with to see why it evaluates differently on OSX (Mojave).

On OSX (Mojave) the regex function regcomp() fails with this code: regexec() failed with 'repetition-operator operand invalid'

Ugh, might I have to use boost?

Ok, so I think I just have to avoid using +? and *? as regex operators. I think I was using them incorrectly in the first regex quoted above anyway. They are meant to be taken together to give "lazy" action and I was using the ? to mean zero or one times for an expression like [0-9]+? by which I meant either no digits or any number, but really it was matching any number of digits "lazily."
here is an update of my regex: v2

here is an update of my regex: v3

here is another update: v4

final one that I'll try: v5
This one doesn't have any *? or +?

Making  some progress based on my SO post, can probably start a pull  request. Regex is weird, at least as implemented in regex.h; I was having a lot of trouble with the \s+ so one of the suggestions in my post showed me how to do  that a different way: [[:space:]]  supposedly this is more POSIX.

REALIZATION: even on Linux, the interpretation of scientific notation as double has always failed b/c the function interpretDbl in cascadeProd.c is not good at selecting scientific notation OR other double types.

Addressed with  PR #61


Why are the docs not reflecting the CRD's

What did you do to encounter the bug?
Steps to reproduce the behavior:
On the official docs for AtlasProject, the customRole should have a name called roleName https://www.mongodb.com/docs/atlas/operator/current/atlasproject-custom-resource/#mongodb-setting-spec.customRoles.roleName
But on the CRD its expecting name
What did you expect?
I expect docs and CRD's to have same field specifications
What happened instead?
Docs and CRD's differ in terms of documentation
Screenshots
If applicable, add screenshots to help explain your problem.
Operator Information

2.5.0

Thanks for the report @vmanikes !
Yep that seems to be a mistake in the docs, will report it internally to get it fixed.

@josvazg Thank you. Are the docs internal to mongo or can they be fixed via a PR? I am interested to contribute to this if they can be fixed via a PR

@josvazg Thank you. Are the docs internal to mongo or can they be fixed via a PR? I am interested to contribute to this if they can be fixed via a PR

Let me get back to you on that

Sorry @vmanikes , but docs for this are internal only. No worries, we already created a ticket internally for this.

Thank you @josvazg

what's the project's release cadence? When is 2.6.0 expected to land?

Release 2.6 is in progress now: https://github.com/mongodb/mongodb-atlas-kubernetes/issues/1958


Move to new k6 module API

see https://github.com/grafana/k6/issues/2344 for more info

I was intending on using the github feature but I see it is disabled :(

I was intending on using the github feature but I see it is disabled :(

@MStoykov I enabled "squash merge" :)


Add task versionPolicyExportCompatibilityReport to export the compatibility reports in a machine-readable format (JSON)

I pushed a version that does not shade the ujson dependency. For the record, I am not 100% sure shading works as expected in sbt plugins, especially now that sbt publishes both Maven-conform artifacts and the old style of artifacts.

@rtyley FYI this is released in v3.2.0.


Port and path mappings in PhpStorm 'server' are overridden by the plugin"

Is there an existing issue for this?

[X] I have searched the existing issues

Are you sure that this bug is related to this DDEV Integration Plugin?

[X] I am sure

Enter your error report ID (If available)
No response
Describe the bug
I have the router_http_port option set to 8080, however, upon restart, DDEV changes the server port to 80.
https://github.com/php-perfect/ddev-intellij-plugin/assets/15305350/9e366b65-b68d-4726-9b8f-e0562ad6420a
Steps to reproduce

Set router_http_port to anything other than 80
Update settings on DDEV server inside PHPStorm to use the port selected for router_http_port, and add some custom path mappings for that server.
Restart DDEV
See that server port switched back to 80 in PHPStorm, and path mappings custom config has been removed.

Additional context
No response

I think you might have upgraded to DDEV v1.22+, where router_http_port can be configured either globally or in the project. The project overrides global configuration, and if you have a project that was configured before v1.22, it will have router_http_port already in it, which will override.
AFAIK the plugin doesn't make any changes of any kind to your configuration, so I assume this issue was intended for https://github.com/ddev/ddev/issues
Anyway, I recommend looking at both your project config and your global config and doing what makes sense for you.
I'm surprised that you say:

Update settings on DDEV server inside PHPStorm to use the port selected for router_http_port, and add some custom path mappings for that server.

I remain completely unaware how you can do DDEV configuration inside PhpStorm.

@rfay Hello, the DDEV integration plugin automatically sets up a "DDEV" server on PHPStorm, that's where the issue is located because the port is always being reset to 80 and the path mappings I add there get removed upon restarting DDEV.

Hey @hmouhtar, @rfay,
Updating / overriding the "Server" named "DDEV" is the intended behavior of the plugin.
All configurations (Interpreter, Server, Docker, DataSource, ...) named "DDEV" are automatically managed by the plugin.
@rfay is the http port part of the ddev describe output? In this case we can easily fix this. Currently the plugin assumes the port is always 80.
@hmouhtar in case your configuration does differ from the defaults, or settings it is aware of, you can always create your own "Server". Just give it any other name than "DDEV". The plugin will always create and update the configurations named "DDEV". If there is already an active configuration (Like a selected interpreter) it will keep the one you created manually.
As for "Servers" there is no selection which one should be used by default, I am not sure how PHPStorm behaves if you add another one.
As long as the ddev plugin is not aware of the router_http_port adding a manual "Server" mapping should be the way to go.

@nico-loeber the "port" in the server is (I think) used only for when PhpStorm launches a browser or similar actions. It could be 80, it's normally 443, but it's changed with router_http_port and router_https_port both globally and on the project.
These router-based URLs are displayed in the bottom of ddev describe,

and in the urls element in ddev describe -j

At least with the current DDEV version, this issue is no longer current and applicable.
If you change router_http_port and router_https_port, you're setting the ports with which the webserver is available for external connections. The xDebug connection however needs SERVER_NAME (project domain) and SERVER_PORT (always 80).
For example:

Let's close it and move on.

https://github.com/php-perfect/ddev-intellij-plugin/issues/227 was very important, maybe this was a variant of that one.


Fix tooltip in filter view

The tooltip overrides the label within the category:

The appearance of the tooltips should be improved.

@bikramkawan, this seems to be done, right? If yes, please close the issue. I really don't want to remind you for every issue. So please keep the issues up-to-date.

Sorry I will have look on other open issue also. This is done.

OK, thx.


ghcr.io/parkervcp/games:source not found

When creating a project zomboid seed this error araises

Docker pull the image on your machine to find out more - something is preventing you from being able to pull it.

ghcr.io/parkervcp/games:source is definitly there. So you have a dns issue or girhub registrar is offline

This can also be an issue if you are running on ARM as the images are only built for amd64.

This can also be an issue if you are running on ARM as the images are only built for amd64.

You are right, im am running on arm, theres no way to use this yolk, or another one for project zomboid?


Move things into the title bars of Visual Script nodes.

Previously, EVERY NODE would have a label of text on the row of the primary sequence nodes, which was in a lot of cases ugly and wasted vertical space. Also do we really need half in-code names in the title bars? Waste of space.

This looks nice to me, code also seems fine.

Next time please squash commits together (or if the second commit made sense to keep separate, give it a meaningful name).


Kubelet TLS Bootstrap

Description
This feature is merged into master and will be a pre-alpha feature. Creating a feature for tracking through the rest of the process.
When a kubelet runs for the first time, it must be given TLS assets or generate them itself. In the first case, this is a burden on the cluster admin and a significant logistical barrier to secure Kubernetes rollouts. In the second, the kubelet must self-sign its certificate and forfeits many of the advantages of a PKI system. Instead, we propose that the kubelet generate a private key and a CSR for submission to a cluster-level certificate signing process.
Progress Tracker

[ ] Before Alpha

[x] Write and maintain draft quality doc

[x] During development keep a doc up-to-date about the desired experience of the feature and how someone can try the feature in its current state. Think of it as the README of your new feature and a skeleton for the docs to be written before the Kubernetes release. Paste link to Google Doc: https://docs.google.com/document/d/1D2Km_SeMENDjHLsMw4b6LHLCYzrkP8nuYUV0G-A4Ifc/edit#

[x] Design Approval

[x] Design Proposal.  This goes under docs/proposals.  Doing a proposal as a PR allows line-by-line commenting from community, and creates the basis for later design documentation.  Paste link to merged design proposal here: https://github.com/kubernetes/kubernetes/pull/20439
[x] Initial API review (if API).

https://github.com/kubernetes/kubernetes/pull/25562

[x] My Shepherd is: Brandon Philips<EMAIL_ADDRESS>@philips
[x] My Secondary Contact Point is: Mike Saparov<EMAIL_ADDRESS>@mike-saparov

[x] Write (code + tests + docs) then get them merged.

https://github.com/kubernetes/kubernetes/pull/25764
https://github.com/kubernetes/kubernetes/pull/30094
[x] Code needs to be disabled by default.   Verified by code OWNERS
[ ] Minimal testing
[ ] Minimal docs

cc @kubernetes/docs on docs PR
cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
New apis: Glossary Section Item in the docs repo: kubernetes/kubernetes.github.io

[ ] Update release notes

[ ] Before Beta

[ ] Testing is sufficient for beta
[ ] User docs with tutorials

Updated walkthrough / tutorial in the docs repo: kubernetes/kubernetes.github.io
cc @kubernetes/docs on docs PR
cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

[ ] Thorough API review

cc @kubernetes/api

[ ] Before Stable

[ ] docs/proposals/foo.md moved to docs/design/foo.md

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

[ ] Soak, load testing
[ ] detailed user docs and examples

cc @kubernetes/docs
cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

FEATURE_STATUS: Partially merged into master

cc @kubernetes/sig-node FYI about this feature for Kubelet TLS bootstrap

I think we should consider this pre-alpha until we complete:

kubectl integration
kubelet integration
e2e testing

Is anyone currently working on this?

@mikedanese @gtank should be working on all of those things to get the feature done done.

Current status of what needs to be done:

kubelet needs to use the Certificates API. This will involve one new flag, provisionally --bootstrap-auth-token which will take a long random string. The kubelet uses this token to authenticate its requests to the Certificates API. Cluster-level access control should ensure that it can only be used for certificates requests. When this token exists, if the kubelet can't find TLS assets locally it will generate a fresh keypair and a Certificate Signing Request (CSR) to submit to the API. It will then watch the CSR object for the appearance of an issued certificate before proceeding with registration. It will use the certificate for client cert auth in subsequent API requests.

kubectl needs to fully support CSR objects. This is currently blocked on a problem with the swagger generation and base64-encoded []byte fields. We also need to document the best way of handling the manual approval flow.

Still need to write tests and update all the docs.

Status update:
PR for kubelet TLS bootstrap is up: https://github.com/kubernetes/kubernetes/pull/30094

Kubectl support tracked int kubernetes/kubernetes#30163 with some basic support prs out

Currently in flight:

Implement TLS bootstrap for kubelet using --bootstrap-auth-token https://github.com/kubernetes/kubernetes/pull/30094
Add an option to controller-manager to auto approve all CSRs https://github.com/kubernetes/kubernetes/pull/30153
Kubectl should support CertificateSigningRequest https://github.com/kubernetes/kubernetes/issues/30163
Add a certificate signing request resource printer in kubectl https://github.com/kubernetes/kubernetes/pull/30166

It will use the certificate for client cert auth in subsequent API requests.

The scope of https://github.com/kubernetes/kubernetes/pull/20439/ was around obtaining TLS serving certs. The kubelet's use of this API should probably be limited to obtaining serving certs initially. Since the kubelet already needs API credentials to submit the initial CSR, obtaining client credentials this way doesn't buy us a whole lot from a bootstrapping perspective.

It allows us to bootstrap individual kubelet identities from a single cluster wide shared secret (bearer token for a kubelet-bootstrap user authorized to submit CSRs).

If the goal is to identify kubelets individually so we can partition node permissions (which I am in favor of), multiple identities obtained from a single shared credential aren't meaningful from an auth perspective.
If we just want to identify requests from different nodes for debugging purposes, we can do that with user-agent strings (the same way controllers set up their own client user-agent string)

multiple identities obtained from a single shared credential

I'm not convinced of this. In fact I think this would work equally well if the CSR API was open (didn't require auth[n/z]). The shared secret is a mechanism that prevents a specific dos attack where a user could spam the CSR API with CSRs that would not be approved. @gtank can you weigh in on this?

cc @kubernetes/sig-cluster-lifecycle

@mikedanese @liggitt can we please move the technical discussion about the design of the system to the https://groups.google.com/forum/#!forum/kubernetes-sig-node mailing list.

@liggitt @mikedanese The nodes derive individual identities from the shared token. The token only exists to 1) filter requests meant for other clusters and 2) allow us restrict the nodes from accessing the rest of the API before they have client certs.

Hi all,
I'm sorry for the nag, but it looks like I am still getting messages from
the SIG group and other Kubernetes teams because I'm still listed as a
member on GitHub. I've already left the organization, but apparently that
doesn't cascade down and remove me from teams.
Hope you guys are all doing well!
-John
On Thu, Aug 11, 2016 at 1:54 PM, Brandon Philips<EMAIL_ADDRESS>wrote:

@mikedanese https://github.com/mikedanese @liggitt
https://github.com/liggitt can we please move the technical discussion
about the design of the system to the https://groups.google.com/
forum/#!forum/kubernetes-sig-node mailing list.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/43#issuecomment-239289320,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFMAf0XPM2rG5xFlcux7fPRE0g-20zA8ks5qe4wbgaJpZM4JS7ez
.

hi @johndmulhausen i checked and you're not a member of the organization or any team (that i can find mentioned on this issue).  it may be worth "ignoring" the kubernetes repos per the article below.  i don't see a way to stop notifications on existing issues/prs etc.  feel free to hit me in email if you want to followup.
https://help.github.com/articles/unwatching-repositories/

@philips Is this on target for the 1.4 feature freeze this Friday (Aug 19)?

@pwittrock: based on https://github.com/kubernetes/kubernetes/pull/30094 this feature suddenly started being redesigned in flight after 5 months of work... Any suggestions on how to avoid the major redesign three days before feature freeze are welcome

Occasionally we will realize gaps in designed features as they are implemented.  We definitely need a process that handles that - rushing features to delivery without all the proper technical due diligence being done is going to cause more issues than occasionally features missing a release.  I think everyone involved is trying to find the best and most secure option for the platform here.

@smarterclayton based on PR discussions it would be great if @liggitt and @deads2k could help with parts of the feature, wdyt? any coding / review help is appreciated to address raised concerns.

I believe both of them had been representing sig-auth on the security aspects here - I had not yet seen an update on the remaining issues though.  That's probably appropriate on the linked issue.

Update: kubelet support merged in https://github.com/kubernetes/kubernetes/pull/30922

To be more clear,  kubernetes/kubernetes#30922 only requests the kubelet client cert from API server. We will need follow up work on getting the kubelet serving cert.

Could you create another issue to clarify that?
On Wed, 24 Aug 2016, 00:18 Yifan Gu<EMAIL_ADDRESS>wrote:

To be more clear, kubernetes/kubernetes#30922
https://github.com/kubernetes/kubernetes/pull/30922 only requests the
kubelet client cert from API server. We will need follow up work on getting
the kubelet serving cert.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/43#issuecomment-241910465,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPWS-UriOVAXjKfqJAoP-mRahm9LOxcks5qi3_TgaJpZM4JS7ez
.

@errordeveloper  Basically we need to think about:

How this continues to combine with the work of dynamic kubelet settings https://github.com/kubernetes/kubernetes/issues/27980
How we get the serving cert for kubelet
How to do the cert rotation

Probably need to sync with @kubernetes/sig-auth to get a better idea before creating the issue.

@gtank @yifan-gu Are the docs ready? Please update the docs in https://github.com/kubernetes/kubernetes.github.io, and then add PR numbers and check the docs box in the issue description

@janetkuo, I'll be tracking our progress on creating the docs. Is there anything besides high level "this is how you turn it on" + known issues that you're expecting for the PR?

@calebamiles  That should be fine, and if you could add a link to the PR in this issue that would help me track it.  Thanks!

@gtank @yifan-gu @calebamiles Another ping on docs. Any PRs you can point me to?

I believe we also still need to figure out next steps for including kubelet server certificates as part of the TLS bootstrap. Based on the kubelet authN proposal - this would greatly simplify the deployment of secure clusters.
Initially discussed in: https://github.com/kubernetes/kubernetes/pull/30094 it sounded like something along these lines might be reasonable?

kubelet uses bootstrap-kubeconfig to post client-cert CSR
kubelet retrieves signed certificate and is now a "full-client" of api
kubelet uses client-cert to post a server-cert CSR
kubelet starts api

/cc @gtank @yifan-gu @philips @liggitt

@gtank @yifan-gu @calebamiles Another ping on docs. Any PRs you can point me to?

I can take the item, but what's expected in the doc?
What I can think about is:

Introduce this new flag --experimental-bootstrap-kubeconfig, why we need it.
Explain what it does step by step
Give an example?

Others?
@gtank @aaronlevy

Was an auto-approver in the controller-manager merged? If so, probably help to document that functionality also.
Also maybe "adding your own approver section"?

Yeah, the auto-approver is in. FYI, this repo is meant to be low on
traffic. Let's migrate the discussions elsewhere.
On Tue, 13 Sep 2016, 00:54 Aaron Levy<EMAIL_ADDRESS>wrote:

Was an auto-approver in the controller-manager merged? If so,
probably help to document that functionality also.
Also maybe "adding your own approver section"?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/43#issuecomment-246531802,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPWSzol3PTrv47n-xvFZx3JBQjRvMtYks5qpeYggaJpZM4JS7ez
.

@jaredbhatti @janetkuo, we will hopefully have a docs PR ready today

@calebamiles , Any word on that Docs PR? Please reference if it's up.

@devin-donnelly,  https://github.com/kubernetes/kubernetes.github.io/pull/1246

Great, thanks!

As part of the documentation effort, here's a flow chart for how this works as of the 1.4 release.

We are aiming to bring the certificates API to beta in v1.6.

@gtank @mikedanese @yifan-gu please, provide us with the release notes and documentation PR or link at https://docs.google.com/spreadsheets/d/1nspIeRVNjAQHRslHQD1-6gPv99OcYZLMezrBe3Pfhhg/edit#gid=0
Also, please, select the valid checkpoints at the Progress Tracker.

@idvoretskyi Added Introduces an API for the Kubelet to request TLS certificates from the API server.

So, certificates API will be beta in 1.6, I'm working on a docs PR for that but also trying to unblock upgrade testing first. Will post in the spreadsheet once it's ready.

@yifan-gu I'm speaking about the "Progress Tracker" checkpoints at the heading message.

PR documenting certificates API is here https://github.com/kubernetes/kubernetes.github.io/pull/2939, the kubelet flags are still experimental in 1.6.

@kubernetes/sig-auth-feature-requests @kubernetes/sig-node-feature-requests
Is this going fully to GA in v1.8 or just a subset of it?
What I can see there are different sub-features in this feature:

the csrapprover and csrsigner in the controller-manager
the certificates API group
the CSR post functionality in the kubelet (the --bootstrap-kubeconfig flag)

Which of these features are being worked on in the v1.8 timeframe?

@luxas this depends on the certificates API being GA which I don't see happening in 1.8. There's a lot in early design phase that will either depend on the certificates API in some form (e.g. pod identity, spiffy, istio) or redo the API. I see greater value in getting feedback on the API as these PKI efforts mature than moving to GA in 1.8.

I am trying to use api-server kubelet-client certificate creation as per the TLS Bootstrap guide. While the node join and certificate handshake works fine, it seems that the certificate does not get created correctly.
After the node joined the cluster I get a
certificate is valid for system:node:<nodename>, not for <nodename>
when trying to issue any command on a pod running on that node (i.e. kubectl logs or kubectl exec).
What is missing from the CNF is a proper alt-name for the hostname as it only has the CN set as system:node.
Is this supposed to work already and am I just missing something?

@christianhuening this is a feature development progress tracking issue, not intended for solving user-facing questions.
Please, open an issue at https://github.com/kubernetes/kubernetes/issues (or check if one has been opened before).
Thanks

@mikedanese @kubernetes/sig-auth-feature-requests are you planning to graduate this to GA soon?

@mikedanese it looks as though the docs could use some updating for GA:

built: https://kubernetes.io/docs/admin/kubelet-tls-bootstrapping/
repo: https://github.com/kubernetes/website/blob/master/docs/admin/kubelet-tls-bootstrapping.md

Could you also please update the spreadsheet for 1.10? Thanks!

This didn't make the cut.

This didn't make the cut.

cc @nickchase

@mikedanese can you please update the OP with the new issue template? It will simplify the feature tracking a lot. Thanks
@kubernetes/sig-auth-feature-requests @kubernetes/sig-cluster-lifecycle-feature-requests @kubernetes/sig-node-feature-requests

@mikedanese @kubernetes/sig-auth-feature-requests @kubernetes/sig-cluster-lifecycle-feature-requests @kubernetes/sig-node-feature-requests
Any plans for this in 1.11?
If so, can you please ensure the feature is up-to-date with the appropriate:

Description
Milestone
Assignee(s)
Labels:

stage/{alpha,beta,stable}
sig/*
kind/feature

cc @idvoretskyi

@mikedanese @kubernetes/sig-auth-feature-requests @kubernetes/sig-cluster-lifecycle-feature-requests @kubernetes/sig-node-feature-requests
Any plans for this in 1.11?
cc @justaugustus

@mikedanese -- We're doing one more sweep of the 1.11 Features tracking spreadsheet.
Would you mind filling in any incomplete / blank fields for this feature's line item?

No updates. Bumped to next milestone.

Thanks for the update, @mikedanese!

@mikedanese @kubernetes/sig-auth-feature-requests @kubernetes/sig-cluster-lifecycle-feature-requests @kubernetes/sig-node-feature-requests --
This feature was removed from the previous milestone, so we'd like to check in and see if there are any plans for this in Kubernetes 1.12.
If so, please ensure that this issue is up-to-date with ALL of the following information:

One-line feature description (can be used as a release note):
Primary contact (assignee):
Responsible SIGs:
Design proposal link (community repo):
Link to e2e and/or unit tests:
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
Approver (likely from SIG/area to which feature belongs):
Feature target (which target equals to which milestone):

Alpha release target (x.y)
Beta release target (x.y)
Stable release target (x.y)

Set the following:

Description
Assignee(s)
Labels:

stage/{alpha,beta,stable}
sig/*
kind/feature

Please note that the Features Freeze is July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.
In addition, please be aware of the following relevant deadlines:

Docs deadline (open placeholder PRs): 8/21
Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.
Happy shipping!
/cc @justaugustus @kacole2 @robertsandoval @rajendar38

@kubernetes/sig-auth-feature-requests can we graduate this to stable in v1.12?

@mikedanese @kubernetes/sig-auth-feature-requests @kubernetes/sig-auth-misc --
Feature Freeze is today. Are we planning on graduating this feature in Kubernetes 1.12?
If so, can you make sure everything is up-to-date, so I can include it on the 1.12 Feature tracking spreadsheet?

I'm ok with this going to GA as long as the certificates API remains beta.

Can a GA feature depend on a beta API? What does that mean, support-wise?

I've added this to the 1.12 sheet as stable, but let me know if we need to walk that back.
cc: @kacole2 @wadadli @robertsandoval @rajendar38

I'm ok with this going to GA as long as the certificates API remains beta.

Why not graduate the as-is API to GA and do a v2 in case we need additional features or whatever?

We discussed this in the sig-auth meeting on 8/8, and agreed the bootstrap feature can be promoted to stable, but not the CSR API yet. That means the externally-facing portions of the bootstrap mechanism (bootstrap kubeconfig, etc) will continue to be supported.

Hey there! @philips I'm the wrangler for the Docs this release. Is there any chance I could have you open up a docs PR against the release-1.12 branch as a placeholder? That gives us more confidence in the feature shipping in this release and gives me something to work with when we start doing reviews/edits. Thanks! If this feature does not require docs, could you please update the features tracking spreadsheet to reflect it?

Zach- I filed the feature initially but other folks took over the work. So,
I won't be able to help with the docs. Sorry.
On Mon, Aug 20, 2018 at 2:25 PM Zach Arnold<EMAIL_ADDRESS>wrote:

Hey there! @philips https://github.com/philips I'm the wrangler for the
Docs this release. Is there any chance I could have you open up a docs PR
against the release-1.12 branch as a placeholder? That gives us more
confidence in the feature shipping in this release and gives me something
to work with when we start doing reviews/edits. Thanks! If this feature
does not require docs, could you please update the features tracking
spreadsheet to reflect it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/43#issuecomment-414468340,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACDCOhjX6sz-ErOXML9lrqSGnd4eHTUks5uSykwgaJpZM4JS7ez
.

Ok, thanks for letting me know. Whom shall I ask for this data then in your
opinion?
On Mon, Aug 20, 2018 at 2:26 PM Brandon Philips<EMAIL_ADDRESS>wrote:

Zach- I filed the feature initially but other folks took over the work. So,
I won't be able to help with the docs. Sorry.
On Mon, Aug 20, 2018 at 2:25 PM Zach Arnold<EMAIL_ADDRESS>wrote:

Hey there! @philips https://github.com/philips I'm the wrangler for
the
Docs this release. Is there any chance I could have you open up a docs PR
against the release-1.12 branch as a placeholder? That gives us more
confidence in the feature shipping in this release and gives me something
to work with when we start doing reviews/edits. Thanks! If this feature
does not require docs, could you please update the features tracking
spreadsheet to reflect it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/features/issues/43#issuecomment-414468340
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AACDCOhjX6sz-ErOXML9lrqSGnd4eHTUks5uSykwgaJpZM4JS7ez
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/43#issuecomment-414468895,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE81SF57z1mjfKYZ9QPBQVJHzoItTVRYks5uSymggaJpZM4JS7ez
.

@zparnold please use the assignee of the feature issue rather than the original creator (which is immutable) of the issue for this kind of stuff. I can do this.

Ok, thanks! Learning the ropes around here. :)
On Mon, Aug 20, 2018 at 2:37 PM Mike Danese<EMAIL_ADDRESS>wrote:

@zparnold https://github.com/zparnold please use the assignee of the
feature issue rather than the original creator (which is immutable) of the
issue for this kind of stuff. I can do this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/43#issuecomment-414471622,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE81SHodJlKFUOZaBgWmnDEiCYq5HUr6ks5uSywMgaJpZM4JS7ez
.

@mikedanese Will you be able to handle docs?

GA docs PR here:
https://github.com/kubernetes/website/pull/10232

It looks like this has graduated to GA so I'm going to clean up and close the issue. nice job everyone!
/close


scale! has no effect on an image scene

This used to work for flipping the y axis for an image, but now scale! has no effect on the scene
img = image([1 0; 0 0])
scale!(img, 1, -1, 1)

Makie 0.10.0
Julia 1.4.1

Works for me on master.

Yea seems fine to me