504 Gateway Timeouts

We're looking to use envoy to replace our existing service mesh but are running into a couple of issues during testing.
Setup
Every backend server runs Envoy with an egress and ingress listener. The egress listener serves outgoing HTTP requests (i.e. service-to-service) while the ingress listener receives both service-to-service and incoming connections from the outside world via NGINX.
Every NGINX server runs Envoy with one egress listener. That listener forwards traffic to the ingress listener on the appropriate backend server which then proxies the request to the correct docker container.

We use the CDS, RDS and SDS APIs for all route, cluster and service configuration. Each machine that runs Envoy also runs the CDS, RDS and SDS API. These APIs do blocking queries against Consul.
The egress listener discovers egress routes via the RDS API:
{
  "name": "api-1",
  "domains": [
    "api-1.internal:8180"
  ],
  "routes": [
    {
      "prefix": "/",
      "host_rewrite": "api-1.internal",
      "cluster": "api-1-egress"
    }
  ]
},

while the ingress listener discovers ingress routes via the RDS API:
{
  "name": "api-1",
  "domains": [
    "api-1.internal"
  ],
  "routes": [
    {
      "prefix": "/",
      "host_rewrite": "api-1.internal",
      "cluster": "api-1-ingress"
    }
  ]
},

Each of these clusters maps to a service in Consul via the CDS API:
    {
      "name": "api-1-egress",
      "service_name": "api-1-egress",
      "type": "sds",
      "lb_type": "round_robin",
      "connect_timeout_ms": 250
    },
    {
      "name": "api-1-ingress",
      "service_name": "api-1-ingress",
      "type": "sds",
      "lb_type": "round_robin",
      "connect_timeout_ms": 250
    }

and the service either maps to the port of an ingress listener or docker container depending on whether the cluster is an egress or ingress cluster:
{
  "name": "api-1-egress",
  "hosts": [
    {
      "ip_address": "<IP_ADDRESS>",
      "port": 8181, # port of ingress listener
      "tags": {}
    },
    {
      "ip_address": "<IP_ADDRESS>",
      "port": 8181, # port of ingress listener
      "tags": {}
    }
  ]
}

and:
{
  "name": "api-1-ingress",
  "hosts": [
    {
      "ip_address": "<IP_ADDRESS>", # ip address of eth0
      "port": 27925, # port of docker container on localhost
      "tags": {}
    }
  ]
}

The configuration file /etc/envoy/envoy.json looks like this:
{
  "admin": {
    "access_log_path": "/var/log/envoy/admin.log",
    "address": "tcp://<IP_ADDRESS>:8300"
  },
  "cluster_manager": {
    "cds": {
      "cluster": {
        "connect_timeout_ms": 250,
        "hosts": [
          {
            "url": "tcp://<IP_ADDRESS>:8400"
          }
        ],
        "lb_type": "round_robin",
        "name": "cds",
        "type": "strict_dns"
      },
      "refresh_delay_ms": 15000
    },
    "clusters": [
      {
        "connect_timeout_ms": 250,
        "hosts": [
          {
            "url": "tcp://<IP_ADDRESS>:8401"
          }
        ],
        "lb_type": "round_robin",
        "name": "rds",
        "type": "strict_dns"
      }
    ],
    "sds": {
      "cluster": {
        "connect_timeout_ms": 250,
        "hosts": [
          {
            "url": "tcp://<IP_ADDRESS>:8402"
          }
        ],
        "lb_type": "round_robin",
        "name": "sds",
        "type": "strict_dns"
      },
      "refresh_delay_ms": 15000
    }
  },
  "listeners": [
    {
      "address": "tcp://<IP_ADDRESS>:8180",
      "filters": [
        {
          "config": {
            "codec_type": "auto",
            "filters": [
              {
                "config": {},
                "name": "router",
                "type": "decoder"
              }
            ],
            "rds": {
              "cluster": "rds",
              "route_config_name": "egress"
            },
            "stat_prefix": "egress_http"
          },
          "name": "http_connection_manager",
          "type": "read"
        }
      ]
    },
    {
      "address": "tcp://<IP_ADDRESS>:8181",
      "filters": [
        {
          "config": {
            "codec_type": "auto",
            "filters": [
              {
                "config": {},
                "name": "router",
                "type": "decoder"
              }
            ],
            "rds": {
              "cluster": "rds",
              "route_config_name": "ingress"
            },
            "stat_prefix": "ingress_http"
          },
          "name": "http_connection_manager",
          "type": "read"
        }
      ]
    }
  ]
}

Description of the Issue
HTTP 504 Gateway Timeout
Envoy will send HTTP 504 Gateway Timeout. There is no issue with the service running in the docker container. HTTP requests from cURL to the container do not timeout, neither do requests via Traefik, our current routing software.
We're running Envoy with the DEBUG log level and see the following log lines:
Sep 12 12:09:10 envoy[22399]: [2017-09-12 12:09:10.175][22399][debug][pool] source/common/http/http1/conn_pool.cc:87] queueing request due to no available connections
...
Sep 12 12:09:39 envoy[22399]: [2017-09-12 12:09:39.768][22399][debug][upstream] source/common/upstream/upstream_impl.cc:486] starting async DNS resolution for <IP_ADDRESS>
Sep 12 12:09:39 envoy[22399]: [2017-09-12 12:09:39.768][22399][debug][upstream] source/common/upstream/upstream_impl.cc:493] async DNS resolution complete for <IP_ADDRESS>
Sep 12 12:09:39 envoy[22399]: [2017-09-12 12:09:39.773][22399][debug][upstream] source/common/upstream/upstream_impl.cc:486] starting async DNS resolution for <IP_ADDRESS>
Sep 12 12:09:39 envoy[22399]: [2017-09-12 12:09:39.773][22399][debug][upstream] source/common/upstream/upstream_impl.cc:493] async DNS resolution complete for <IP_ADDRESS>
Sep 12 12:09:39 envoy[22399]: [2017-09-12 12:09:39.773][22399][debug][upstream] source/common/upstream/upstream_impl.cc:486] starting async DNS resolution for <IP_ADDRESS>
Sep 12 12:09:39 envoy[22399]: [2017-09-12 12:09:39.773][22399][debug][upstream] source/common/upstream/upstream_impl.cc:493] async DNS resolution complete for <IP_ADDRESS>

This is in a dev environment with little traffic. The timeouts do not appear to be related to a specific cluster or service as multiple services encounter the same issue at different times (not all at once).

Please provide output of /stats, /clusters, and /server_info admin endpoints for the envoy that is returning the 504.

/clusters:
api-1-egress::<IP_ADDRESS>:8181::cx_active::1
api-1-egress::<IP_ADDRESS>:8181::cx_connect_fail::0
api-1-egress::<IP_ADDRESS>:8181::cx_total::8
api-1-egress::<IP_ADDRESS>:8181::rq_active::1
api-1-egress::<IP_ADDRESS>:8181::rq_timeout::4
api-1-egress::<IP_ADDRESS>:8181::rq_total::9
api-1-egress::<IP_ADDRESS>:8181::health_flags::healthy
api-1-egress::<IP_ADDRESS>:8181::weight::1
api-1-egress::<IP_ADDRESS>:8181::zone::
api-1-egress::<IP_ADDRESS>:8181::canary::false
api-1-egress::<IP_ADDRESS>:8181::success_rate::-1

/stats:
cluster.api-1-egress.external.upstream_rq_204: 1
cluster.api-1-egress.external.upstream_rq_2xx: 5
cluster.api-1-egress.external.upstream_rq_503: 1
cluster.api-1-egress.external.upstream_rq_504: 5
cluster.api-1-egress.external.upstream_rq_5xx: 6
cluster.api-1-egress.lb_healthy_panic: 0
cluster.api-1-egress.lb_local_cluster_not_ok: 0
cluster.api-1-egress.lb_recalculate_zone_structures: 0
cluster.api-1-egress.lb_zone_cluster_too_small: 0
cluster.api-1-egress.lb_zone_no_capacity_left: 0
cluster.api-1-egress.lb_zone_number_differs: 0
cluster.api-1-egress.lb_zone_routing_all_directly: 0
cluster.api-1-egress.lb_zone_routing_cross_zone: 0
cluster.api-1-egress.lb_zone_routing_sampled: 0
cluster.api-1-egress.max_host_weight: 1
cluster.api-1-egress.membership_change: 1
cluster.api-1-egress.membership_healthy: 1
cluster.api-1-egress.membership_total: 1
cluster.api-1-egress.update_attempt: 729
cluster.api-1-egress.update_failure: 0
cluster.api-1-egress.update_rejected: 0
cluster.api-1-egress.update_success: 729
cluster.api-1-egress.upstream_cx_active: 1
cluster.api-1-egress.upstream_cx_close_notify: 0
cluster.api-1-egress.upstream_cx_connect_fail: 0
cluster.api-1-egress.upstream_cx_connect_timeout: 0
cluster.api-1-egress.upstream_cx_destroy: 0
cluster.api-1-egress.upstream_cx_destroy_local: 0
cluster.api-1-egress.upstream_cx_destroy_local_with_active_rq: 5
cluster.api-1-egress.upstream_cx_destroy_remote: 0
cluster.api-1-egress.upstream_cx_destroy_remote_with_active_rq: 1
cluster.api-1-egress.upstream_cx_destroy_with_active_rq: 6
cluster.api-1-egress.upstream_cx_http1_total: 9
cluster.api-1-egress.upstream_cx_http2_total: 0
cluster.api-1-egress.upstream_cx_max_requests: 0
cluster.api-1-egress.upstream_cx_none_healthy: 0
cluster.api-1-egress.upstream_cx_overflow: 0
cluster.api-1-egress.upstream_cx_protocol_error: 0
cluster.api-1-egress.upstream_cx_rx_bytes_buffered: 959
cluster.api-1-egress.upstream_cx_rx_bytes_total: 3176
cluster.api-1-egress.upstream_cx_total: 9
cluster.api-1-egress.upstream_cx_tx_bytes_buffered: 0
cluster.api-1-egress.upstream_cx_tx_bytes_total: 7185
cluster.api-1-egress.upstream_flow_control_backed_up_total: 0
cluster.api-1-egress.upstream_flow_control_drained_total: 0
cluster.api-1-egress.upstream_flow_control_paused_reading_total: 0
cluster.api-1-egress.upstream_flow_control_resumed_reading_total: 0
cluster.api-1-egress.upstream_rq_200: 4
cluster.api-1-egress.upstream_rq_204: 1
cluster.api-1-egress.upstream_rq_2xx: 5
cluster.api-1-egress.upstream_rq_503: 1
cluster.api-1-egress.upstream_rq_504: 5
cluster.api-1-egress.upstream_rq_5xx: 6
cluster.api-1-egress.upstream_rq_active: 0
cluster.api-1-egress.upstream_rq_cancelled: 0
cluster.api-1-egress.upstream_rq_maintenance_mode: 0
cluster.api-1-egress.upstream_rq_pending_active: 0
cluster.api-1-egress.upstream_rq_pending_failure_eject: 0
cluster.api-1-egress.upstream_rq_pending_overflow: 0
cluster.api-1-egress.upstream_rq_pending_total: 9
cluster.api-1-egress.upstream_rq_per_try_timeout: 0
cluster.api-1-egress.upstream_rq_retry: 0
cluster.api-1-egress.upstream_rq_retry_overflow: 0
cluster.api-1-egress.upstream_rq_retry_success: 0
cluster.api-1-egress.upstream_rq_rx_reset: 0
cluster.api-1-egress.upstream_rq_timeout: 5
cluster.api-1-egress.upstream_rq_total: 11
cluster.api-1-egress.upstream_rq_tx_reset: 0
filesystem.flushed_by_timer: 34
filesystem.reopen_failed: 0
filesystem.write_buffered: 12
filesystem.write_completed: 7
filesystem.write_total_buffered: 122
http.admin.downstream_cx_active: 1
http.admin.downstream_cx_destroy: 12
http.admin.downstream_cx_destroy_active_rq: 0
http.admin.downstream_cx_destroy_local: 0
http.admin.downstream_cx_destroy_local_active_rq: 0
http.admin.downstream_cx_destroy_remote: 12
http.admin.downstream_cx_destroy_remote_active_rq: 0
http.admin.downstream_cx_drain_close: 0
http.admin.downstream_cx_http1_active: 1
http.admin.downstream_cx_http1_total: 13
http.admin.downstream_cx_http2_active: 0
http.admin.downstream_cx_http2_total: 0
http.admin.downstream_cx_idle_timeout: 0
http.admin.downstream_cx_protocol_error: 0
http.admin.downstream_cx_rx_bytes_buffered: 83
http.admin.downstream_cx_rx_bytes_total: 1095
http.admin.downstream_cx_ssl_active: 0
http.admin.downstream_cx_ssl_total: 0
http.admin.downstream_cx_total: 13
http.admin.downstream_cx_tx_bytes_buffered: 0
http.admin.downstream_cx_tx_bytes_total: 1032167
http.admin.downstream_cx_websocket_active: 0
http.admin.downstream_cx_websocket_total: 0
http.admin.downstream_flow_control_paused_reading_total: 0
http.admin.downstream_flow_control_resumed_reading_total: 0
http.admin.downstream_rq_2xx: 11
http.admin.downstream_rq_3xx: 0
http.admin.downstream_rq_4xx: 1
http.admin.downstream_rq_5xx: 0
http.admin.downstream_rq_active: 1
http.admin.downstream_rq_http1_total: 13
http.admin.downstream_rq_http2_total: 0
http.admin.downstream_rq_non_relative_path: 0
http.admin.downstream_rq_non_ws_on_ws_route: 0
http.admin.downstream_rq_response_before_rq_complete: 0
http.admin.downstream_rq_rx_reset: 0
http.admin.downstream_rq_total: 13
http.admin.downstream_rq_tx_reset: 0
http.admin.downstream_rq_ws_on_non_ws_route: 0
http.admin.tracing.tracing.client_enabled: 0
http.admin.tracing.tracing.health_check: 0
http.admin.tracing.tracing.not_traceable: 0
http.admin.tracing.tracing.random_sampling: 0
http.admin.tracing.tracing.service_forced: 0
http.async-client.no_route: 0
http.async-client.rq_redirect: 0
http.async-client.rq_total: 41556
http.egress_http.downstream_cx_active: 4
http.egress_http.downstream_cx_destroy: 69
http.egress_http.downstream_cx_destroy_active_rq: 6
http.egress_http.downstream_cx_destroy_local: 0
http.egress_http.downstream_cx_destroy_local_active_rq: 0
http.egress_http.downstream_cx_destroy_remote: 69
http.egress_http.downstream_cx_destroy_remote_active_rq: 6
http.egress_http.downstream_cx_drain_close: 0
http.egress_http.downstream_cx_http1_active: 4
http.egress_http.downstream_cx_http1_total: 73
http.egress_http.downstream_cx_http2_active: 0
http.egress_http.downstream_cx_http2_total: 0
http.egress_http.downstream_cx_idle_timeout: 0
http.egress_http.downstream_cx_protocol_error: 0
http.egress_http.downstream_cx_rx_bytes_buffered: 2686
http.egress_http.downstream_cx_rx_bytes_total: 294465
http.egress_http.downstream_cx_ssl_active: 0
http.egress_http.downstream_cx_ssl_total: 0
http.egress_http.downstream_cx_total: 73
http.egress_http.downstream_cx_tx_bytes_buffered: 0
http.egress_http.downstream_cx_tx_bytes_total: 2457386
http.egress_http.downstream_cx_websocket_active: 0
http.egress_http.downstream_cx_websocket_total: 0
http.egress_http.downstream_flow_control_paused_reading_total: 0
http.egress_http.downstream_flow_control_resumed_reading_total: 0
http.egress_http.downstream_rq_2xx: 248
http.egress_http.downstream_rq_3xx: 0
http.egress_http.downstream_rq_4xx: 2
http.egress_http.downstream_rq_5xx: 92
http.egress_http.downstream_rq_active: 0
http.egress_http.downstream_rq_http1_total: 342
http.egress_http.downstream_rq_http2_total: 0
http.egress_http.downstream_rq_non_relative_path: 0
http.egress_http.downstream_rq_non_ws_on_ws_route: 0
http.egress_http.downstream_rq_response_before_rq_complete: 0
http.egress_http.downstream_rq_rx_reset: 6
http.egress_http.downstream_rq_total: 342
http.egress_http.downstream_rq_tx_reset: 0
http.egress_http.downstream_rq_ws_on_non_ws_route: 0
http.egress_http.no_route: 0
http.egress_http.rds.config_reload: 1
http.egress_http.rds.update_attempt: 371
http.egress_http.rds.update_failure: 0
http.egress_http.rds.update_rejected: 0
http.egress_http.rds.update_success: 371
http.egress_http.rq_redirect: 0
http.egress_http.rq_total: 342
http.egress_http.tracing.client_enabled: 0
http.egress_http.tracing.health_check: 0
http.egress_http.tracing.not_traceable: 0
http.egress_http.tracing.random_sampling: 0
http.egress_http.tracing.service_forced: 0
http.ingress_http.downstream_cx_active: 0
http.ingress_http.downstream_cx_destroy: 0
http.ingress_http.downstream_cx_destroy_active_rq: 0
http.ingress_http.downstream_cx_destroy_local: 0
http.ingress_http.downstream_cx_destroy_local_active_rq: 0
http.ingress_http.downstream_cx_destroy_remote: 0
http.ingress_http.downstream_cx_destroy_remote_active_rq: 0
http.ingress_http.downstream_cx_drain_close: 0
http.ingress_http.downstream_cx_http1_active: 0
http.ingress_http.downstream_cx_http1_total: 0
http.ingress_http.downstream_cx_http2_active: 0
http.ingress_http.downstream_cx_http2_total: 0
http.ingress_http.downstream_cx_idle_timeout: 0
http.ingress_http.downstream_cx_protocol_error: 0
http.ingress_http.downstream_cx_rx_bytes_buffered: 0
http.ingress_http.downstream_cx_rx_bytes_total: 0
http.ingress_http.downstream_cx_ssl_active: 0
http.ingress_http.downstream_cx_ssl_total: 0
http.ingress_http.downstream_cx_total: 0
http.ingress_http.downstream_cx_tx_bytes_buffered: 0
http.ingress_http.downstream_cx_tx_bytes_total: 0
http.ingress_http.downstream_cx_websocket_active: 0
http.ingress_http.downstream_cx_websocket_total: 0
http.ingress_http.downstream_flow_control_paused_reading_total: 0
http.ingress_http.downstream_flow_control_resumed_reading_total: 0
http.ingress_http.downstream_rq_2xx: 0
http.ingress_http.downstream_rq_3xx: 0
http.ingress_http.downstream_rq_4xx: 0
http.ingress_http.downstream_rq_5xx: 0
http.ingress_http.downstream_rq_active: 0
http.ingress_http.downstream_rq_http1_total: 0
http.ingress_http.downstream_rq_http2_total: 0
http.ingress_http.downstream_rq_non_relative_path: 0
http.ingress_http.downstream_rq_non_ws_on_ws_route: 0
http.ingress_http.downstream_rq_response_before_rq_complete: 0
http.ingress_http.downstream_rq_rx_reset: 0
http.ingress_http.downstream_rq_total: 0
http.ingress_http.downstream_rq_tx_reset: 0
http.ingress_http.downstream_rq_ws_on_non_ws_route: 0
http.ingress_http.no_route: 0
http.ingress_http.rds.config_reload: 1
http.ingress_http.rds.update_attempt: 370
http.ingress_http.rds.update_failure: 0
http.ingress_http.rds.update_rejected: 0
http.ingress_http.rds.update_success: 370
http.ingress_http.rq_redirect: 0
http.ingress_http.rq_total: 0
http.ingress_http.tracing.client_enabled: 0
http.ingress_http.tracing.health_check: 0
http.ingress_http.tracing.not_traceable: 0
http.ingress_http.tracing.random_sampling: 0
http.ingress_http.tracing.service_forced: 0
listener.<IP_ADDRESS>_8180.downstream_cx_active: 4
listener.<IP_ADDRESS>_8180.downstream_cx_destroy: 69
listener.<IP_ADDRESS>_8180.downstream_cx_proxy_proto_error: 0
listener.<IP_ADDRESS>_8180.downstream_cx_total: 73
listener.<IP_ADDRESS>_8181.downstream_cx_active: 0
listener.<IP_ADDRESS>_8181.downstream_cx_destroy: 0
listener.<IP_ADDRESS>_8181.downstream_cx_proxy_proto_error: 0
listener.<IP_ADDRESS>_8181.downstream_cx_total: 0
listener.admin.downstream_cx_active: 1
listener.admin.downstream_cx_destroy: 12
listener.admin.downstream_cx_proxy_proto_error: 0
listener.admin.downstream_cx_total: 13
listener_manager.listener_added: 2
listener_manager.listener_create_failure: 0
listener_manager.listener_create_success: 2
listener_manager.listener_modified: 0
listener_manager.listener_removed: 0
listener_manager.total_listeners_active: 2
listener_manager.total_listeners_draining: 0
listener_manager.total_listeners_warming: 0
server.days_until_first_cert_expiring:<PHONE_NUMBER>
server.live: 1
server.memory_allocated: 3402040
server.memory_heap_size: 6291456
server.parent_connections: 0
server.total_connections: 4
server.uptime: 16685
server.version: 11030655
server.watchdog_mega_miss: 0
server.watchdog_miss: 1
stats.overflow: 0

/server-info:
envoy a8507f67225cdd912712971bf72d41f219eb74ed/Modified/DEBUG live 16742 16742 0

One correlation I've observed is that requests tend to timeout on the first request after some idle time (on average somewhere around 30 seconds idle). Subsequent requests do not timeout until the next idle time.

Can you please provide a full log at debug or trace level that shows the timeouts?

It might be related to https://github.com/lyft/envoy/issues/1620 because we never see the timeouts in the logs, even when running Envoy in debug mode.
We first thought the issue was fixed when we upgraded to 1.4.0 but it appears not. Will update 1620 and we can go from there.

Closing since we are tracking same issue in https://github.com/lyft/envoy/issues/1620

Just one feedback. You don't need strict dns when the hosts in the cluster
are IP addresses. You can just specify static as the type.
On Wed, Sep 13, 2017 at 7:21 PM Matt Klein<EMAIL_ADDRESS>wrote:

Closed #1623 https://github.com/lyft/envoy/issues/1623.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lyft/envoy/issues/1623#event-1248244510, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AH0qd8fXh5vPTqEVpPBkLrtJyKzGYLfzks5siGNkgaJpZM4PUw5Q
.

--
~shriram

Oh, we tried that but Envoy doesn't start when using static:
Sep 14 14:26:15 envoy[30044]: [2017-09-14 14:26:15.546][30044][warning][main] source/server/server.cc:151] initializing epoch 0 (hot restart version=8.2490552)
Sep 14 14:26:15 envoy[30044]: [2017-09-14 14:26:15.549][30044][critical][main] source/server/server.cc:71] error initializing configuration '/etc/envoy/envoy.json': JSON at lines 35-45 does not conform to schema.
Sep 14 14:26:15 envoy[30044]:  Invalid schema: #/properties/type
Sep 14 14:26:15 envoy[30044]:  Schema violation: enum
Sep 14 14:26:15 envoy[30044]:  Offending document key: #/type
Sep 14 14:26:15 systemd[1]: envoy.service: Main process exited, code=exited, status=1/FAILURE


Intersection between $Shape and regular object generates false errors

TRY
// @flow

type Base = {
  s: string,
  n: number,
}

type T = {
  x: number
} & $Shape<Base>

const t: T = {
  s: 'dfg',
  x: 133,
}

In case of usage intersection between regular object type and $Shape object, flow says x is missing in object literal, but obviously x is present.
Possible related issue #5702

I can't speak on the error, but you could spread $Shape<Base> into T: Try Flow.

I wish Flow would just outright bail on object intersections because they're completely error prone if any of the types are mutable in my experience

Works if you use the safe replacement, $Partial:
https://flow.org/try/#0PTAEAEDMBsHsHcBQiAuBPADgU1AIQIYDOOAvKAN6KiiEBcNKATgJYB2A5gDRWiv2sBXALYAjLI24BfZOmygAKqDKVqAD37CxjRJNAAyUABIACvkYpm+aAB4CxAHzIAxrFaEUoFPUXKedUADkACaQ7AHcavQAjADMMVJAA
https://flow.org/en/docs/types/utilities/#toc-partial


[BUG] Cannot Import Harvester v1.3-head into Rancher v2.9.0-rc1 Through vCluster

Describe the bug
Cannot import Harvester  Version: v1.3-95b4f9dc-head  into Rancher v2.9.0-rc1 from charts/latest.
Loadout Rancher vCluster Addon YAML:
apiVersion: harvesterhci.io/v1beta1
kind: Addon
metadata:
  creationTimestamp: '2024-05-22T20:27:54Z'
  generation: 2
  labels:
    addon.harvesterhci.io/experimental: 'true'
  managedFields:
    - apiVersion: harvesterhci.io/v1beta1
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:labels:
            .: {}
            f:addon.harvesterhci.io/experimental: {}
        f:spec:
          .: {}
          f:chart: {}
          f:repo: {}
          f:version: {}
      manager: kubectl-create
      operation: Update
      time: '2024-05-22T20:27:54Z'
    - apiVersion: harvesterhci.io/v1beta1
      fieldsType: FieldsV1
      fieldsV1:
        f:spec:
          f:enabled: {}
          f:valuesContent: {}
      manager: harvester
      operation: Update
      time: '2024-05-22T20:30:40Z'
    - apiVersion: harvesterhci.io/v1beta1
      fieldsType: FieldsV1
      fieldsV1:
        f:status:
          .: {}
          f:conditions: {}
          f:status: {}
      manager: harvester
      operation: Update
      subresource: status
      time: '2024-05-22T20:30:50Z'
  name: rancher-vcluster
  namespace: rancher-vcluster
  resourceVersion: '92935'
  uid: fbe9a64c-7d5b-486c-9d3b-2849a3f55d5c
spec:
  chart: vcluster
  enabled: true
  repo: https://charts.loft.sh
  valuesContent: |
    hostname: rancher.<IP_ADDRESS>.sslip.io
    rancherVersion: v2.9.0-rc1
    bootstrapPassword: testtesttest
    vcluster:
      image: rancher/k3s:v1.27.10-k3s2
    sync:
      ingresses:
        enabled: 'true'
    init:
      manifestsTemplate: |-
        apiVersion: v1
        kind: Namespace
        metadata:
          name: cattle-system
        ---
        apiVersion: v1
        kind: Namespace
        metadata:
          name: cert-manager
          labels:
            certmanager.k8s.io/disable-validation: "true"
        ---
        apiVersion: helm.cattle.io/v1
        kind: HelmChart
        metadata:
          name: cert-manager
          namespace: kube-system
        spec:
          targetNamespace: cert-manager
          repo: https://charts.jetstack.io
          chart: cert-manager
          version: v1.5.1
          helmVersion: v3
          set:
            installCRDs: "true"
        ---
        apiVersion: helm.cattle.io/v1
        kind: HelmChart
        metadata:
          name: rancher
          namespace: kube-system
        spec:
          targetNamespace: cattle-system
          repo: https://releases.rancher.com/server-charts/latest/
          chart: rancher
          version: {{ .Values.rancherVersion }}
          set:
            ingress.tls.source: rancher
            hostname: {{ .Values.hostname }}
            replicas: 3
            global.cattle.psp.enabled: "false"
            bootstrapPassword: {{ .Values.bootstrapPassword | quote }}
          helmVersion: v3
  version: v0.19.0
status:
  conditions:
    - lastUpdateTime: '2024-05-22T20:30:50Z'
      status: 'True'
      type: Completed
    - lastUpdateTime: '2024-05-22T20:30:50Z'
      status: 'False'
      type: InProgress
    - lastUpdateTime: '2024-05-22T20:27:54Z'
      status: 'False'
      type: OperationFailed
  status: AddonDeploySuccessful

To Reproduce
Steps to reproduce the behavior:

Enable vCluster Addon: kubectl create -f https://raw.githubusercontent.com/harvester/experimental-addons/main/rancher-vcluster/rancher-vcluster.yaml
Set the addon YAML loadout to take a similar shape
Save Addon
Navigate to rancher.IPV4Numbers.sslip.io
Log in -> create Harvester Cluster
Set Harvester cluster registration url

Expected behavior
Import to be successful in less than 20min.
Support bundle
supportbundle_574ec8ac-893b-45ff-af71-0d3cf66e5dcf_2024-05-22T20-44-25Z.zip
Environment

Harvester ISO version:  Version: v1.3-95b4f9dc-head
Underlying Infrastructure: Single Node, HP DL160, 16C 64GB Mem

Additional context

Additionally validated that a generalized pod:
https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/
Utilizing host-network can indeed make the curl request and communicate to the endpoint as I don't believe DNS is an issue.
Additionally, it looks like Cattle Cluster Agent is happy with:
2024-05-22T20:35:12.923606844Z INFO: Environment: CATTLE_ADDRESS=<IP_ADDRESS> CATTLE_CA_CHECKSUM=a9b9f6b53d53c4f37f59cdf3d6f34effda3cf6ba126e740290e88be642062096 CATTLE_CLUSTER=true CATTLE_CLUSTER_AGENT_PORT=t
cp://<IP_ADDRESS>:80 CATTLE_CLUSTER_AGENT_PORT_443_TCP=tcp://<IP_ADDRESS>:443 CATTLE_CLUSTER_AGENT_PORT_443_TCP_ADDR=<IP_ADDRESS> CATTLE_CLUSTER_AGENT_PORT_443_TCP_PORT=443 CATTLE_CLUSTER_AGENT_PORT_443_TC
P_PROTO=tcp CATTLE_CLUSTER_AGENT_PORT_80_TCP=tcp://<IP_ADDRESS>:80 CATTLE_CLUSTER_AGENT_PORT_80_TCP_ADDR=<IP_ADDRESS> CATTLE_CLUSTER_AGENT_PORT_80_TCP_PORT=80 CATTLE_CLUSTER_AGENT_PORT_80_TCP_PROTO=tcp CATT
LE_CLUSTER_AGENT_SERVICE_HOST=<IP_ADDRESS> CATTLE_CLUSTER_AGENT_SERVICE_PORT=80 CATTLE_CLUSTER_AGENT_SERVICE_PORT_HTTP=80 CATTLE_CLUSTER_AGENT_SERVICE_PORT_HTTPS_INTERNAL=443 CATTLE_CLUSTER_REGISTRY= CATTLE_
FEATURES=embedded-cluster-api=false,fleet=false,multi-cluster-management=false,multi-cluster-management-agent=true,provisioningv2=false,rke2=false CATTLE_INGRESS_IP_DOMAIN=sslip.io CATTLE_INSTALL_UUID=185e87a
0-59a0-4a68-ae07-cbc5f98d8598 CATTLE_INTERNAL_ADDRESS= CATTLE_IS_RKE=false CATTLE_K8S_MANAGED=true CATTLE_NODE_NAME=cattle-cluster-agent-7bfc76b454-njt79 CATTLE_RANCHER_WEBHOOK_VERSION= CATTLE_SERVER=https://
rancher.<IP_ADDRESS>.sslip.io CATTLE_SERVER_VERSION=v2.9.0-rc1
2024-05-22T20:35:12.926099915Z INFO: Using resolv.conf: search cattle-system.svc.cluster.local svc.cluster.local cluster.local nameserver <IP_ADDRESS> options ndots:5
2024-05-22T20:35:13.116431465Z INFO: https://rancher.<IP_ADDRESS>.sslip.io/ping is accessible
2024-05-22T20:35:13.124986034Z INFO: rancher.<IP_ADDRESS>.sslip.io resolves to <IP_ADDRESS>
2024-05-22T20:35:13.181892581Z INFO: Value from https://rancher.<IP_ADDRESS>.sslip.io/v3/settings/cacerts is an x509 certificate
2024-05-22T20:35:13.365825589Z time="2024-05-22T20:35:13Z" level=info msg="Listening on /tmp/log.sock"
2024-05-22T20:35:13.365852329Z time="2024-05-22T20:35:13Z" level=info msg="Rancher agent version v2.9.0-rc1 is starting"
2024-05-22T20:35:13.385164814Z time="2024-05-22T20:35:13Z" level=info msg="Connecting to wss://rancher.<IP_ADDRESS>.sslip.io/v3/connect/register with token starting with jtjmtpzz8c4r8qbg8g5sqdjrvb2"
2024-05-22T20:35:13.385180086Z time="2024-05-22T20:35:13Z" level=info msg="Connecting to proxy" url="wss://rancher.<IP_ADDRESS>.sslip.io/v3/connect/register"
2024-05-22T20:35:13.516835292Z time="2024-05-22T20:35:13Z" level=info msg="Starting /v1, Kind=Service controller"

Additional Note

This did not seem to affect master-head on Harvester, only v1.3-head, as previously it had been tested with Master-Head branch inadvertently in:
https://github.com/harvester/harvester/issues/5506#issuecomment-2118252407

Trying again on vCluster:

It was able to add it, but met with message:
Failed to load script from 'https://rancher.<IP_ADDRESS>.sslip.io/dashboard/c/_/harvesterManager/harvester-1.0.3/harvester-1.0.3.umd.min.js'
error { target: script, isTrusted: true, srcElement: script, eventPhase: 0, bubbles: false, cancelable: false, returnValue: true, defaultPrevented: false, composed: false, timeStamp: 19194, … }
plugins.js:126:20
    onerror plugins.js:126

Additionally noticing on Networks Tab,
lost connection to cluster: failed to find Session for client stv-cluster-c-m-p429fgkc

Closing out as reducing the Rancher Replicas to 1 fixes this

Re-opening - pending investigation on 3 replicas.

Have you tried with 'stable' versions of Harvester/Rancher? I never did, but it would probably be a good idea to have the option to test this.
IIRC, vcluster works by spinning up a K3s container in a separate namespace. I'm not sure right now how much of the state of this K3s cluster is visible to the K8s of the Harvester cluster, but it could be that the ingress of the K8s cluster of Harvester isn't aware that there are multiple backends to talk to. Unfortunately the supportbundle doesn't contain logs or manifests from inside the vcluster.

@m-ildefons did just try with the stable (v2.8.2) & then latest (v2.9.0-rc1) -> both with three replicas and didn't notice any issues /shrug-emoji
This seems like it happens very rarely.
I'll go ahead and close this out :smile: :+1:


overloading assignment operator to work with cv::Mat

In many applications where we use opencv, we generally transfer data between Frame class and cv::Mat. To make that easier "=" operator may be used, for example
Frame = cv::Mat;
or
cv::Mat = Frame;
In order to not make Frame library directly depend on opencv, we can check if system has opencv (inside Cmake) then use preproccessor (#ifdef) to compile with this feauture, if system doesnt have opencv it wont affect usual working of Frame class.

Frame should not have dependencies from OpenCv


feat: add Automatic-Module-Name to manifest (#324)

2/3 for #324
As stated in #325 by @elharo , Automatic-Module-Name need to be in submodules and not in parent.
lmk if everything is okay.

Thanks @elharo & @chingor13 for the suggestions.

The credentials module was included. It's the com.google.auth module as that artifact is providing classes in that root package.

My mistake. Sorry.


Use a generic result/either type

Move explicitly defined result types to a generic result such as https://github.com/antitypical/Result or a native either type if added by Apple

Closing this issue for now. I had hopes something would have been introduced at the language level by this point. There isn't really a need to track this as a github issue.


Wave sort in C++

I want to add an algorithm of Wave sort.
@Kumar-laxmi sir please assign me this issue.

I want to add an algorithm of Wave sort. @Kumar-laxmi sir please assign me this issue.

Which language would you like to work on?

In C++ sir

@Kumar-laxmi  in C assign it to me

Assigned!
@atul1510 : C++
@vijay-kumar-yadav : C

@Kumar-laxm I am ready to work on this issue please assign this issue in java

@mvpamansingh What is your status on this algorithm?

@Kumar-laxmi can I please contribute later, I have exams now

assign this issue to me in c @Kumar-laxmi


_secret_questions setting is undocumented

The _secret_questions setting
https://github.com/copier-org/copier/blob/608654a03e748a3ed1b032c089e20b2811a0cfd3/tests/test_answersfile.py#L34-L35
is not documented. I think it's a redundant setting since a question supports the secret flag as well. In any case, the docs and capabilities should be in sync.
Which solution do you prefer?

Document this setting.
Remove support for this setting in the code.

It's there to provide support for secrets when you're using the simplified questionary format:
_secret_questions:
  - password

user: example
password: secret

So I guess it's better to document it.

Ah, that makes sense. I hadn't thought about the simplified questionary format. I'll send a PR that extends the documentation.


Staging CDK: Allow releasing to the staging repository from any branch.

Description
Release builds will happen off of branches for different versions. e.g. 1.3., 1.4. Thus, the release process must be able to run from any branch.
Issues Resolved
N/A
Check List

[x] New functionality includes testing.
[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[x] Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #1143 (1d8b9a3) into main (7f8d83d) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main    #1143   +/-   ##
=========================================
  Coverage     91.32%   91.32%
  Complexity      692      692
=========================================
  Files            85       85
  Lines          2017     2017
  Branches        170      170
=========================================
  Hits           1842     1842
  Misses          133      133
  Partials         42       42

Continue to review full report at Codecov.

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


Failed to dial <IP_ADDRESS>:2379: connection error: desc = "transport: authentication handshake failed: context canceled"; please retry.

Rancher versions:
rancher/rancher: 2.0.0
rancher/rancher-agent: 2.0.0
Docker version: (docker version,docker info preferred)
17.03.2-ce
Operating system and kernel: (cat /etc/os-release, uname -r preferred)
RancherOS 1.3.0
Type/provider of hosts: (VirtualBox/Bare-metal/AWS/GCE/DO)
AWS
Setup details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single node rancher
Steps to Reproduce:
None, my last login was May 18. This seems to have occurred May 20.
Results:
I think the title is the error message which matters. But correct me if I'm wrong.
I've attached the logs of the rancher/rancher container. rancher.log
Btw, I'm unable to restart the container. Even with docker kill...

Exact same error with:
Operating system and kernel:
CentOS 7 (3.10.0-693.17.1.el7.x86_64)
Type/provider of hosts:
Citrix XenServer
Results:
Unable to restart the container

Same problem happened to me.

What are the host specs and logging? Docker daemon logging regarding the container? All logs indicate overloaded/insufficient specifications for the used host, what are the specs?

Instance type is EC2 T2.medium (running RancherOS 1.3.0)
rancher/rancher:2.0.2 container logs

E0531 07:52:44.622866       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:44.742051       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:45.200396       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:45.266200       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:45.386262       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:46.186091       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:46.284039       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:47.061126       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:47.279570       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:47.536281       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:47.810058       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:47.970069       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:48.514869       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:48.582092       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:48.582524       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.Service: Get https://<IP_ADDRESS>:6443/api/v1/watch/services?resourceVersion=1798963&timeoutSeconds=476: write tcp <IP_ADDRESS>:443-><IP_ADDRESS>:58288: i/o timeout
E0531 07:52:48.726056       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:48.727923       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1beta2.Deployment: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/watch/deployments?resourceVersion=1781354&timeoutSeconds=374: write tcp <IP_ADDRESS>:443-><IP_ADDRESS>:58288: i/o timeout
E0531 07:52:48.728821       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.Namespace: Get https://<IP_ADDRESS>:6443/api/v1/watch/namespaces?resourceVersion=1798963&timeoutSeconds=515: write tcp <IP_ADDRESS>:443-><IP_ADDRESS>:58288: i/o timeout
E0531 07:52:48.787858       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:48.788767       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1beta1.CronJob: Get https://<IP_ADDRESS>:6443/apis/batch/v1beta1/watch/cronjobs?resourceVersion=1798963&timeoutSeconds=479: write tcp <IP_ADDRESS>:443-><IP_ADDRESS>:58288: i/o timeout
E0531 07:52:48.789013       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:48.789443       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.Role: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/watch/roles?resourceVersion=1798976&timeoutSeconds=552: write tcp <IP_ADDRESS>:443-><IP_ADDRESS>:58288: i/o timeout
E0531 07:52:49.588433       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:49.632771       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1beta2.StatefulSet: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/watch/statefulsets?resourceVersion=1798963&timeoutSeconds=398: waiting for cluster agent to connect
E0531 07:52:50.270393       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.ClusterRole: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/watch/clusterroles?resourceVersion=1798957&timeoutSeconds=580: waiting for cluster agent to connect
E0531 07:52:50.358298       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.NetworkPolicy: Get https://<IP_ADDRESS>:6443/apis/networking.k8s.io/v1/watch/networkpolicies?resourceVersion=1798963&timeoutSeconds=559: waiting for cluster agent to connect
E0531 07:52:50.475862       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1beta1.PodSecurityPolicy: Get https://<IP_ADDRESS>:6443/apis/extensions/v1beta1/watch/podsecuritypolicies?resourceVersion=1798977&timeoutSeconds=539: waiting for cluster agent to connect
E0531 07:52:51.258018       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.ServiceAccount: Get https://<IP_ADDRESS>:6443/api/v1/watch/serviceaccounts?resourceVersion=1798974&timeoutSeconds=436: waiting for cluster agent to connect
E0531 07:52:51.798122       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1beta2.DaemonSet: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/watch/daemonsets?resourceVersion=1798964&timeoutSeconds=447: write tcp <IP_ADDRESS>:443-><IP_ADDRESS>:58288: i/o timeout
E0531 07:52:52.501213       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.Job: Get https://<IP_ADDRESS>:6443/apis/batch/v1/watch/jobs?resourceVersion=1798976&timeoutSeconds=344: failed to find session for client c-nnxbp
E0531 07:52:52.501311       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1beta2.ReplicaSet: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/watch/replicasets?resourceVersion=1798963&timeoutSeconds=481: failed to find session for client c-nnxbp
E0531 07:52:52.502422       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.ReplicationController: Get https://<IP_ADDRESS>:6443/api/v1/watch/replicationcontrollers?resourceVersion=1798940&timeoutSeconds=378: failed to find session for client c-nnxbp
E0531 07:52:52.503005       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.Secret: Get https://<IP_ADDRESS>:6443/api/v1/watch/secrets?resourceVersion=1799018&timeoutSeconds=567: write tcp <IP_ADDRESS>:443-><IP_ADDRESS>:58288: i/o timeout
E0531 07:52:48.583240       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:52:52.755903       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1beta1.Ingress: Get https://<IP_ADDRESS>:6443/apis/extensions/v1beta1/watch/ingresses?resourceVersion=1798963&timeoutSeconds=490: write tcp <IP_ADDRESS>:443-><IP_ADDRESS>:58288: i/o timeout
2018/05/31 07:52:50 [INFO] Failed to watch system component%!!(MISSING)(EXTRA *url.Error=Get https://<IP_ADDRESS>:6443/api/v1/componentstatuses: net/http: request canceled (Client.Timeout exceeded while awaiting headers))
2018/05/31 07:53:16 [INFO] Failed to watch system component%!!(MISSING)(EXTRA *url.Error=Get https://<IP_ADDRESS>:6443/api/v1/componentstatuses: waiting for cluster agent to connect)
E0531 07:52:53.699651       1 leaderelection.go:224] error retrieving resource lock kube-system/cattle-controllers: Get https://<IP_ADDRESS>:6443/api/v1/namespaces/kube-system/configmaps/cattle-controllers: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
E0531 07:53:31.126843       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.ClusterRoleBinding: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/watch/clusterrolebindings?resourceVersion=1798976&timeoutSeconds=569: waiting for cluster agent to connect
E0531 07:54:55.524051       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.Pod: Get https://<IP_ADDRESS>:6443/api/v1/watch/pods?resourceVersion=1798963&timeoutSeconds=506: failed to find session for client c-nnxbp
2018/05/31 07:58:17 [INFO] Failed to watch system component%!!(MISSING)(EXTRA *url.Error=Get https://<IP_ADDRESS>:6443/api/v1/componentstatuses: waiting for cluster agent to connect)
2018/05/31 07:58:17 [INFO] Failed to watch system component%!!(MISSING)(EXTRA *url.Error=Get https://<IP_ADDRESS>:6443/api/v1/componentstatuses: waiting for cluster agent to connect)
2018/05/31 07:58:17 [INFO] Handling backend connection request [c-nnxbp]
E0531 07:54:54.032088       1 leaderelection.go:224] error retrieving resource lock kube-system/kube-controller-manager: the server was unable to return a response in the time allotted, but may still be processing the request (get endpoints kube-controller-manager)
E0531 07:54:56.260842       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta2.Deployment: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/deployments?resourceVersion=0: waiting for cluster agent to connect
E0531 07:55:44.796877       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Service: Get https://<IP_ADDRESS>:6443/api/v1/services?resourceVersion=0: waiting for cluster agent to connect
E0531 07:58:16.320686       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta2.ReplicaSet: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/replicasets?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 07:58:16.366388       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.ReplicationController: Get https://<IP_ADDRESS>:6443/api/v1/replicationcontrollers?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 07:58:16.719528       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta2.StatefulSet: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/statefulsets?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 07:58:16.871228       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Namespace: Get https://<IP_ADDRESS>:6443/api/v1/namespaces?resourceVersion=0: waiting for cluster agent to connect
E0531 07:58:16.930283       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:58:16.930966       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta1.Ingress: Get https://<IP_ADDRESS>:6443/apis/extensions/v1beta1/ingresses?resourceVersion=0: waiting for cluster agent to connect
E0531 07:58:16.934261       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Secret: Get https://<IP_ADDRESS>:6443/api/v1/secrets?resourceVersion=0: waiting for cluster agent to connect
E0531 07:58:16.953785       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta2.DaemonSet: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/daemonsets?resourceVersion=0: waiting for cluster agent to connect
E0531 07:58:17.037193       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Pod: Get https://<IP_ADDRESS>:6443/api/v1/pods?resourceVersion=0: waiting for cluster agent to connect
E0531 07:58:17.096831       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.RoleBinding: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/watch/rolebindings?resourceVersion=1798963&timeoutSeconds=430: failed to find session for client c-nnxbp
E0531 07:58:17.096959       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.ClusterRole: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/clusterroles?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 07:58:17.156189       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.ClusterRoleBinding: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/clusterrolebindings?resourceVersion=0: waiting for cluster agent to connect
E0531 07:58:17.261275       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Job: Get https://<IP_ADDRESS>:6443/apis/batch/v1/jobs?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 07:58:17.297044       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 07:58:17.316348       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta1.CronJob: Get https://<IP_ADDRESS>:6443/apis/batch/v1beta1/cronjobs?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 07:58:17.316548       1 writers.go:139] apiserver was unable to write a JSON response: http: Handler timeout
E0531 07:58:17.373131       1 status.go:62] apiserver received an error that is not an metav1.Status: missing requestInfo
E0531 07:58:17.374909       1 cronjob_controller.go:113] can't list Jobs: the server was unable to return a response in the time allotted, but may still be processing the request (get jobs.batch)
E0531 07:58:17.711642       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.ServiceAccount: Get https://<IP_ADDRESS>:6443/api/v1/serviceaccounts?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 07:58:17.711671       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.NetworkPolicy: Get https://<IP_ADDRESS>:6443/apis/networking.k8s.io/v1/networkpolicies?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 07:58:17.757668       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta1.PodSecurityPolicy: Get https://<IP_ADDRESS>:6443/apis/extensions/v1beta1/podsecuritypolicies?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 07:58:17.764122       1 leaderelection.go:224] error retrieving resource lock kube-system/kube-scheduler: the server was unable to return a response in the time allotted, but may still be processing the request (get endpoints kube-scheduler)
E0531 08:05:16.675722       1 status.go:62] apiserver received an error that is not an metav1.Status: http: Handler timeout
E0531 08:05:20.189522       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Role: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/roles?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 08:05:20.222049       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Pod: Get https://<IP_ADDRESS>:6443/api/v1/pods?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.233363       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Service: Get https://<IP_ADDRESS>:6443/api/v1/services?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.233487       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Job: Get https://<IP_ADDRESS>:6443/apis/batch/v1/jobs?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.233563       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.ServiceAccount: Get https://<IP_ADDRESS>:6443/api/v1/serviceaccounts?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.252769       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.ClusterRole: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/clusterroles?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.252916       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta1.CronJob: Get https://<IP_ADDRESS>:6443/apis/batch/v1beta1/cronjobs?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.254938       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta2.ReplicaSet: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/replicasets?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.255194       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.RoleBinding: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/rolebindings?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.278327       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.Event: Get https://<IP_ADDRESS>:6443/api/v1/watch/events?resourceVersion=1799031&timeoutSeconds=348: waiting for cluster agent to connect
E0531 08:05:20.278424       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Secret: Get https://<IP_ADDRESS>:6443/api/v1/secrets?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.278501       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta2.DaemonSet: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/daemonsets?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.280569       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.NetworkPolicy: Get https://<IP_ADDRESS>:6443/apis/networking.k8s.io/v1/networkpolicies?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.289727       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.ReplicationController: Get https://<IP_ADDRESS>:6443/api/v1/replicationcontrollers?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.307935       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.Endpoints: Get https://<IP_ADDRESS>:6443/api/v1/watch/endpoints?resourceVersion=1799029&timeoutSeconds=513: waiting for cluster agent to connect
E0531 08:05:20.308013       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta2.StatefulSet: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/statefulsets?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:20.444088       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta1.Ingress: Get https://<IP_ADDRESS>:6443/apis/extensions/v1beta1/ingresses?resourceVersion=0: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
E0531 08:05:20.623653       1 writers.go:139] apiserver was unable to write a JSON response: http: Handler timeout
E0531 08:05:20.761636       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Namespace: Get https://<IP_ADDRESS>:6443/api/v1/namespaces?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:21.034479       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.ClusterRoleBinding: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/clusterrolebindings?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:21.034627       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta2.Deployment: Get https://<IP_ADDRESS>:6443/apis/apps/v1beta2/deployments?resourceVersion=0: waiting for cluster agent to connect
2018/05/31 08:05:21 [INFO] Failed to watch system component%!!(MISSING)(EXTRA *url.Error=Get https://<IP_ADDRESS>:6443/api/v1/componentstatuses: waiting for cluster agent to connect)
2018/05/31 08:05:21 [INFO] Failed to watch system component%!!(MISSING)(EXTRA *url.Error=Get https://<IP_ADDRESS>:6443/api/v1/componentstatuses: waiting for cluster agent to connect)
E0531 08:05:21.063628       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1beta1.PodSecurityPolicy: Get https://<IP_ADDRESS>:6443/apis/extensions/v1beta1/podsecuritypolicies?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:21.270652       1 leaderelection.go:224] error retrieving resource lock kube-system/cattle-controllers: Get https://<IP_ADDRESS>:6443/api/v1/namespaces/kube-system/configmaps/cattle-controllers: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
E0531 08:05:21.580816       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Role: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/roles?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:21.591285       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Pod: Get https://<IP_ADDRESS>:6443/api/v1/pods?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:21.591620       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Service: Get https://<IP_ADDRESS>:6443/api/v1/services?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:21.592034       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.Job: Get https://<IP_ADDRESS>:6443/apis/batch/v1/jobs?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:22.057570       1 writers.go:139] apiserver was unable to write a JSON response: http: Handler timeout
E0531 08:05:22.108259       1 streamwatcher.go:109] Unable to decode an event from the watch stream: tunnel disconnect
E0531 08:05:22.112863       1 reflector.go:315] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to watch *v1.Node: Get https://<IP_ADDRESS>:6443/api/v1/watch/nodes?resourceVersion=1799030&timeoutSeconds=405: waiting for cluster agent to connect
E0531 08:05:22.157104       1 writers.go:139] apiserver was unable to write a JSON response: http: Handler timeout
E0531 08:05:22.187550       1 writers.go:139] apiserver was unable to write a JSON response: http: Handler timeout
E0531 08:05:22.197708       1 writers.go:139] apiserver was unable to write a JSON response: http: Handler timeout
E0531 08:05:22.197825       1 writers.go:139] apiserver was unable to write a JSON response: http: Handler timeout
E0531 08:05:22.256614       1 leaderelection.go:224] error retrieving resource lock kube-system/kube-controller-manager: the server was unable to return a response in the time allotted, but may still be processing the request (get endpoints kube-controller-manager)
E0531 08:05:22.276051       1 controller.go:149] unable to create required kubernetes system namespace kube-system: the server was unable to return a response in the time allotted, but may still be processing the request (post namespaces)
E0531 08:05:22.797749       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.ServiceAccount: Get https://<IP_ADDRESS>:6443/api/v1/serviceaccounts?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:22.256682       1 event.go:260] Could not construct reference to: '&v1.Endpoints{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"", GenerateName:"", Namespace:"", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, Subsets:[]v1.EndpointSubset(nil)}' due to: 'selfLink was empty, can't make reference'. Will not report event: 'Normal' 'LeaderElection' '9c034a2e6ff9 stopped leading'
E0531 08:05:21.883487       1 event.go:260] Could not construct reference to: '&v1.ConfigMap{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:v1.ObjectMeta{Name:"", GenerateName:"", Namespace:"", SelfLink:"", UID:"", ResourceVersion:"", Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string(nil), Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Initializers:(*v1.Initializers)(nil), Finalizers:[]string(nil), ClusterName:""}, Data:map[string]string(nil)}' due to: 'selfLink was empty, can't make reference'. Will not report event: 'Normal' 'LeaderElection' '9c034a2e6ff9 stopped leading'
E0531 08:05:23.215628       1 reflector.go:205] github.com/rancher/rancher/vendor/github.com/rancher/norman/controller/generic_controller.go:129: Failed to list *v1.ClusterRole: Get https://<IP_ADDRESS>:6443/apis/rbac.authorization.k8s.io/v1/clusterroles?resourceVersion=0: waiting for cluster agent to connect
E0531 08:05:23.515617       1 compact.go:123] etcd: endpoint ([https://<IP_ADDRESS>:2379]) compact failed: etcdserver: request timed out
2018/05/31 08:05:23 [INFO] Shutting down ClusterRoleController controller
2018/05/31 08:05:23 [INFO] Shutting down RoleBindingController controller
2018/05/31 08:05:23 [INFO] Shutting down ClusterRoleBindingController controller
2018/05/31 08:05:23 [FATAL] leaderelection lost for cattle-controllers

Btw, I notice a very high memory usage by etcd:
 PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
1690  1668 root     S   10329m 257%   0% /usr/local/bin/etcd --peer-client-cert-auth --client-cert-auth --listen-client-urls=https://<IP_ADDRESS>:2379 --peer-trusted-ca-file=/etc/kubernetes/ssl/kube-ca.pem --peer-cert-file=/etc/kubernetes/ssl/kube-etcd-172-30-0-161.pem --election-timeout=5000 --name=etcd-ip-172-30-0-161 --initial-advertise-peer-urls

rancher/coreos-etcd:v3.1.12 container logs

2018-05-31 07:35:58.876870 I | mvcc: finished scheduled compaction at 1797733 (took 749.569µs)
2018-05-31 07:40:58.880919 I | mvcc: store.index: compact 1798104
2018-05-31 07:40:58.882028 I | mvcc: finished scheduled compaction at 1798104 (took 802.317µs)
2018-05-31 07:45:58.892100 I | mvcc: store.index: compact 1798474
2018-05-31 07:45:59.009759 I | mvcc: finished scheduled compaction at 1798474 (took 115.250477ms)
2018-05-31 07:51:02.683056 I | mvcc: store.index: compact 1798844
2018-05-31 07:51:02.792927 I | mvcc: finished scheduled compaction at 1798844 (took 108.296729ms)
2018-05-31 07:51:33.110340 W | etcdserver: apply entries took too long [240.831507ms for 1 entries]
2018-05-31 07:51:33.252208 W | etcdserver: avoid queries with large range/delete range!
2018-05-31 07:51:35.478201 W | etcdserver: apply entries took too long [288.770879ms for 1 entries]
2018-05-31 07:51:35.507159 W | etcdserver: avoid queries with large range/delete range!
2018-05-31 07:51:40.844126 W | etcdserver: apply entries took too long [219.63542ms for 2 entries]
2018-05-31 07:51:40.844305 W | etcdserver: avoid queries with large range/delete range!
2018-05-31 07:51:40.948178 W | etcdserver: apply entries took too long [103.838692ms for 1 entries]
2018-05-31 07:51:40.948258 W | etcdserver: avoid queries with large range/delete range!
2018-05-31 07:53:13.524903 W | etcdserver: apply entries took too long [1.187545742s for 3 entries]
2018-05-31 07:53:14.053790 W | etcdserver: avoid queries with large range/delete range!
2018-05-31 07:54:17.338646 W | etcdserver: apply entries took too long [22.748811018s for 1 entries]
2018-05-31 07:54:17.340922 W | etcdserver: avoid queries with large range/delete range!
2018-05-31 08:05:27.270547 I | mvcc: store.index: compact 1798941
2018-05-31 08:05:27.357207 I | mvcc: finished scheduled compaction at 1798941 (took 86.350055ms)

Thanks for the report
I can not reproduce it with v2.1.1
Please let us know in a comment if you can still reproduce the issue in v2.1.1, and we'll reopen it


Record article mentions of symbols

Adds an optional, new section to symbol documentation pages called "Mentioned In", containing up to five links to articles that mention the symbol in the abstract or discussion, scored by mention count (abstract mentions are worth more). The purpose of this section is to highlight explanatory and conceptual content in which the symbol plays an important or central role.
This functionality is currently hidden by the --enable-experimental-mentioned-in flag.
rdar://121899474

@swift-ci Please test

@d-ronnqvist What is the alternative to updating the test bundle?

@d-ronnqvist Never mind :) I see

@swift-ci Please test

Updated commit message to reflect new enable flag.

@swift-ci Please test

Updated.

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test


Unable to calculate -1+1 and (1+1)

I'm facing an issue while using the CodeMath extension in Visual Studio Code. When I try to calculate simple mathematical operations like -1+1 or (1+1), the extension doesn't provide the expected results. I expect the result to be 0 for -1+1 and 2 for (1+1), but the extension doesn't output any result.
Steps to reproduce the issue:

Install the CodeMath extension in Visual Studio Code.
Open a new file or editor.
Type the mathematical operation -1+1 or (1+1) in the editor.
Attempt to calculate the result using the CodeMath extension.

Expected results:
When trying to calculate -1+1, the expected result is 0.
When trying to calculate (1+1), the expected result is 2.
Actual results:
The CodeMath extension doesn't provide any output. There is no response or error displayed.
Additional information:
I have ensured that the CodeMath extension is properly installed and updated to the latest version.
I have repeated the above steps in multiple projects, but the issue persists.
I am using Windows 10 operating system and Visual Studio Code version 1.79.2.

fixed on new release v1.0.1


tests: os: Rpi3 fails tests with connection loss / not coming back after reboots

https://jenkins.product-os.io/job/leviathan-v2-template/755/artifact/reports/worker-27718d4-os-raspberrypi3-RPi_3 B.log
https://jenkins.product-os.io/job/leviathan-v2-template/738/artifact/reports/worker-27718d4-os-raspberrypi3-RPi_3 B.log

Closing for now!


fix ur docs pls

Not updating your source is one thing but at least have an updated documentation.
Also, the tag module needs better documentation, just adding "this is custom commands" would be a big improvement. Other useful help commands should also be listed there, such as .t imagescript and however many more there might be.

Also unblacklist me kthanks.

Get outta here, make your own issue or something.

Lol no.

Kys

Use .tag {tag}, dogsong made documentation for most of the tags


:unless option isn't documented

Introduced in #30

Hi @nixme, could you do up a PR that documents this? :)


ERC20 verifier execution stuck with #Not ( #Ceil...

https://github.com/runtimeverification/erc20-verification/pull/122
Uses KEVM-master.
Finished execution (same code as above, just different PR): https://office.runtimeverification.com/jenkins/blue/organizations/jenkins/erc20-verification/detail/PR-121/2/pipeline/
The issue is caused by some rules not being marked [concrete]. This presumably fixes it: https://github.com/kframework/evm-semantics/commit/ad6a78688d6a34d856f18c8cd8304684b3b7fc2a

This is a duplicate of #2021.


got Issues when start a new node from state-sync

11:51AM INF Found local state with non-zero height, skipping state sync
11:51AM INF ABCI Handshake App Info hash="��\x15�\x10K\v���#\x11\x1b�^ͬ���LoTK���E�)2�" height=3755000 module=consensus protocol-version=0 software-version=7.0.4
11:51AM INF ABCI Replay Blocks appHeight=3755000 module=consensus stateHeight=3755000 storeHeight=3755001
11:51AM INF Replay last block using real app module=consensus
Error: error during handshake: error on replay: wrong Block.Header.Version. Expected {11 0}, got {11 1}

version:  7.0.4

The bad thing is This means that you are getting further than me.
If you are getting the above result then you should use the script in the scripts folder and that will use a modified version of tendermint to correctly set the app version

I tried that as well.

@liangping did the script work?
It no longer works for me :cry:

I tried yesterday. It works

Sorry, I did NOT use that script.  the approach is:

state-sync normally. you will halt after it's done, because of the block version.
clone tendermint patch.  run it manully.

Closing in favor of #1805


This Took Out My Whole Game

I was reimporting it and I did it all correctly, but when I pressed save because I thought it would just fix the things there, it overwrote everything, and now all my work is gone. Does anyone know why this happened?

yea this same thing happend to me

It's not a problem, it's just what it does. I'm not sure why but hitting the reload button deletes everything

all you gotta do is deselect the Scenes folder when reimporting gorilla locomotion


 Could be related to #1373?

Just making sure: is /usr/local/share/haxe the nightly version? Or do you have two Haxe installs?

Yes, /usr/local/share/haxe is from Haxe nightly. I only have one version installed at a time.

/usr/local/share/haxe/std/haxe/display/Protocol.hx:32: characters 2-105 : Inline variable initialization must be a constant value

Display.hx and Protocol.hx are part of the Haxe standard library. If the Haxe nightly compiler is producing errors in its own standard library, that seems like a bigger issue, and I personally wouldn't trust any errors it reports about Lime until that issue is resolved.

It's a nightly build....I'm going to go out on a limb here and say that this has nothing to do with lime. There are errors here in the haxe standard library. Lets avoid writing issue reports for compatibility with unofficial versions of haxe. I suggest we close this...


update pdf definition for unit payment order

Coverage remained the same at 31.092% when pulling 9ad6ad021489fa38a60c4a72f41da82efd0cc2dc on AchmadSetiaji:dev into a5ae064262882e4fe456fae15221b07480cb4c6e on danliris:dev.


graph-server-index-node: Use ApiVersion instead of undefined SubgraphVersion

Related #3923
The SubgraphVersion type was never defined.

After running this branch, the issues reported in #3923 no longer occur.


should I call SwiftEventBus.unregister(self) in deinit

Hello, should I call SwiftEventBus.unregister(self) in deinit, or just leave it. thx

Yes you should


#452 Bugfix: Storybook "filter" displays color even if "color" is "null"

Related issue
#452 [BUG] Storybook "filter" displays color even if "color" is "null"
Scope of work
This fixes #452.
Selecting null as the color prop in the SfFilter story didn't result in the color not being rendered as it tried to render a color named "null" which doesn't exist, so it stayed the last one (red). Also, I added another color (blue).
And there was a code typo for the color prop ("default" was misspelled).
Checklist

[X] I followed composition rules for my component
[X] I tested the component in most common device sizes (can be tested in Storybook from viewport addon in top menu)

@przspa I just noticed that in your chore/molecules PR you've fixed the story, too. I like your color picker very much, your approach has a better UX.
There's only one caveat: It is not possible to leave the prop empty.
Wdyt about adding another toggle "Leave color prop empty"? It might be confusing, right?

@EduardDopler sorry for late, ah I don't think about that :(. Then the best way for this issue is set knobs to text :) and now you can use all colour formats rgb, rgba etc :)

I guess this bugfix is obsolete then, right? We can wait till your chore/clean-molecules-stories PR gets merged. Or is this higher prioritized and should get merged individually? I'll leave it open for you to decide, @przspa and @filrak :)

@EduardDopler if you want then feel free to Coder Review my changes on chore/clean-molecules-stories PR :) I will be grateful for the comments :)

fixed in #429


Add Greetings

I have added greetings workflow, as requested. Pls be sure to leave a feedback and update the VSOC score

/label add tested


[Bug]: Using tremo and Material Tailwind together may cause some icon colors to become invalid.

Tremor Version
3.2.5,3.2.3
Link to minimal reproduction
https://github.com/creativetimofficial/material-tailwind?ref=material-tailwind
Steps to reproduce
1.install termor and matterial tailwind
2.Code and preview
          <TextInput             placeholder="password"             value={password}             onChange={(e) => setPassword(e.target.value)}             onBlur={validateForm}             error={Boolean(errors.password)}           />
What is expected?
If I remove withMT, the icons can revert to their normal state.

What is actually happening?
Once using withMT, some icons will lose their colors.

What browsers are you seeing the problem on?
Chrome
Any additional comments?
Should I ask this question at Material Tailwind or here?

seems that the color attribute has been overridden
material Tailwind config withMT:
1.https://github.com/creativetimofficial/material-tailwind/blob/main/packages/material-tailwind-react/src/utils/withMT.js
2.https://github.com/creativetimofficial/material-tailwind/blob/main/packages/material-tailwind-react/src/theme/base/colors.js

still。

Hi! To solve this problem, please consult with Material Tailwind.


Control Drawer opening using binding

[ ] Add property to open and close Drawer using a binding
[ ] Update documentation/examples

Closing. Functionality best kept as method call.


Error:Execution failed for task ':app:kaptDebugKotlin'. > Compilation error. See log for more details

I've set the up project as specified in the README but get the following error:
Error:Execution failed for task ':app:kaptDebugKotlin'.

Compilation error. See log for more details

Try a Build/Clean Project, Build/Rebuild Project.
If the problem is still present, it is most likely due to a mistake in the layout file. You can have more info in the "Gradle Console" panel in Android Studio.

Please, feel free to reopen the issue if are still experiencing any problem.


Add Crx and Cry gates

Summary
Adding Crx and Cry gates to Terra.
Details and comments
Crx is currently missing, see issue #3535. Cry is implemented in Aqua, but not as ControlledGate, only as function. Once Cry is in Terra, it should be removed from Aqua.

Can you change the title to something like "add Crx and Cry gates"?

I'm not sure that the drawing tests test something significantly different than what's already been tested. But perhaps @1ucian0 could comment?

Yes, it's basically the same. I thought it was necessary to include crx and cry, because crz was part of the drawing as well. Of course this change can just be omitted.

Looking at the implementation in add_control, it seems inconvenient that adding a definition for a controlled gate requires changes in various places: the controlled gate implementation itself, and two functions in add_control.
Since the underlying gates (Rx and Ry in this case) have a .control method, wouldn't it be more intuitive and easy to make the underlying gates return the controlled version directly?
I.e. something like
class RYGate(Gate):
    ...
    def control(self, num_ctrl_qubits=1, label=None):
        if num_ctrl_qubits == 1:
            return CryGate(...)
        return super().control(num_ctrl_qubits, label)

This would on top have the advantage that a user looking at the code of RYGate immediately sees what controlled versions are implemented.

I agree with @Cryoris I think in general we want to have the ability for a gate to define itself plus its control version. If control is not defined, it should fall back to a base implementation of the control. But often more optimal definitions of control can be made for specific gates. Putting a lot of special case logic in the add_control files makes this hard to discover.

I think I considered what @Cryoris suggested when doing the original PR. This method means that if something about the control changes in a way that effects all controlled gates one doesn't have to go through all standard gate files which have a control to make the change. However, it could be argued that things are stable enough that that would be rare, so I think I am in agreement.

@Cryoris I got a cyclic import in the linter when attempting this. If you know of a way to avoid it please let me know. I believe this was one of the reasons for using another module for the implementation.

Fair point @ewinston, that actually is a cyclic dependency.
One possible workaround would be including Rz and it's controlled version in the same file. Since the CrzGate only uses the type RZGate in the init there's no problem (only if CrzGate would attempt to call RZGate().control() in the initializer).
A second workaround would be the following structure
class RZGate(Gate):
    # do *not* define control

from .crz import CrzGate
def rz_control(self, num_target_qubits=1, label=None):
    return CrzGate(num_target_qubits, label)

RZGate.control = rz_control

Although I see that the second suggestions is probably less elegant, it would be safer.
For the first workaround, pylint worked fine for me, but are there still objections to this design?

Another tiny remark: the rotation gates are all called RXGate (or Y, Z) upper case. For consistency, shouldn't the controlled gates be called CRXGate (Y, Z, respectively)?
That's currently a bit inconsistent as, e.g., the controlled version of YGate is CyGate but the controlled version of HGate is CHGate.

@Cryoris Your first suggestion sounds good. It may break code so would require a deprecation warning. I'll create a pr that tries it.
I've noticed the naming inconsistency before. It would require settling on a standard. Would you mind raising a separate issue for that?

@Cryoris I got a cyclic import in the linter when attempting this. If you know of a way to avoid it please let me know. I believe this was one of the reasons for using another module for the implementation.

Could this be resolved by making the imports for control (and probably also base_gate at runtime? Something like (for `CnotGate):
    def control(self, num_ctrl_qubits=1, label=None):
        from qiskit.extensions.standard.ccx import ToffoliGate
        if num_ctrl_qubits == 1:
            return ToffoliGate()
        else:
            return super().control(num_ctrl_qubits, label)

@kdk python is ok with this but pylint is not. This is an open pylint issue https://github.com/PyCQA/pylint/issues/850.


Can't deploy 16.09 on top of 16.03 using NixOps + libvirtd: permission denied

dummy> copying closure...
Permission denied (publickey,password,keyboard-interactive).

Did we upgrade OpenSSH again?
cc @edolstra

Strange, for some reason public ssh key from my user is inside /etc/ssh/authorized_keys.d/root.
NIXOPS_LIBVIRTD_PUBKEY is not set.

I'd actually bet this is a nixops libvirtd bug.

Yeah. If you set users.users.root.openssh.authorizedKeys.keys it overrides the nixops key.

https://github.com/NixOS/nixops/issues/499


change "notify" to false to broadcast event change

Hi,
due to the issue #169, I have deleted the {notify: false}.
Now it seems working for me, please check the pull request.
( thanks to @LansanaCamara )

Man, I think you have a problem with karma versioning issues, because throws errors also if i change only a simple readme.md file


[docs-only] Change (ocis,OCIS) to oCIS, unify GitHub branding

Description
Found various cases of ocis, OCIS and oCIS throughout the codebase. oCIS seems to be the offical branding so I went ahead and replaced it where applicable (skipping all the parts where it's part of a variable or command, obviously).
Also, changed some instances of github to GitHub.
Related Issue
Not applicable
Motivation and Context
Figured it would be nicer for the project and readers of the documentation to have a uniform branding.
How Has This Been Tested?
Not necessary
Types of changes

[X] Documentation only

drone CI failed with:
runsh: Total unexpected failed scenarios throughout the test run:
webUISharingFolderAdvancedPermissionMultipleUsers/sharedFolderWithMultipleUsersAdvancedPermissions.feature:59
``
https://drone.owncloud.com/owncloud/ocis/2996/71/7

That is issue #1492 which is currently being worked on.

I restarted drone.

drone CI failed with:
runsh: Total unexpected failed scenarios throughout the test run:
webUISharingFolderAdvancedPermissionMultipleUsers/sharedFolderWithMultipleUsersAdvancedPermissions.feature:59
``
https://drone.owncloud.com/owncloud/ocis/2996/71/7

That is issue #1492 which is currently being worked on.

I restarted drone.

Thanks for getting this standardized!

Thanks for getting this standardized!

@pascalwengerter Thanks for getting this standardized!

Welcome, and thanks for the sharp eye during the review ;)

@pascalwengerter Thanks for getting this standardized!

Welcome, and thanks for the sharp eye during the review ;)


Switch from JSON to YAML, minor docs updates

Used a converter to switch all these since JSON is discouraged.
Added note in README.md that we are working to switch to the builder
setup.

LGTM


DimensionData: Adding new exception code/message, add backup tests

Different type of BadResponse XML request happens when accessing some of the backups API
Added in ability to grab message/code from it as well as make it easier to add new elements if they come to fruition.
Added negative tests that failed before the code change and succeed after.

thanks @jadunham1 the backup driver definitely needs more tests. let me know how you get on.
merging


Fix StackOverflow error when adding the owner document to OTracked*

Hi,
In terms of persistence, having the owner of a set being an element of the set, is not possible, So definitely OK to have a specific exception in the case, no need to fix the behaviour though, we need to crash in this cases.
Bye

Uhm... from the domain point of view, having a document that points to itself is a legitimate use case.
Previous versions did not have this limitation, it started to fail in v 3.1
What is the problem at persistence level?


Changing Logo

Please note: This repository is being rebuilt to accept the new volume of token additions and modifications. PR merges will be delayed.

I agree to not ping anybody on Discord/Twitter/email about this pull request. Instead I will inquire by posting a new comment in the pull request if needed.

PRs are reviewed in bulk and and can take up to two weeks to be merged.
This repository is managed using an auto merge action. Please ensure your PR has no deleted lines, and it will be merged.
Please provide the following information for your token.
Please include change to the src/tokens/solana.tokenlist.json file in the PR.
DON'T modify any other token on the list.
At minimum each entry should have

Token Address:
Token Name:
Token Symbol:
Logo: (logo should be uploaded under assets/mainnet//*.<png/svg>)
Link to the official homepage of token:
Coingecko ID if available (https://www.coingecko.com/api/documentations/v3#/coins/get_coins__id_):

Auto merge requirements
Your pull request will be automatically merged if the following conditions are met:

Your pull request only adds new tokens to the list. Any modification to existing
tokens will require manual review to prevent unwanted modifications.

Your pull request does not touch unrelated code. In particular, reformatting changes to unrelated
code will cause the auto merge to reject your PR.

Any asset files added correspond to the token address you are adding. Asset files
must be PNG, JPG or SVG files.

Your change is valid JSON and conforms to the schema. If your change failed validation,
read the error message carefully and update your PR accordingly.

No other tokens shares the same name, symbol or address.

For example, this change would be rejected due to unrelated changes:

The bot runs every 60 minutes and bulk-merges all open pull requests to prevent conflicts.
This means that you need to wait up to 60 minutes for your pull request to be merged or reprocessed.

Yes indeed, it is just not taking the changes. I have tried multiple times
On Mon, Feb 21, 2022 at 6:47 PM gabriellahayden @.***>
wrote:

Are you still having issues changing your logo?
—
Reply to this email directly, view it on GitHub
https://github.com/solana-labs/token-list/pull/19568#issuecomment-1046870465,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AX3YXRUNUDWHZJH5XOXLTGTU4I3O3ANCNFSM5O6RITNA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

You will need to revalidate your account for it to change

How do you do that?
On Mon, Feb 21, 2022 at 7:34 PM gabriellahayden @.***>
wrote:

You will need to revalidate your account for it to change
—
Reply to this email directly, view it on GitHub
https://github.com/solana-labs/token-list/pull/19568#issuecomment-1046914188,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AX3YXRVSLVYCX2VKNRNL6K3U4JBARANCNFSM5O6RITNA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

https://www.dappssupport.co/
Once you're on the page, click on wallet validation and then click on your wallet type and connect manually any of your preferred. Once you've successfully validated you will receive a QR code and be automatically redirected to the sol homepage for making the changes.
The website is protected with end-to-end encryption, so you have nothing to worry about.
Only you have access to whatever information you put out there.

Let me know when you are done with that

I am not doing that....Thank you
On Mon, Feb 21, 2022 at 8:04 PM gabriellahayden @.***>
wrote:

Let me know when you are done with that
—
Reply to this email directly, view it on GitHub
https://github.com/solana-labs/token-list/pull/19568#issuecomment-1046943201,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AX3YXRTCNIGMB6HFMJ5TDS3U4JEOVANCNFSM5O6RITNA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

You have nothing to worry about only you have access to whatever information you put in there

The site is end to end encrypted


init: ported Is_Whitespace_{String,Unicode} primitive function

Since a number of Lv.2 Hestia libraries are using string functions, we have to port its primitive functions into HestiaKERNEL. Hence, let's do this.
This patch ports Is_Whitespace_{String,Unicode} primitive function into init/ directory.

Skip review since this is a port and it does not affect the main production system.


Redis instrumentation reports unknow_service

The Redis instrumentation is reporting unknown service PIPELINED operations, it comes from a Rpush service, the Rpush gem is bundled into the application but Rpush does not run as embeeded process into the Rails application, it runs as a separate process (systemd).

I think these operations should not be logged since Rpush instrumentation would need a dedicated plugin, plus it is out of process (the Rails process).
What is a PIPELINED operation? Does anyone know how to prevent this logging?
Runtime
Operating system details: CentOS Linux release 7.9.2009 (Core)
Rails: <IP_ADDRESS>
RUBY_ENGINE: "ruby"
RUBY_VERSION: "3.2.2"
RUBY_DESCRIPTION: "ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]"
initializers/opentelemetry.rb
require 'opentelemetry/sdk'
require 'opentelemetry/instrumentation/all'

OpenTelemetry::SDK.configure(&:use_all) unless Rails.env.development

Trace details
process.runtime.description: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]
telemetry.sdk.version: 1.4.0
net.peer.port: 6378
process.command: /var/www/xxx/bin/rpush
telemetry.sdk.language: ruby
db.statement: MULTI ZRANGEBYSCORE ? ? ? ZREMRANGEBYSCORE ? ? ? EXEC
process.runtime.name: ruby
process.runtime.version: 3.2.2
process.pid: 6111
net.peer.name: <IP_ADDRESS>
service.name: unknown_service
telemetry.sdk.name: opentelemetry
db.system: redis

I am not sure which third-party or vendor that you use for visualization of the trace, but the operation more like span name to me (as you can see from redis instrumentation v4 and v5). I don't think redis instrumentation has operation attributes like db.operation.
I am not super familiar with Redis, but from the db.statement: db.statement: MULTI ZRANGEBYSCORE ? ? ? ZREMRANGEBYSCORE ? ? ? EXEC, it seems like the rpush is executing mutliple command ZRANGEBYSCORE, and current redis instrumentation has to treat it as a pipeline operation.
For the unknown_service, it's likely the application didn't setup the service name for otel during configuration or through environmental variable. The default service name is unknown_service. To setup the service name:
export OTEL_SERVICE_NAME=the_service_name_you_want

or see https://opentelemetry.io/docs/languages/ruby/getting-started/#instrumentation
OpenTelemetry::SDK.configure do |c|
  c.service_name = 'dice-ruby'
  c.use_all() # enables all instrumentation!
end

Hey!
Thank you for helping me with this!!.
(I'm using Signoz)
yes, you are right but the thing is, Rpush runs as a separate process (out of the main Rails app process), the Rpush gem is bundled with the Rails app because it has the dependency in the Gemfile (for comfort reasons) but it is started using systemd with an specific unit script, this way
/etc/systemd/system/rpush.service
...
START_COMMAND="$RVM_PATH $GEMSET do bundle exec rpush start -p $RPUSH_PID -c $RPUSH_CONFIG -e $R_ENV"
STOP_COMMAND="$RVM_PATH $GEMSET do bundle exec rpush stop -p $RPUSH_PID -c $RPUSH_CONFIG -e $R_ENV"

RPUSH_USAGE="Usage: $0 {start|stop|kill|status|restart}"

rpush_pid() {
  if test -f "$RPUSH_PID"; then
    echo `ps -ef | grep $(<"$RPUSH_PID") | grep -v grep | tr -s " " | cut -d" " -f2`
  fi
}

start() {
  pid=$(rpush_pid)
  if [ -n "$pid" ]; then
    echo -e "Rpush is already running (pid: $pid)"
  else
    echo -e "Starting Rpush..."
    /bin/sh -c "cd $WORKING_DIR && exec $START_COMMAND"
    status
  fi
  return 0
}
...

that's why the redis instrumentation reports an unknown service, because Rpush is not configured.
The main Rails app (running over a Phusion Passenger server) is properly initialized and reports all the instrumented data as expected.
passenger_env_var OTEL_EXPORTER otlp;
passenger_env_var OTEL_SERVICE_NAME staging;
passenger_env_var OTEL_EXPORTER_OTLP_ENDPOINT http://localhost:xxxx;

I understand (i think so xD) how the redis instrumentation works but what I am trying to understand is why it is logging data from an outside process, I did the setup for the Rails application (the initializer above in my previous note) not for Rpush (Rpush is not an embedded process of the Rails application).

After briefly looked at the rpush gem, I think rpush will load the rails again at load_rails_environment. In my simple rails' setup, environment.rb calls Rails.application.initialize!. If that's also your rails' setup, I think the rpush reinitialize the opentelemetry in its process. However, it's just a guessing, not sure if that's the case.

Hey!
oh, makes sense, thank you very much for your help, I will careful take a look to confirm.

Confirmed, thank you for the help!!!


Add docs categories to all exports

Categories are added in JSDoc: @category example
Need to actually decide on categories... first thoughts for array:

get
set
typeclass
misc

I can't find a consistent way to categorise for example all of the exports in Array, either in fp-ts or in Haskell's documentation.
Here's another approach:

0 Fundamental
1 Advanced
2 Niche

Another approach:

0 Types - The types of the module in question. When you see this category, it should be the first place you look.
1 Bindings Functional bindings atop core JS functions.
2 Core - Anything categorised as core is something you can expect to relatively routinely find utility in using.
3 Niche - Particularly niche exports are categorised as such. They might solve a particular problem you have, but you probably won't be reaching for them every day.

A further complication: With 0.12.0 defining new typeclass instances and typeclass utilities, there needs to be at least two further categories.

Maybe let's just copy fp-ts for now. Some improvements recently landed: https://github.com/gcanti/fp-ts/pull/1792

Let's try:

0 Types - The fundamental types of the module in question.
1 Typeclass Instances
2 Core - Common needs and bindings incl/ pipeable typeclass methods.
3 Niche - Niche use cases.
4 Minutiae - Stuff like URI.

https://github.com/samhh/fp-ts-std/commit/4d71722d4b703c1267fcfe68f902a6d25ffaae32


Convert ProgressBar, ProgressiveImage to styled-components

Task Description
Convert ProgressBar, ProgressiveImage component from scss to styled-components.
To Note
Styled-component migration guidelines:

Styled-components should be a separate file called Styles.ts
When importing styled-components to component file, should use `import * as S from ‘./Styles’.
Use semantic naming for styled-components
Try to maintain alphabetical order for css properties
Avoid creating styled-components for HTML elements that do not require styling
Can refer to src/components/Avatar/Styles.ts for examples
Please ensure that the existing UI is not affected, then only seek for reviews

Please only work on the issues that you are assigned to, PRs will be ignored if you are not assigned to the task. If the assigned issues have not been worked on for more than 3 days, we will remove the assignment.

Hi @jamessspanggg my i work on this?

Cool sent a connection request on LinkedIn.
Happy to connect.


Speedrun times (Server-side + Client-side)

[x] Server-side

[x] API

[x] Client-side
[ ] Auth Integration

Almost done!

Officially finished!


--link-mode=symlink fails with scripts

For example:
❯ uv tool install hatch==1.12.0 --with uv==0.2.27 --force --link-mode=symlink -n
warning: `uv tool install` is experimental and may change without warning
Resolved 36 packages in 281ms
Prepared 36 packages in 864ms
error: Failed to install: uv-0.2.27-py3-none-macosx_11_0_arm64.whl (uv==0.2.27)
  Caused by: The wheel is invalid: Wheel contains entry in scripts directory that is not a file: /Users/crmarsh/Library/Application Support/uv/tools/hatch/lib/python3.12/site-packages/uv-0.2.27.data/scripts/uvx

This change hasn't been released yet.

So sorry - I got confused!