text:
etcd timeout

My Kubernetes master and etcd is running on the same VM is running into some intermittent issue with "etcd timing out" and "apiserver received an error that is not an metav1.Status: etcdserver: request timed out"
Feb 09 15:09:41 master-a4995c9c-0da9-11e8-94fe-02fa846d2442 kube-apiserver[1267]: logging error output: "k8s\x00\n\f\n\x02v1\x12\x06Status\x125\n\x06\n\x00\x12\x00\x1a\x00\x12\aFailure\x1a\x1detcdserver: request timed out\"\x000\xf4\x03\x1a\x00\"\x00"
Feb 09 15:09:41 master-a4995c9c-0da9-11e8-94fe-02fa846d2442 kube-apiserver[1267]: I0209 15:09:36.085202    1267 trace.go:76] Trace[376525130]: "GuaranteedUpdate etcd3: *api.Node" (started: 2018-02-09 15:09:29.07814287 +0000 UTC m=+423.501354923) (total time: 7.007027719s):
Feb 09 15:09:41 master-a4995c9c-0da9-11e8-94fe-02fa846d2442 kube-apiserver[1267]: E0209 15:09:36.085234    1267 status.go:62] apiserver received an error that is not an metav1.Status: etcdserver: request timed out
Feb 09 15:09:41 master-a4995c9c-0da9-11e8-94fe-02fa846d2442 kube-apiserver[1267]: logging error output: "k8s\x00\n\f\n\x02v1\x12\x06Status\x125\n\x06\n\x00\x12\x00\x1a\x00\x12\aFailure\x1a\x1detcdserver: request timed out\"\x000\xf4\x03\x1a\x00\"\x00"
Feb 09 15:09:44 master-a4995c9c-0da9-11e8-94fe-02fa846d2442 etcd[1185]: timed out waiting for read index response
Feb 09 15:09:51 master-a4995c9c-0da9-11e8-94fe-02fa846d2442 etcd[1185]: timed out waiting for read index response
Feb 09 15:09:53 master-a4995c9c-0da9-11e8-94fe-02fa846d2442 etcd[1185]: sync duration of 23.383339906s, expected less than 1s
Feb 09 15:10:06 master-a4995c9c-0da9-11e8-94fe-02fa846d2442 etcd[1185]: apply entries took too long [36.026037646s for 7 entries]
Feb 09 15:10:06 master-a4995c9c-0da9-11e8-94fe-02fa846d2442 etcd[1185]: avoid queries with large range/delete range!
Feb 09 15:10:13 master-a4995c9c-0da9-11e8-94fe-02fa846d2442 etcd[1185]: timed out waiting for read index response

Attach is my etcd metrics. Can somebody point to me if there are any obvious problems in this metrics? Like I need to switch etcd to use better disk, etc?
# HELP etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds Bucketed histogram of db compaction pause duration.
# TYPE etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds histogram
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="1"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="2"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="4"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="8"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="16"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="32"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="64"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="128"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="256"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="512"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="1024"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="2048"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="4096"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket{le="+Inf"} 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_sum 0
etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_count 0
# HELP etcd_debugging_mvcc_db_compaction_total_duration_milliseconds Bucketed histogram of db compaction total duration.
# TYPE etcd_debugging_mvcc_db_compaction_total_duration_milliseconds histogram
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="100"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="200"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="400"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="800"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="1600"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="3200"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="6400"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="12800"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="25600"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="51200"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="102400"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="204800"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="409600"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="819200"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_bucket{le="+Inf"} 82
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_sum 0
etcd_debugging_mvcc_db_compaction_total_duration_milliseconds_count 82
# HELP etcd_debugging_mvcc_db_total_size_in_bytes Total size of the underlying database in bytes.
# TYPE etcd_debugging_mvcc_db_total_size_in_bytes gauge
etcd_debugging_mvcc_db_total_size_in_bytes 2.17088e+06
# HELP etcd_debugging_mvcc_delete_total Total number of deletes seen by this member.
# TYPE etcd_debugging_mvcc_delete_total counter
etcd_debugging_mvcc_delete_total 0
# HELP etcd_debugging_mvcc_events_total Total number of events sent by this member.
# TYPE etcd_debugging_mvcc_events_total counter
etcd_debugging_mvcc_events_total 27284
# HELP etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds Bucketed histogram of index compaction pause duration.
# TYPE etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds histogram
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="0.5"} 0
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="1"} 69
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="2"} 75
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="4"} 76
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="8"} 76
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="16"} 76
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="32"} 77
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="64"} 77
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="128"} 77
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="256"} 77
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="512"} 81
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="1024"} 82
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_bucket{le="+Inf"} 82
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_sum 2309
etcd_debugging_mvcc_index_compaction_pause_duration_milliseconds_count 82
# HELP etcd_debugging_mvcc_keys_total Total number of keys.
# TYPE etcd_debugging_mvcc_keys_total gauge
etcd_debugging_mvcc_keys_total 179
# HELP etcd_debugging_mvcc_pending_events_total Total number of pending events to be sent.
# TYPE etcd_debugging_mvcc_pending_events_total gauge
etcd_debugging_mvcc_pending_events_total 0
# HELP etcd_debugging_mvcc_put_total Total number of puts seen by this member.
# TYPE etcd_debugging_mvcc_put_total counter
etcd_debugging_mvcc_put_total 0
# HELP etcd_debugging_mvcc_range_total Total number of ranges seen by this member.
# TYPE etcd_debugging_mvcc_range_total counter
etcd_debugging_mvcc_range_total 104375
# HELP etcd_debugging_mvcc_slow_watcher_total Total number of unsynced slow watchers.
# TYPE etcd_debugging_mvcc_slow_watcher_total gauge
etcd_debugging_mvcc_slow_watcher_total 0
# HELP etcd_debugging_mvcc_txn_total Total number of txns seen by this member.
# TYPE etcd_debugging_mvcc_txn_total counter
etcd_debugging_mvcc_txn_total 27952
# HELP etcd_debugging_mvcc_watch_stream_total Total number of watch streams.
# TYPE etcd_debugging_mvcc_watch_stream_total gauge
etcd_debugging_mvcc_watch_stream_total 60
# HELP etcd_debugging_mvcc_watcher_total Total number of watchers.
# TYPE etcd_debugging_mvcc_watcher_total gauge
etcd_debugging_mvcc_watcher_total 60
# HELP etcd_debugging_snap_save_marshalling_duration_seconds The marshalling cost distributions of save called by snapshot.
# TYPE etcd_debugging_snap_save_marshalling_duration_seconds histogram
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="0.001"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="0.002"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="0.004"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="0.008"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="0.016"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="0.032"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="0.064"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="0.128"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="0.256"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="0.512"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="1.024"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="2.048"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="4.096"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="8.192"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_bucket{le="+Inf"} 10
etcd_debugging_snap_save_marshalling_duration_seconds_sum 0.0003179209999999999
etcd_debugging_snap_save_marshalling_duration_seconds_count 10
# HELP etcd_debugging_snap_save_total_duration_seconds The total latency distributions of save called by snapshot.
# TYPE etcd_debugging_snap_save_total_duration_seconds histogram
etcd_debugging_snap_save_total_duration_seconds_bucket{le="0.001"} 0
etcd_debugging_snap_save_total_duration_seconds_bucket{le="0.002"} 0
etcd_debugging_snap_save_total_duration_seconds_bucket{le="0.004"} 8
etcd_debugging_snap_save_total_duration_seconds_bucket{le="0.008"} 8
etcd_debugging_snap_save_total_duration_seconds_bucket{le="0.016"} 8
etcd_debugging_snap_save_total_duration_seconds_bucket{le="0.032"} 9
etcd_debugging_snap_save_total_duration_seconds_bucket{le="0.064"} 9
etcd_debugging_snap_save_total_duration_seconds_bucket{le="0.128"} 10
etcd_debugging_snap_save_total_duration_seconds_bucket{le="0.256"} 10
etcd_debugging_snap_save_total_duration_seconds_bucket{le="0.512"} 10
etcd_debugging_snap_save_total_duration_seconds_bucket{le="1.024"} 10
etcd_debugging_snap_save_total_duration_seconds_bucket{le="2.048"} 10
etcd_debugging_snap_save_total_duration_seconds_bucket{le="4.096"} 10
etcd_debugging_snap_save_total_duration_seconds_bucket{le="8.192"} 10
etcd_debugging_snap_save_total_duration_seconds_bucket{le="+Inf"} 10
etcd_debugging_snap_save_total_duration_seconds_sum 0.12088795499999999
etcd_debugging_snap_save_total_duration_seconds_count 10
# HELP etcd_debugging_store_expires_total Total number of expired keys.
# TYPE etcd_debugging_store_expires_total counter
etcd_debugging_store_expires_total 0
# HELP etcd_debugging_store_reads_total Total number of reads action by (get/getRecursive), local to this member.
# TYPE etcd_debugging_store_reads_total counter
etcd_debugging_store_reads_total{action="get"} 128
etcd_debugging_store_reads_total{action="getRecursive"} 42
# HELP etcd_debugging_store_watch_requests_total Total number of incoming watch requests (new or reestablished).
# TYPE etcd_debugging_store_watch_requests_total counter
etcd_debugging_store_watch_requests_total 2
# HELP etcd_debugging_store_watchers Count of currently active watchers.
# TYPE etcd_debugging_store_watchers gauge
etcd_debugging_store_watchers 2
# HELP etcd_debugging_store_writes_total Total number of writes (e.g. set/compareAndDelete) seen by this member.
# TYPE etcd_debugging_store_writes_total counter
etcd_debugging_store_writes_total{action="create"} 8
etcd_debugging_store_writes_total{action="delete"} 8
etcd_debugging_store_writes_total{action="set"} 25
# HELP etcd_disk_backend_commit_duration_seconds The latency distributions of commit called by backend.
# TYPE etcd_disk_backend_commit_duration_seconds histogram
etcd_disk_backend_commit_duration_seconds_bucket{le="0.001"} 0
etcd_disk_backend_commit_duration_seconds_bucket{le="0.002"} 23166
etcd_disk_backend_commit_duration_seconds_bucket{le="0.004"} 23601
etcd_disk_backend_commit_duration_seconds_bucket{le="0.008"} 23675
etcd_disk_backend_commit_duration_seconds_bucket{le="0.016"} 23707
etcd_disk_backend_commit_duration_seconds_bucket{le="0.032"} 23751
etcd_disk_backend_commit_duration_seconds_bucket{le="0.064"} 23832
etcd_disk_backend_commit_duration_seconds_bucket{le="0.128"} 23934
etcd_disk_backend_commit_duration_seconds_bucket{le="0.256"} 24247
etcd_disk_backend_commit_duration_seconds_bucket{le="0.512"} 25122
etcd_disk_backend_commit_duration_seconds_bucket{le="1.024"} 25844
etcd_disk_backend_commit_duration_seconds_bucket{le="2.048"} 25933
etcd_disk_backend_commit_duration_seconds_bucket{le="4.096"} 25944
etcd_disk_backend_commit_duration_seconds_bucket{le="8.192"} 25950
etcd_disk_backend_commit_duration_seconds_bucket{le="+Inf"} 25966
etcd_disk_backend_commit_duration_seconds_sum 1444.4355971160062
etcd_disk_backend_commit_duration_seconds_count 25966
# HELP etcd_disk_wal_fsync_duration_seconds The latency distributions of fsync called by wal.
# TYPE etcd_disk_wal_fsync_duration_seconds histogram
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.001"} 81426
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.002"} 85807
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.004"} 91673
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.008"} 92134
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.016"} 93055
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.032"} 98054
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.064"} 98651
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.128"} 99059
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.256"} 99718
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.512"} 100661
etcd_disk_wal_fsync_duration_seconds_bucket{le="1.024"} 101216
etcd_disk_wal_fsync_duration_seconds_bucket{le="2.048"} 101353
etcd_disk_wal_fsync_duration_seconds_bucket{le="4.096"} 101371
etcd_disk_wal_fsync_duration_seconds_bucket{le="8.192"} 101376
etcd_disk_wal_fsync_duration_seconds_bucket{le="+Inf"} 101390
etcd_disk_wal_fsync_duration_seconds_sum 1650.672015552
etcd_disk_wal_fsync_duration_seconds_count 101390
# HELP etcd_grpc_proxy_cache_hits_total Total number of cache hits
# TYPE etcd_grpc_proxy_cache_hits_total gauge
etcd_grpc_proxy_cache_hits_total 0
# HELP etcd_grpc_proxy_cache_misses_total Total number of cache misses
# TYPE etcd_grpc_proxy_cache_misses_total gauge
etcd_grpc_proxy_cache_misses_total 0
# HELP etcd_grpc_proxy_events_coalescing_total Total number of events coalescing
# TYPE etcd_grpc_proxy_events_coalescing_total counter
etcd_grpc_proxy_events_coalescing_total 0
# HELP etcd_grpc_proxy_watchers_coalescing_total Total number of current watchers coalescing
# TYPE etcd_grpc_proxy_watchers_coalescing_total gauge
etcd_grpc_proxy_watchers_coalescing_total 0
# HELP etcd_http_failed_total Counter of handle failures of requests (non-watches), by method (GET/PUT etc.) and code (400, 500 etc.).
# TYPE etcd_http_failed_total counter
etcd_http_failed_total{code="404",method="DELETE"} 8
etcd_http_failed_total{code="404",method="QGET"} 27
etcd_http_failed_total{code="412",method="PUT"} 2
etcd_http_failed_total{code="500",method="PUT"} 1
etcd_http_failed_total{code="500",method="QGET"} 1
# HELP etcd_http_received_total Counter of requests received into the system (successfully parsed and authd).
# TYPE etcd_http_received_total counter
etcd_http_received_total{method="DELETE"} 8
etcd_http_received_total{method="PUT"} 30
etcd_http_received_total{method="QGET"} 60
# HELP etcd_http_successful_duration_seconds Bucketed histogram of processing time (s) of successfully handled requests (non-watches), by method (GET/PUT etc.).
# TYPE etcd_http_successful_duration_seconds histogram
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.0005"} 4
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.001"} 4
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.002"} 4
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.004"} 4
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.008"} 4
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.016"} 6
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.032"} 7
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.064"} 10
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.128"} 15
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.256"} 19
etcd_http_successful_duration_seconds_bucket{method="PUT",le="0.512"} 24
etcd_http_successful_duration_seconds_bucket{method="PUT",le="1.024"} 26
etcd_http_successful_duration_seconds_bucket{method="PUT",le="2.048"} 27
etcd_http_successful_duration_seconds_bucket{method="PUT",le="+Inf"} 27
etcd_http_successful_duration_seconds_sum{method="PUT"} 6.325096843000001
etcd_http_successful_duration_seconds_count{method="PUT"} 27
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.0005"} 25
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.001"} 25
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.002"} 25
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.004"} 25
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.008"} 25
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.016"} 25
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.032"} 25
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.064"} 25
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.128"} 26
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.256"} 27
etcd_http_successful_duration_seconds_bucket{method="QGET",le="0.512"} 30
etcd_http_successful_duration_seconds_bucket{method="QGET",le="1.024"} 31
etcd_http_successful_duration_seconds_bucket{method="QGET",le="2.048"} 32
etcd_http_successful_duration_seconds_bucket{method="QGET",le="+Inf"} 32
etcd_http_successful_duration_seconds_sum{method="QGET"} 3.5796803930000007
etcd_http_successful_duration_seconds_count{method="QGET"} 32
# HELP etcd_network_client_grpc_received_bytes_total The total number of bytes received from grpc clients.
# TYPE etcd_network_client_grpc_received_bytes_total counter
etcd_network_client_grpc_received_bytes_total 1.9240446e+07
# HELP etcd_network_client_grpc_sent_bytes_total The total number of bytes sent to grpc clients.
# TYPE etcd_network_client_grpc_sent_bytes_total counter
etcd_network_client_grpc_sent_bytes_total 5.9652246e+07
# HELP etcd_server_has_leader Whether or not a leader exists. 1 is existence, 0 is not.
# TYPE etcd_server_has_leader gauge
etcd_server_has_leader 1
# HELP etcd_server_leader_changes_seen_total The number of leader changes seen.
# TYPE etcd_server_leader_changes_seen_total counter
etcd_server_leader_changes_seen_total 1
# HELP etcd_server_proposals_applied_total The total number of consensus proposals applied.
# TYPE etcd_server_proposals_applied_total gauge
etcd_server_proposals_applied_total 103076
# HELP etcd_server_proposals_committed_total The total number of consensus proposals committed.
# TYPE etcd_server_proposals_committed_total gauge
etcd_server_proposals_committed_total 103076
# HELP etcd_server_proposals_failed_total The total number of failed proposals seen.
# TYPE etcd_server_proposals_failed_total counter
etcd_server_proposals_failed_total 130
# HELP etcd_server_proposals_pending The current number of pending proposals to commit.
# TYPE etcd_server_proposals_pending gauge
etcd_server_proposals_pending 0
# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 2.7515e-05
go_gc_duration_seconds{quantile="0.25"} 6.2877e-05
go_gc_duration_seconds{quantile="0.5"} 0.000112538
go_gc_duration_seconds{quantile="0.75"} 0.000194799
go_gc_duration_seconds{quantile="1"} 0.246447656
go_gc_duration_seconds_sum 1.108936047
go_gc_duration_seconds_count 324
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 966
# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
# TYPE go_memstats_alloc_bytes gauge
go_memstats_alloc_bytes 2.378836e+07
# HELP go_memstats_alloc_bytes_total Total number of bytes allocated, even if freed.
# TYPE go_memstats_alloc_bytes_total counter
go_memstats_alloc_bytes_total 3.045720936e+09
# HELP go_memstats_buck_hash_sys_bytes Number of bytes used by the profiling bucket hash table.
# TYPE go_memstats_buck_hash_sys_bytes gauge
go_memstats_buck_hash_sys_bytes 1.59714e+06
# HELP go_memstats_frees_total Total number of frees.
# TYPE go_memstats_frees_total counter
go_memstats_frees_total 2.4471211e+07
# HELP go_memstats_gc_sys_bytes Number of bytes used for garbage collection system metadata.
# TYPE go_memstats_gc_sys_bytes gauge
go_memstats_gc_sys_bytes 2.332672e+06
# HELP go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in use.
# TYPE go_memstats_heap_alloc_bytes gauge
go_memstats_heap_alloc_bytes 2.378836e+07
# HELP go_memstats_heap_idle_bytes Number of heap bytes waiting to be used.
# TYPE go_memstats_heap_idle_bytes gauge
go_memstats_heap_idle_bytes 2.7303936e+07
# HELP go_memstats_heap_inuse_bytes Number of heap bytes that are in use.
# TYPE go_memstats_heap_inuse_bytes gauge
go_memstats_heap_inuse_bytes 3.2169984e+07
# HELP go_memstats_heap_objects Number of allocated objects.
# TYPE go_memstats_heap_objects gauge
go_memstats_heap_objects 56163
# HELP go_memstats_heap_released_bytes_total Total number of heap bytes released to OS.
# TYPE go_memstats_heap_released_bytes_total counter
go_memstats_heap_released_bytes_total 1.9423232e+07
# HELP go_memstats_heap_sys_bytes Number of heap bytes obtained from system.
# TYPE go_memstats_heap_sys_bytes gauge
go_memstats_heap_sys_bytes 5.947392e+07
# HELP go_memstats_last_gc_time_seconds Number of seconds since 1970 of last garbage collection.
# TYPE go_memstats_last_gc_time_seconds gauge
go_memstats_last_gc_time_seconds 1.5182259817514844e+09
# HELP go_memstats_lookups_total Total number of pointer lookups.
# TYPE go_memstats_lookups_total counter
go_memstats_lookups_total 20744
# HELP go_memstats_mallocs_total Total number of mallocs.
# TYPE go_memstats_mallocs_total counter
go_memstats_mallocs_total 2.4527374e+07
# HELP go_memstats_mcache_inuse_bytes Number of bytes in use by mcache structures.
# TYPE go_memstats_mcache_inuse_bytes gauge
go_memstats_mcache_inuse_bytes 2400
# HELP go_memstats_mcache_sys_bytes Number of bytes used for mcache structures obtained from system.
# TYPE go_memstats_mcache_sys_bytes gauge
go_memstats_mcache_sys_bytes 16384
# HELP go_memstats_mspan_inuse_bytes Number of bytes in use by mspan structures.
# TYPE go_memstats_mspan_inuse_bytes gauge
go_memstats_mspan_inuse_bytes 402648
# HELP go_memstats_mspan_sys_bytes Number of bytes used for mspan structures obtained from system.
# TYPE go_memstats_mspan_sys_bytes gauge
go_memstats_mspan_sys_bytes 540672
# HELP go_memstats_next_gc_bytes Number of heap bytes when next garbage collection will take place.
# TYPE go_memstats_next_gc_bytes gauge
go_memstats_next_gc_bytes 4.6783152e+07
# HELP go_memstats_other_sys_bytes Number of bytes used for other system allocations.
# TYPE go_memstats_other_sys_bytes gauge
go_memstats_other_sys_bytes 606756
# HELP go_memstats_stack_inuse_bytes Number of bytes in use by the stack allocator.
# TYPE go_memstats_stack_inuse_bytes gauge
go_memstats_stack_inuse_bytes 5.013504e+06
# HELP go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator.
# TYPE go_memstats_stack_sys_bytes gauge
go_memstats_stack_sys_bytes 5.013504e+06
# HELP go_memstats_sys_bytes Number of bytes obtained by system. Sum of all system allocations.
# TYPE go_memstats_sys_bytes gauge
go_memstats_sys_bytes 6.9581048e+07
# HELP grpc_server_handled_total Total number of RPCs completed on the server, regardless of success or failure.
# TYPE grpc_server_handled_total counter
grpc_server_handled_total{grpc_code="Canceled",grpc_method="LeaseKeepAlive",grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"} 96
grpc_server_handled_total{grpc_code="Internal",grpc_method="LeaseKeepAlive",grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"} 167
grpc_server_handled_total{grpc_code="Internal",grpc_method="Watch",grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"} 77
grpc_server_handled_total{grpc_code="OK",grpc_method="Compact",grpc_service="etcdserverpb.KV",grpc_type="unary"} 82
grpc_server_handled_total{grpc_code="OK",grpc_method="LeaseGrant",grpc_service="etcdserverpb.Lease",grpc_type="unary"} 365
grpc_server_handled_total{grpc_code="OK",grpc_method="Range",grpc_service="etcdserverpb.KV",grpc_type="unary"} 49462
grpc_server_handled_total{grpc_code="OK",grpc_method="Txn",grpc_service="etcdserverpb.KV",grpc_type="unary"} 27490
grpc_server_handled_total{grpc_code="Unavailable",grpc_method="LeaseGrant",grpc_service="etcdserverpb.Lease",grpc_type="unary"} 64
grpc_server_handled_total{grpc_code="Unavailable",grpc_method="Range",grpc_service="etcdserverpb.KV",grpc_type="unary"} 27
grpc_server_handled_total{grpc_code="Unavailable",grpc_method="Txn",grpc_service="etcdserverpb.KV",grpc_type="unary"} 56
grpc_server_handled_total{grpc_code="Unavailable",grpc_method="Watch",grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"} 166
grpc_server_handled_total{grpc_code="Unknown",grpc_method="Txn",grpc_service="etcdserverpb.KV",grpc_type="unary"} 1
# HELP grpc_server_msg_received_total Total number of RPC stream messages received on the server.
# TYPE grpc_server_msg_received_total counter
grpc_server_msg_received_total{grpc_method="Compact",grpc_service="etcdserverpb.KV",grpc_type="unary"} 82
grpc_server_msg_received_total{grpc_method="LeaseGrant",grpc_service="etcdserverpb.Lease",grpc_type="unary"} 429
grpc_server_msg_received_total{grpc_method="Range",grpc_service="etcdserverpb.KV",grpc_type="unary"} 49489
grpc_server_msg_received_total{grpc_method="Txn",grpc_service="etcdserverpb.KV",grpc_type="unary"} 27547
grpc_server_msg_received_total{grpc_method="Watch",grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"} 303
# HELP grpc_server_msg_sent_total Total number of gRPC stream messages sent by the server.
# TYPE grpc_server_msg_sent_total counter
grpc_server_msg_sent_total{grpc_method="Compact",grpc_service="etcdserverpb.KV",grpc_type="unary"} 82
grpc_server_msg_sent_total{grpc_method="LeaseGrant",grpc_service="etcdserverpb.Lease",grpc_type="unary"} 365
grpc_server_msg_sent_total{grpc_method="Range",grpc_service="etcdserverpb.KV",grpc_type="unary"} 49462
grpc_server_msg_sent_total{grpc_method="Txn",grpc_service="etcdserverpb.KV",grpc_type="unary"} 27490
grpc_server_msg_sent_total{grpc_method="Watch",grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"} 27587
# HELP grpc_server_started_total Total number of RPCs started on the server.
# TYPE grpc_server_started_total counter
grpc_server_started_total{grpc_method="Compact",grpc_service="etcdserverpb.KV",grpc_type="unary"} 82
grpc_server_started_total{grpc_method="LeaseGrant",grpc_service="etcdserverpb.Lease",grpc_type="unary"} 429
grpc_server_started_total{grpc_method="LeaseKeepAlive",grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"} 328
grpc_server_started_total{grpc_method="Range",grpc_service="etcdserverpb.KV",grpc_type="unary"} 49489
grpc_server_started_total{grpc_method="Txn",grpc_service="etcdserverpb.KV",grpc_type="unary"} 27547
grpc_server_started_total{grpc_method="Watch",grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"} 303
# HELP http_request_duration_microseconds The HTTP request latencies in microseconds.
# TYPE http_request_duration_microseconds summary
http_request_duration_microseconds{handler="prometheus",quantile="0.5"} NaN
http_request_duration_microseconds{handler="prometheus",quantile="0.9"} NaN
http_request_duration_microseconds{handler="prometheus",quantile="0.99"} NaN
http_request_duration_microseconds_sum{handler="prometheus"} 0
http_request_duration_microseconds_count{handler="prometheus"} 0
# HELP http_request_size_bytes The HTTP request sizes in bytes.
# TYPE http_request_size_bytes summary
http_request_size_bytes{handler="prometheus",quantile="0.5"} NaN
http_request_size_bytes{handler="prometheus",quantile="0.9"} NaN
http_request_size_bytes{handler="prometheus",quantile="0.99"} NaN
http_request_size_bytes_sum{handler="prometheus"} 0
http_request_size_bytes_count{handler="prometheus"} 0
# HELP http_response_size_bytes The HTTP response sizes in bytes.
# TYPE http_response_size_bytes summary
http_response_size_bytes{handler="prometheus",quantile="0.5"} NaN
http_response_size_bytes{handler="prometheus",quantile="0.9"} NaN
http_response_size_bytes{handler="prometheus",quantile="0.99"} NaN
http_response_size_bytes_sum{handler="prometheus"} 0
http_response_size_bytes_count{handler="prometheus"} 0
# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE process_cpu_seconds_total counter
process_cpu_seconds_total 241.24
# HELP process_max_fds Maximum number of open file descriptors.
# TYPE process_max_fds gauge
process_max_fds 65536
# HELP process_open_fds Number of open file descriptors.
# TYPE process_open_fds gauge
process_open_fds 92
# HELP process_resident_memory_bytes Resident memory size in bytes.
# TYPE process_resident_memory_bytes gauge
process_resident_memory_bytes 6.3168512e+07
# HELP process_start_time_seconds Start time of the process since unix epoch in seconds.
# TYPE process_start_time_seconds gauge
process_start_time_seconds 1.51818851942e+09
# HELP process_virtual_memory_bytes Virtual memory size in bytes.
# TYPE process_virtual_memory_bytes gauge
process_virtual_memory_bytes 1.082361856e+10```

sync duration of 23.383339906s, expected less than 1s

Is this using HDD?
etcd is I/O intensive, persisting Raft entries with application data on disk.
You need better disk.

yeah, something doesn't look right with the sync duration.

Thank you for getting back so promptly. Is disk the only reason that cause sync duration high and etcd timeout? Why would etcd timeout so fast at the begining of cluster creation? Is Kubernetes stressing etcd too much? Do we have guidelines on CPU/Memory for etcd/k8s-apiserver VMs?
Thanks a lot.

We have general hardward setting guide https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md, but not Kubernetes specific.
The metrics

grpc_server_handled_total{grpc_code="Unavailable",grpc_method="LeaseGrant",grpc_service="etcdserverpb.Lease",grpc_type="unary"} 64
grpc_server_handled_total{grpc_code="Unavailable",grpc_method="Range",grpc_service="etcdserverpb.KV",grpc_type="unary"} 27
grpc_server_handled_total{grpc_code="Unavailable",grpc_method="Txn",grpc_service="etcdserverpb.KV",grpc_type="unary"} 56
grpc_server_handled_total{grpc_code="Unavailable",grpc_method="Watch",grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"} 166
grpc_server_handled_total{grpc_code="Unknown",grpc_method="Txn",grpc_service="etcdserverpb.KV",grpc_type="unary"} 1

indicates a bunch of v3 requests timed out, but these workloads are not that intensive. etcd with better disk should be able to handle much more pressing workloads.

for ebs backed instance, you might consider to  use Provisioned IOPS (SSD) volumes offer storage with consistent and low-latency performance, and are designed for I/O intensive applications such as large relational or NoSQL databases. for better I/O performance.

authors: Lokicity fanminshi gyuho


text:
WIP (rafthttp: retry proposal)

The transport layer now drops all messages if the connection
is not good. Raft will generally retry messages, however proposal
is an exception since it is not a raft generated message.
We now retry once at transport layer.
@heyitsanthony This is a WPI. Seeking for early opinions. I hate the retryTerm thing. But I have no other easy way to make it work.

Closing after an offline discussion with @heyitsanthony.
The problem we worry about is that retry might lead to duplicate proposals. This is hard to achieve for today's transport layer since there is no seq/id assigned to each message for us to dedup.

source: gharchive/pull-request

repo: coreos/etcd

license_type: permissive

license_source: github-api


text:
pods "prometheus-prometheus-0" is forbidden when creating a new prometheus server on a different namespace

What did you do?
prom.yml
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  namespace: istio-system
spec:
  serviceAccountName: prometheus
  serviceMonitorSelector:
    matchLabels:
      istio: monitoring

kubectl apply -f prom.yml
What did you expect to see?
A prometheus server running on that namespace.
What did you see instead? Under which circumstances?
A stateful set failing to be created.
create Pod prometheus-prometheus-0 in StatefulSet prometheus-prometheus failed error: pods "prometheus-prometheus-0" is forbidden: service account istio-system/prometheus was not found, retry after the service account is created
Environment
AWS

Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.0", GitCommit:"fc32d2f3698e36b93322a3465f63a14e9f0eaead", GitTreeState:"clean", BuildDate:"2018-03-27T00:13:02Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.7", GitCommit:"b30876a5539f09684ff9fde266fda10b37738c9c", GitTreeState:"clean", BuildDate:"2018-01-16T21:52:38Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes cluster kind:
kops

Prometheus Operator Logs:

ts=2018-03-29T03:10:17.953388986Z caller=operator.go:672 component=prometheusoperator msg="sync prometheus" key=monitoring/kube-prometheus
ts=2018-03-29T03:10:17.963130314Z caller=operator.go:981 component=prometheusoperator msg="updating config skipped, no configuration change"
ts=2018-03-29T03:10:17.975837608Z caller=operator.go:672 component=prometheusoperator msg="sync prometheus" key=istio-system/prometheus
ts=2018-03-29T03:10:17.981400498Z caller=operator.go:981 component=prometheusoperator msg="updating config skipped, no configuration change"
ts=2018-03-29T03:10:20.116726088Z caller=operator.go:672 component=prometheusoperator msg="sync prometheus" key=istio-system/prometheus
ts=2018-03-29T03:10:20.124098572Z caller=operator.go:981 component=prometheusoperator msg="updating config skipped, no configuration change"
ts=2018-03-29T03:10:25.126926043Z caller=operator.go:672 component=prometheusoperator msg="sync prometheus" key=istio-system/prometheus
ts=2018-03-29T03:10:25.132565028Z caller=operator.go:981 component=prometheusoperator msg="updating config skipped, no configuration change"
ts=2018-03-29T03:10:30.132331186Z caller=operator.go:672 component=prometheusoperator msg="sync prometheus" key=istio-system/prometheus
ts=2018-03-29T03:10:30.139420888Z caller=operator.go:981 component=prometheusoperator msg="updating config skipped, no configuration change"
ts=2018-03-29T03:10:35.142729734Z caller=operator.go:672 component=prometheusoperator msg="sync prometheus" key=istio-system/prometheus
ts=2018-03-29T03:10:35.148308816Z caller=operator.go:981 component=prometheusoperator msg="updating config skipped, no configuration change"
ts=2018-03-29T03:10:40.148404776Z caller=operator.go:672 component=prometheusoperator msg="sync prometheus" key=istio-system/prometheus
ts=2018-03-29T03:10:40.155465608Z caller=operator.go:981 component=prometheusoperator msg="updating config skipped, no configuration change"
ts=2018-03-29T03:10:41.655554312Z caller=operator.go:325 component=alertmanageroperator msg="Alertmanager updated" key=monitoring/kube-prometheus
ts=2018-03-29T03:10:41.655604646Z caller=operator.go:381 component=alertmanageroperator msg="sync alertmanager" key=monitoring/kube-prometheus
ts=2018-03-29T03:10:45.158023179Z caller=operator.go:672 component=prometheusoperator msg="sync prometheus" key=istio-system/prometheus
ts=2018-03-29T03:10:45.163726628Z caller=operator.go:981 component=prometheusoperator msg="updating config skipped, no configuration change"
ts=2018-03-29T03:10:50.163707865Z caller=operator.go:672 component=prometheusoperator msg="sync prometheus" key=istio-system/prometheus
ts=2018-03-29T03:10:50.171283077Z caller=operator.go:981 component=prometheusoperator msg="updating config skipped, no configuration change"
ts=2018-03-29T03:10:55.175990536Z caller=operator.go:672 component=prometheusoperator msg="sync prometheus" key=istio-system/prometheus
ts=2018-03-29T03:10:55.182879811Z caller=operator.go:981 component=prometheusoperator msg="updating config skipped, no configuration change"

I know this has to do with permission issues of some sort. I've read just about every issue related to this and I understand the goal is to have a way to deploy a single prometheus server per namespace(if wanted) But I'm not able to do so and it's not very clear what roles are necessary to make it work in other namespaces. Also when I try to create this same file or even a servicemonitor resource in the monitoring namespace, I get similar permission errors.

I'm going to close this since a fresh day let me get a grip of the paradigm and I'm getting it!

source: gharchive/issue

repo: coreos/prometheus-operator


text:
Multiple prometheus objects in the same namespace get added to the same default 'prometheus' service

Prometheus Operator seems to create default service objects named prometheus and alertmanager. If you create more than one prometheus object in the same namespace (E.G. frontend and backend, both in the monitoring namespace,) then both get added to the same default service named prometheus, as seen in the related endpoints object. (Looks like the same would happen if for some reason you wanted more than one alertmanager object in the same namespace.)
This is confusing and I imagine not what was intended. (Or maybe there's a purpose I'm missing?)
I'm unclear as to the purpose of these default service objects. I'm creating my own as I need to control various aspects including annotations.
P.S. Hope I'm not creating too many issues, love what you guys are doing, hoping to help!

No worries - all feedback is good feedback! 👍
Those Service objects are created to satisfy the StatefulSets need for a governing service, for stable DNS names. These services are not suitable for accessing the underlying Prometheus/Alertmanager instances. For that purpose we wanted to be unopinionated about how someone exposes those.
We're working on versioned user-guides and documentation, but are not quite ready yet unfortunately, but I can imagine this kind of information going there. Until then open as many issues as you want 🙂

@brancz thanks!
OK. It sounds like it's OK to have more than one prometheus object connected to this governing service, do you agree? - It's just for internal usage by Prometheus Operator?
I think we can close this issue.

Yep it is purely intended for internal use. If we hit any issues regarding that we can reconsider it, but it allows us to just make sure there is one Service per Namespace and not worry about it further. But if we hit any limitations on this path it won't be a problem to change this behavior.

authors: brancz snarlysodboxer


text:
REQUEST-912-DOS-PROTECTION paranoia level 2 sets ip.dos_block=1 outside of dos_burst_time_slice window

Describe the bug
I've experienced issues whereby dos-protection is kicking in, without the request count exceeding a threshold within the given time slice window. This appears when the client is slowly sending traffic regularly over a period of time.
Premise is that paranoid level 2 should take into account dos_burst_time_slice before blocking an address, and it is not.
I've tried to follow the logic through https://github.com/coreruleset/coreruleset/blob/v3.3/master/rules/REQUEST-912-DOS-PROTECTION.conf

and looking for validation or correction of my understanding.

With paranoia level set to 2, IP:DOS_COUNTER is able to exceed TX:DOS_COUNTER_THRESHOLD and set ip.dos_block=1 without consideration of account dos_burst_time_slice

id:912160 or id:912161 can reset ip:dos_counter.
id:912160 sets ip.dos_burst_counter=1 irrespective of time taken for ip.dos_burst_counter to reach tx.dos_counter_threshold
id:912171 with ip.dos_burst_counter set to 1,  ip.dos_block is set to 1
id:912120 bocks request

With paranoia of 1 this is not an issue as id:912170, both id:912160 and id: 912161 and this flow takes into account tx.dos_burst_time_slice.
https://github.com/coreruleset/coreruleset/blob/v3.3/master/rules/REQUEST-912-DOS-PROTECTION.conf
Steps to reproduce
Set paranoia to 2 and send a slow rate of requests that reach tx.dos_counter_threshold within modsecurity's overall capture time, but less than dos_counter_threshold
Expected behaviour
I expect paranoia 2 to set ip.dos_block=1 only when ip:dos_counter has exceeded tx.dos_counter_threshold within a given tx.dos_burst_time_slice
Actual behaviour
ip.dos_block is set to 1 within id:912171 and traffic is blocked, without ip:dos_counter reaching tx.dos_counter_threshold within tx.dos_burst_time_slice
Additional context
Your Environment

CRS version: 3.3.0
Paranoia level setting: 2

The plugin pull request is about to be merged. This will allow to take the DOS rules and transform them into an official CRS plugin as has been our plan for quite some time. I will also address this issue here when making that transformation.
Thank you for reporting and sorry for not responding earlier.

I think this affects Paranoia level 1 also.
The issue was already described here.
I've tried to raise the dos_counter_threshold, but it's just delaying the problem : it seems that dos_burst_time_slice does not work as intended. I'm also using CRS v3.3.0
For now I've disabled the rule, but I'll be happy to test a correction.

Thank you for this complementary remark, @jacen05.

Status: This is clearly on my turf and I am postponing this constantly while life interferes. Sorry. Yet I am none the wise and can not give a clear date, I'm behind on many fronts.

Additional fail occurs when PARANOIA_LEVEL=1 and EXECUTING_PARANOIA_LEVEL=2. Due to here...
https://github.com/coreruleset/coreruleset/blob/8a7a8960c2721890054ec1f5d9e79f9dc62ac991/rules/REQUEST-912-DOS-PROTECTION.conf#L273-L275
With EPL=2, it will continue and then apply rule 912171 which causes immediate DOS block as if PL=2.
This is a discontinuity in the intention of EPL to get warnings but not apply blocks.

@diablodale Thanks for digging into this! Can you be so kind and open a new issue? Thank you.

I think there is a misconception here w.r.t. how DOS blocking works (admittedly, it's not intuitive). TX:DOS_BURST_TIME_SLICE is only relevant for paranoia level 1, because it is applied to IP:DOS_BURST_COUNTER, not to IP:DOS_COUNTER. Hence, at paranoia level 2 the rules block immediately whenever a burst is detected.
It is possible that this was never the intention. To fix it I see two options:

Make PL 2 depend on TX:DOS_BURST_TIME_SLICE:

PL 1 should block at IP:DOS_BURST_COUNTER >= 3
PL 2 should block at IP:DOS_BURST_COUNTER >= 2

Expire IP:DOS_COUNTER after TX:DOS_BURST_TIME_SLICE, not IP:DOS_BURST_COUNTER (or both, for that matter).

Option two is probably the right way to go.

Digging in my memory and reporting from family holidays in Calanca, GR, Switzerland, where I used the early morning hours to document and clean up the DOS rules, I can report the following:

The idea was indeed to see PL2 as strict sibling of the burst counter rule in PL1. I think I remember that it was intended to block regardless of burst counter.

I am not convinced this is correct or smart, but this is what I thought was the intention of the rules and one way to add a stricter sibling. A new concept back in the day.
Can you elaborate some more what option 2 would mean and how the behaviour would change.
If we would opt for options 1, then I think there is nothing wrong with this approach. Maybe add a PL3 rule retains the current PL2 behaviour: blocking on the first burst.

I think option 2 is semantically correct. It is not the burst that becomes invalid after a certain time. We actually want some way to define what we consider a burst to look like. I think that we should use two different timeout variables, one for counting requests toward a burst, and one to expire bursts.
What I'm struggling with is how to properly define a sliding window. Static windows would be easy to do but aren't optimal. In theory, an attacker could send requests to determine the window size and then bombard the service such that it never registers enough requests to go into blocking mode. With a sliding window, the attacker would at least have to wait for an entire window before resuming the attack.
However, as pointed out elsewhere, CRS isn't the proper tool to defend against serious DoS attacks, so maybe static windows are good enough.
With the current approach, almost every IP will trigger the first burst, since the request counter is only reset once the threshold has been reached. To retain the current behaviour, we would actually need block at PL1 after the first burst, however, I think it would be better to wait until we've identified a second burst. So, for both PL1 and PL2, adding a timeout to the request counter means that the rules will block later than they would now (one timeout window later) but I think that is actually a good thing and will reduce the number of FP's (I had a couple of issues with FP's and had to increase the timeout / disable the rules for certain IP's).
Technically speaking, we would introduce one new variable TX:DOS_COUNTER_TIME_SLICE which would be initialized to the same value as TX:DOS_BURST_TIME_SLICE by default. Then we'd add a new rule that would expire IP:DOS_COUNTER with the value of TX:DOS_COUNTER_TIME_SLICE if it is unset. When TX:DOS_COUNTER_THRESHOLD has been reached, we unset IP:DOS_COUNTER (instead of using "unset" as the initialization state we could also use the value 0 of the counter; this could be safer to use with the other rules).
To summarise, I think option 2 would be cleaner and semantically correct, however, it also introduces additional complexity into a system that is very hard to understand in its current state. Option 1 would certainly be the "simple" fix.

@dune73 I've created a proof of concept PR https://github.com/coreruleset/dos-protection-plugin-modsecurity-v2/pull/3.

ping alive

ping alive

@diablodale Did you tested what @theseion created?

hi @fzipi, I have not tested the proof of concept. I doubt I can provide solid testing feedback as I do not have the deep experience to test it. I can read the code, yet that's not the same. :-/

I sat down and looked at the  proof of concept PR by @theseion linked above.
There are several issues and I eventually gave up on this.
Here is a list:

rule ID 9514110 used twice
dos-protection-before.conf, line 221, single quote not closed
dos-protection-config.conf, line 36, single quote not closed

When fixing these, apache starts.
But then comes the next problem:
The central rule 9514120 runs in phase 1 and thus before REQUEST-901 that initialized the IP collection. 9514120 references the IP collection that is only initialized afterwards. So this can not work and rules ought to be rearranged.
I think we would fare best if IP collection initialization would be removed from main CRS alltogether and the plugin should come with the init that can also be switched off via a config item. Explain in the README that you have to pay attention that not more than one plugin initializes the collection etc. Then it should work.

I've updated the PR with fixes to the format issues you found. Do we have a resolution in collection initialisation by now? I vaguely recall that we had discussed something in a meeting.

@theseion Found it:

CRS no longer needs collections, but plugins may want to work with collections
-> Decisions: CRS initializes them for the plugins, off by default

crs-setup.conf has (commented out) rule 900130 which contains the action setvar:tx.enable_default_collections=1 to enable collection initialisation.

@theseion What's next here?

We had decided that:

🔵 Decision: @theseion with help of @dune73 and @airween will try to check for initcol. If the collection is initialized by the plugin -> remove the 901 rule via ctl statement and do initcol yourself.

Should we move this one to https://github.com/coreruleset/dos-protection-plugin-modsecurity ? Or the ctl will be for the core instead?

Yes

authors: RedXanadu azurit diablodale dune73 fzipi jacen05 jelsdon theseion

repo: coreruleset/coreruleset

license_source: bigquery


text:
npm installation fails because "The filename or extension is too long."

My Environment

[ ] Windows 7 or below (not truly supported due to EOL - see wiki for details)

[ ] Windows 8

[ ] Windows 8.1

[x] Windows 10

[ ] Windows 10 IoT Core

[ ] Windows Server 2012

[ ] Windows Server 2012 R2

[ ] Windows Server 2016

[x] My Windows installation is non-English.

Language is Italian
I'm using NVM4W version:

[ ] 1.1.6
[x] 1.1.5
[ ] 1.1.4
[ ] 1.1.3
[ ] 1.1.2
[ ] 1.1.1
[ ] Older
[ ] OTHER (Please Specify)

I have already...

[x] read the README to be aware of npm gotchas & antivirus issues.
[x] reviewed the wiki to make sure my issue hasn't already been resolved.
[x] verified I'm using an account with administrative privileges.
[x] searched the issues (open and closed) to make sure this isn't a duplicate.
[x] made sure this isn't a question about how to use NVM for Windows, since gitter is used for questions and comments.

My issue is related to (check only those which apply):

[ ] settings.txt
[ ] proxy support (Have you tried version 1.1.0+?)
[ ] 32 or 64 bit support (Have you tried version 1.1.3+?)
[ ] Character escaping (Have you tried version 1.1.6+?)
[x] A standard shell environment (terminal/powershell)
[x] A non-standard shell environment (Cmder, Hyper, Cygwin, git)

In particular, the "non standard" shell is the bash included in VS code. The same problem presents itself even when using simple "Win+R -> cmd", though.
Expected Behavior
Running nvm install <version> should install both node and npm correctly.
Actual Behavior
Node is installed, but npm fails while installing. Output is the following:
C:\example>nvm install 9.5.0
Downloading node.js version 9.5.0 (64-bit)...
Complete
Downloading npm version 5.6.0... Complete
Installing npm v5.6.0...2018/02/21 14:45:28 mkdir C:\Users\stepbeta\AppData\Roaming\nvm\temp\nvm-npm\npm-5.6.0\node_modules\libnpx\node_modules\yargs\node_modules\read-pkg-up\node_modules\read-pkg\node_modules\load-json-file\node_modules\parse-json\node_modules\error-ex\node_modules\is-arrayish: The filename or extension is too long.

C:\example>nvm use 9.5.0
Now using node v9.5.0 (64-bit)

C:\example>node
>
(To exit, press ^C again or type .exit)
>

C:\example>npm
"npm" non è riconosciuto come comando interno o esterno,
 un programma eseguibile o un file batch.

C:\example>nvm install 8.9.4
Downloading node.js version 8.9.4 (64-bit)...
Complete
Downloading npm version 5.6.0... Complete
Installing npm v5.6.0...2018/02/21 14:46:42 mkdir C:\Users\stepbeta\AppData\Roaming\nvm\temp\nvm-npm\npm-5.6.0\node_modules\libnpx\node_modules\yargs\node_modules\read-pkg-up\node_modules\read-pkg\node_modules\load-json-file\node_modules\parse-json\node_modules\error-ex\node_modules\is-arrayish: The filename or extension is too long.

C:\example>nvm use 8.9.4
Now using node v8.9.4 (64-bit)

C:\example>node
>
(To exit, press ^C again or type .exit)
>

C:\example>npm
"npm" non è riconosciuto come comando interno o esterno,
 un programma eseguibile o un file batch.

Folder structure is:
C:\Users\stepbeta\AppData\Roaming\nvm>tree
Elenco del percorso delle cartelle per il volume OS
Numero di serie del volume: xxxx-xxxx
C:.
├───temp
│   └───nvm-npm
│       └───npm-5.6.0
│           ├───.github
│           ├───bin
│           │   └───node-gyp-bin
│           ├───changelogs
│           ├───doc
│           │   ├───cli
│           │   ├───files
│           │   ├───misc
│           │   └───spec
│           ├───html
│           │   └───static
│           ├───lib
│           │   ├───auth
│           │   ├───config
│           │   ├───doctor
│           │   ├───install
│           │   │   └───action
│           │   ├───search
│           │   └───utils
│           │       └───completion
│           └───node_modules
│               ├───.bin
│               ├───abbrev
│               ├───ansi-regex
│               ├───ansicolors
│               │   └───test
│               ├───ansistyles
│               │   └───test
│               ├───aproba
│               ├───archy
│               │   ├───examples
│               │   └───test
│               ├───bin-links
│               ├───bluebird
│               │   └───js
│               │       ├───browser
│               │       └───release
│               ├───cacache
│               │   ├───lib
│               │   │   ├───content
│               │   │   └───util
│               │   ├───locales
│               │   └───node_modules
│               │       ├───ssri
│               │       └───y18n
│               ├───call-limit
│               ├───chownr
│               ├───cli-table2
│               │   ├───examples
│               │   │   └───screenshots
│               │   ├───lib
│               │   ├───node_modules
│               │   │   ├───colors
│               │   │   │   ├───examples
│               │   │   │   ├───lib
│               │   │   │   │   ├───custom
│               │   │   │   │   ├───maps
│               │   │   │   │   └───system
│               │   │   │   └───themes
│               │   │   ├───lodash
│               │   │   │   ├───array
│               │   │   │   ├───chain
│               │   │   │   ├───collection
│               │   │   │   ├───date
│               │   │   │   ├───function
│               │   │   │   ├───internal
│               │   │   │   ├───lang
│               │   │   │   ├───math
│               │   │   │   ├───number
│               │   │   │   ├───object
│               │   │   │   ├───string
│               │   │   │   └───utility
│               │   │   └───string-width
│               │   │       └───node_modules
│               │   │           ├───code-point-at
│               │   │           ├───is-fullwidth-code-point
│               │   │           │   └───node_modules
│               │   │           │       └───number-is-nan
│               │   │           └───strip-ansi
│               │   │               └───node_modules
│               │   │                   └───ansi-regex
│               │   ├───src
│               │   └───test
│               ├───cmd-shim
│               │   └───test
│               ├───columnify
│               │   └───node_modules
│               │       ├───strip-ansi
│               │       │   └───node_modules
│               │       │       └───ansi-regex
│               │       └───wcwidth
│               │           ├───docs
│               │           ├───node_modules
│               │           │   └───defaults
│               │           │       └───node_modules
│               │           │           └───clone
│               │           └───test
│               ├───config-chain
│               │   ├───node_modules
│               │   │   └───proto-list
│               │   │       └───test
│               │   └───test
│               ├───debuglog
│               ├───detect-indent
│               ├───dezalgo
│               │   ├───node_modules
│               │   │   └───asap
│               │   └───test
│               ├───editor
│               │   └───example
│               ├───find-npm-prefix
│               │   └───test
│               ├───fs-vacuum
│               │   └───test
│               ├───fs-write-stream-atomic
│               │   └───test
│               ├───gentle-fs
│               │   └───lib
│               ├───glob
│               │   └───node_modules
│               │       ├───fs.realpath
│               │       ├───minimatch
│               │       │   └───node_modules
│               │       │       └───brace-expansion
│               │       │           └───node_modules
│               │       │               ├───balanced-match
│               │       │               └───concat-map
│               │       │                   ├───example
│               │       │                   └───test
│               │       └───path-is-absolute
│               ├───graceful-fs
│               ├───has-unicode
│               ├───hosted-git-info
│               ├───iferr
│               │   └───test
│               ├───imurmurhash
│               ├───inflight
│               ├───inherits
│               ├───ini
│               ├───init-package-json
│               │   └───node_modules
│               │       ├───npm-package-arg
│               │       └───promzard
│               │           ├───example
│               │           │   └───npm-init
│               │           └───test
│               ├───is-cidr
│               │   ├───example
│               │   ├───lib
│               │   ├───node_modules
│               │   │   └───cidr-regex
│               │   │       └───lib
│               │   └───test
│               ├───JSONStream
│               │   ├───examples
│               │   ├───node_modules
│               │   │   ├───jsonparse
│               │   │   │   ├───examples
│               │   │   │   ├───samplejson
│               │   │   │   └───test
│               │   │   └───through
│               │   │       └───test
│               │   └───test
│               │       ├───disabled
│               │       └───fixtures
│               ├───lazy-property
│               └───libnpx
│                   ├───locales
│                   └───node_modules
│                       ├───dotenv
│                       │   └───lib
│                       ├───npm-package-arg
│                       ├───y18n
│                       └───yargs
│                           ├───lib
│                           ├───locales
│                           └───node_modules
│                               ├───camelcase
│                               ├───cliui
│                               │   └───node_modules
│                               │       ├───string-width
│                               │       │   └───node_modules
│                               │       │       ├───code-point-at
│                               │       │       └───is-fullwidth-code-point
│                               │       │           └───node_modules
│                               │       │               └───number-is-nan
│                               │       ├───strip-ansi
│                               │       │   └───node_modules
│                               │       │       └───ansi-regex
│                               │       └───wrap-ansi
│                               ├───decamelize
│                               ├───get-caller-file
│                               ├───os-locale
│                               │   └───node_modules
│                               │       ├───execa
│                               │       │   ├───lib
│                               │       │   └───node_modules
│                               │       │       ├───cross-spawn
│                               │       │       │   ├───lib
│                               │       │       │   │   └───util
│                               │       │       │   └───node_modules
│                               │       │       │       └───shebang-command
│                               │       │       │           └───node_modules
│                               │       │       │               └───shebang-regex
│                               │       │       ├───get-stream
│                               │       │       ├───is-stream
│                               │       │       ├───npm-run-path
│                               │       │       │   └───node_modules
│                               │       │       │       └───path-key
│                               │       │       ├───p-finally
│                               │       │       ├───signal-exit
│                               │       │       └───strip-eof
│                               │       ├───lcid
│                               │       │   └───node_modules
│                               │       │       └───invert-kv
│                               │       └───mem
│                               │           └───node_modules
│                               │               └───mimic-fn
│                               └───read-pkg-up
│                                   └───node_modules
│                                       ├───find-up
│                                       │   └───node_modules
│                                       │       └───locate-path
│                                       │           └───node_modules
│                                       │               ├───p-locate
│                                       │               │   └───node_modules
│                                       │               │       └───p-limit
│                                       │               └───path-exists
│                                       └───read-pkg
│                                           └───node_modules
│                                               └───load-json-file
│                                                   └───node_modules
│                                                       └───parse-json
│                                                           └───node_modules
│                                                               └───error-ex
│                                                                   └───node_modules
├───v8.9.4
│   └───node_modules
└───v9.5.0
    └───node_modules

Steps to reproduce the problem:

Install nvm4w v1.1.5
run nvm install 9.5.0

A possible workaround for your problem is to install nvm in a "shorter path" than C:\Users\stepbeta\AppData\Roaming\nvm. If you use something like C:\dev\nvm your problem should go away.
If you do not want to re-install you can relocate your "root": Move all files except nvm.exe, settings.txt, unins000.dat and unins000.exe to C:\dev\nvm. Then, in C:\Users\stepbeta\AppData\Roaming\nvm\settings.txt change root:  accordingly (i.e. the line should become root: C:\dev\nvm). Now, remove the symlink C:\Program Files\nodejs which has now become invalid and on the command-line, do nvm use <your-node-version>. Everything should work now, including installing a newer node version.

@davidbilge The workaround of reinstalling nvm in a shorter path did not work for me.

Duplicate of #289.

@davidbilge workaround did work for me.
My suggestion: it's non necessa move files from nvm folder. You may use subst command:
subst W: "C:\Users\YourUserName\AppData\Roaming\nvm"
and then
root: N:\
in C:\Users\YourUserName\AppData\Roaming\nvm\setting.txt
finally put the subst command in a batch file in Startup folder

authors: AnandDivakaran coreybutler davidbilge magicbruno stepbeta

repo: coreybutler/nvm-windows

license: MIT


text:
Remove semester type from database

Summary

This pull request cleans up the semesters collection by removing the type property. Should be merged and run on prod after #604 is deployed to prod.
Test Plan

npm run ts-node -- src/requirements/admin/semester-season-migration <user email> to dry-run on a single user.
npm run ts-node -- src/requirements/admin/semester-season-migration --run-on-db to run on the entire database.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant benjamin-shen

repo: cornell-dti/course-plan


text:
feat: support sigmoid voiLUTFunction

Adds support for a sigmoid lut rendered by vtkjs engine.

yarn run build:update-api and commit the generated .mds

authors: Ouwen sedghi


text:
Translation Delivery

Translation Delivery

This pull request is for translation delivery. Please review and approve them.

repo: corona-warn-app/cwa-app-android


text:
Strange Wording in Trace Location Info screen

Avoid duplicates

[x] Bug is not mentioned in the FAQ
[x] Bug is not already reported in another issue

Technical details

Device name: -
iOS Version: -
App Version: 2.0 RC 1

Describe the bug
TraceLocation_Information_Item_RenewQRCode says:
https://github.com/corona-warn-app/cwa-app-ios/blob/f531dac46eab9f34dc5c8aaf379a5a73eaa15a53/src/xcode/ENA/ENA/Resources/Localization/de.lproj/Localizable.strings#L2216
This sounds strange, the "außerhalb der Öffnungszeiten" shouldn't be on the end of the sentence.
Steps to reproduce the issue

Open CWA version 2.0
Scroll to "Sie planen eine Veranstaltung?
Click on "QR-Code erstellen"
If there's no pop up with the information click on the 3 dots in the right corner and choose "Info"
Scroll down and see the last point above of the "Datenschutz und Datensicherheit" box

Screenshot

Expected behaviour
String should be:
"Wenn Sie dauerhaft einen QR-Code verwenden, sollten Sie diesen einmal täglich außerhalb der Öffnungszeiten neu erstellen."
Possible Fix
Change the localizable strings.
Additional context
I'll provide a PR for this.

Closing this as it's fixed in #2343.

repo: corona-warn-app/cwa-app-ios


text:
Add Feedback

Users should be able to provide feedback to the chat.
This should be handled by a Feedback model, which has

chat_message : fk to ChatMessage
user : fk to User
liked : boolean
message : (optional) text

Make relevant views and serializers. Feedback should be listed with /feedback url, with possible filters -

project_id
chat_id
chat_message_id
liked

Only admins should be able to list and retrieve all feedback. Normal users can only list their own. Feedbacks cannot be deleted.

Hey @skks1212, I have a couple of questions,

In the above description, you mentioned adding user_id as a foreign key, but as the chat itself is user-specific, do we need that? :thinking:

Second is more like clarification, we should also have thumbs down, right? And as far as storing value goes, liked === null, no feedback; liked === true, thumbs up; and liked === false, thumbs down;

Hey @khavinshankar yes we can leave out the user field.
And as liked is Boolean, thumbs-up will be ===true and thumbs down will be ===false. It will be a not null field

Hey @skks1212, about /feedback endpoint, is just an endpoint enough or do we need a dedicated screen in the frontend, if so where?

@khavinshankar we need the feedback buttons on the chat UI (👍,👎) and a way to list feedbacks in the admin panel, preferably in its own page

repo: coronasafe/ayushma


text:
🛑 Catalin.ro is down

In 7e60676, Catalin.ro (https://catalin.ro) was down:

HTTP code: 403
Response time: 878 ms

Resolved: Catalin.ro is back up in 035ef5f after 7 minutes.


text:
Does the webpack prod build exclude all spec.js files from bundle.js?

Does the webpack prod build exclude all spec.js files from bundle.js?

I believe it does because webpack only compile the files that are references via require or import. You can test this by creating a new file without referencing it and you should not see it in the list of source mapped files in your browser.

Well said @kwelch. Thanks!

authors: alikor coryhouse kwelch

repo: coryhouse/react-slingshot

license: mit


text:
Problem with masonry-column and lostMasonryColumnGutterUnit

When attempting to use the masonry-column function, I continue running into an error where the gutter unit "isn't defined", regardless of the unit of measurement used for the gutter. This also occurs regardless of whether I'm defining the gutter width through the column settings, or separately, as a variable definition.

Okay, will fix today.

Fixed. Was missing a comma in var declarations. :)

authors: corysimmons jackhogg

repo: corysimmons/lost


text:
Institution2

Add Institution in Theme 4

@karleywalker can you make a fake institution logo and use it for the top page?

@Rytiggy

looks good

authors: Rytiggy caneruguz karleywalker

repo: cos-labs/osfpages


text:
Notebook-style documentation?

Hi Tivadar,
First: this is a really solid project — thank you for your contributions!
I noticed that the examples that accompany this repository are functionally sufficient, but difficult for someone to skim/follow along without running locally. Do you think it'd be worthwhile to add examples that are in a Jupyter notebook format? If so, would you mind if I took a crack at porting over one of the current scripts into a notebook (with inline plots, comments, etc.) this weekend? Thanks!
Danny

Hi Danny!
I would be happy if you try to port the examples into a Jupyter notebook! I encourage you to submit a pull request, your contribution is very much welcome!
Cheers,
Tivadar

Pool-based sampling Jupyter Notebook added by @dataframing, more to come :) I'll do some myself in the next few days hopefully!

authors: cosmic-cortex dataframing

repo: cosmic-cortex/modAL


text:
Follow up items for #3019

Once #3019 is merged, these items will be worked on in a follow-up PR:

[x] Write documentation (docs & migration) (https://github.com/cosmos/ibc-go/pull/3509)
[x] Fix base transfer e2e test (https://github.com/cosmos/ibc-go/pull/3517).
[x] Fix upgrade e2e test and make sure it passes (https://github.com/cosmos/ibc-go/pull/3605).
[x] As recommended by @colin-axner, add invariants to check that actual amounts are equal or greater than the expected escrow amount. (https://github.com/cosmos/ibc-go/pull/3506)
[x] Apply this suggestion. (https://github.com/cosmos/ibc-go/pull/3507)
[x] Add ADR and link in the code to the ADR. I think this should not block the release of the feature, though, and we can add it afterwards. (https://github.com/cosmos/ibc-go/pull/3641)
[x] add link in migration docs once backport is merged (see TODO)

Closed by #3558

repo: cosmos/ibc-go


text:
Godoc comments

Summary of Improvement
Surfaced as part of an audit.

[ ]  All public functions should have godoc comments.
[ ]  update doc for interchain account proto type

InterchainAccount proto type godoc should specify
An InterchainAccount is defined as a BaseAccount & the address of the account owner on the controller chain

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged/assigned

@colin-axner Do you remember which functions?
@damiannolan maybe we can do a quick review of the godoc? :eyeglasses:

This should be pretty trivial. Everything that's pkg exported/public should have a godoc and be written in the form:
// FunctionName ...
func FunctionName() {}

I spotted some undocumented functions in module.go, but there might be some missing in other files

@damiannolan can we close this?

@seantking I can close it after the remaining PRs are merged. I think there's a bunch of godocs being added in them

authors: colin-axner damiannolan seantking


text:
Dev

add 3 parameter to control the details of function ePie

https://github.com/cosname/recharts/blob/dev/docs/03-basicFunction.Rmd
在这个页面的饼图里面也增加一下控制中心的代码吧

authors: Lchiffon yefeimagina

repo: cosname/recharts


text:
Add docker-compose for benchmarks with collection profiling data

Here added new run_transparent.sh script in benchmarks/ folder that runs simple commands that generate data in simple table and then read from database directly and through acra-server. That helps compare gap between DB and DB + Acra.
It is simplified existing benchmark/run.sh script, with calling same logic as for direct database, but through acra-server in transparent mode too.
Additionally added fetching profiling data from http debug server to analyze it with go tool pprof after that.
For now it's only for postgresql because used existing code that worked only with this db.

Checklist

[+] Change is covered by automated tests
[+] The coding guidelines are followed
[+] Public API has proper documentation in the Acra documentation site or has PR on documentation repository
with new changes
[+] CHANGELOG.md is updated (in case of notable or breaking changes)
[+] CHANGELOG_DEV.md is updated
[+] Benchmark results are attached (if applicable)
[+] Example projects and code samples are up-to-date (in case of API changes)

One thing that came to my mind is that we may want to store PostgreSQL's data (which by default lives in /var/lib/postgres/data or somewhere there) in tmpfs to ensure that the time needed to write/read all the columns data (directly, or through AcraServer) will be equal

authors: Lagovas iamnotacake

repo: cossacklabs/acra


text:
rust: Add Send bound to SecureSessionTransport trait

New Clippy 1.58 has found an unsoundness in RustThemis: unsafe impl for SecureSession make it Send – safe to pass over to a different thread – but in fact it's not safe to do that unless SecureSessionTransport implementation used by SecureSession is also Send, which was expected but never required. Well, now it is required.
This would break application code that uses SecureSessionTransport implementations that are !Send (e.g., using Rc inside, or raw pointers). This is not safe if SecureSession is moved to another thread, but it should be okay if it stays on the same thread as its transport.
I believe that most applications will not be affected by this change. If someone is really out there using !Send transports, they'd come complaining, then I'd decide what to do: either tell them “you're doing it wrong”, or make a patch release that make it possible to SecureSession to be !Send as well.
For now, my goal is to fix a warning from Clippy on CI.
Checklist

[x] Change is covered by automated tests
[x] The coding guidelines are followed
[x] Changelog is updated

Ha-ha, "all users", said I. Our own integration tests are those affected users, it seems.

Should we update Thread Safety guidelines too?
https://docs.cossacklabs.com/themis/debugging/thread-safety/#secure-comparator-secure-session

Should we update Thread Safety guidelines too?

I think it will be okay as is, no need to add any extra warnings there.
Contrary to C++, if a Rust application tries to use SecureSession in unsafe way, the compiler will show an error. Send and Sync traits are there to help. In other languages we have to resort to "pls don't do that, it's not safe" in documentation because it's not possible to enforce the requirements at compile-time.

In other languages .. it's not possible to enforce the requirements at compile-tim

Rust rules!

authors: ilammy vixentael

repo: cossacklabs/themis


text:
🛑 Mainnet [TezTools] (eu01-node.teztools.net) is down

In 840c982, Mainnet [TezTools] (eu01-node.teztools.net) (https://eu01-node.teztools.net/chains/main/blocks/head/header) was down:

HTTP code: 502
Response time: 133 ms

Resolved: Mainnet [TezTools] (eu01-node.teztools.net) is back up in e77234f.

repo: cotezos/teznodes


text:
🛑 Mainnet [TezTools] (eu01-node.teztools.net) is down

In 5ba2732, Mainnet [TezTools] (eu01-node.teztools.net) (https://eu01-node.teztools.net/chains/main/blocks/head/header) was down:

HTTP code: 502
Response time: 603 ms

Resolved: Mainnet [TezTools] (eu01-node.teztools.net) is back up in e6639c6.


text:
Download error cs-x86_64-pc-win32.exe for v2.0.1

I executed cs.exe on Windows 10 and it crashed because of javax.net.ssl.SSLHandshakeException. I realized the file v2.0.1/cs-x86_64-pc-win32.exe does not exist. Please advise. Thanks
Checking if the standard Scala applications are installed
Found ammonite
Exception in thread "main" coursier.cache.ArtifactError$DownloadError: download error: Caught javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure (Received fatal alert: handshake_failure) while downloading https://github.com/coursier/coursier/releases/download/v2.0.1/cs-x86_64-pc-win32.exe
at coursier.cache.FileCache$.helper$2(FileCache.scala:1019)
at coursier.cache.FileCache$.coursier$cache$FileCache$$downloading(FileCache.scala:1033)
at coursier.cache.FileCache.doDownload$1(FileCache.scala:321)
at coursier.cache.FileCache.$anonfun$download$55(FileCache.scala:508)
at coursier.cache.CacheLocks$.loop$1(CacheLocks.scala:72)
at coursier.cache.CacheLocks$.withLockOr(CacheLocks.scala:98)

Thanks for the report! I was able to reproduce that on my Windows machine, with cs 2.0.0, by doing
> cs install --install-dir test-install cs

The missing 2.0.1 launcher should have been silently ignored (these were not published because of an issue on the CI), and the 2.0.0 launcher should have been pulled instead. This is what happens on Linux and macOS.
Weirdly enough, it seems only to happen with the native launcher, not with the JVM-based one, and only on Windows. So as a workaround, if you already have a JVM installed, you can just use the JVM-based launcher, until 2.0.2 is released.
https://github.com/coursier/coursier/pull/1893 should fix that, and the upcoming 2.0.2 artifacts should also make old launchers not run into that error.

It turned out the issue was more complex than that, and wasn't really fixed in 2.0.2… see https://github.com/coursier/coursier/issues/1894. 2.0.3 should (really) fix that.

authors: alexarchambault sshark

repo: coursier/coursier


text:
fix(genAI): set loading dots to atomic-primary

Huge change to set loading icon to atomic-primary instead of the hardcoded #1372ec. The default color of atomic-primary is also #1372ec.
https://coveord.atlassian.net/browse/SVCINT-2527

@y-lakhdar or @louis-bompart could you merge this major CSS update for me 🙏

@y-lakhdar or @louis-bompart could you merge this major CSS update for me 🙏

no u. (fixed the access)

authors: dguerinCoveo louis-bompart

repo: coveo/ui-kit


text:
Data undefined in "state_test_data" ?

The testsperthousand and testpositivityrate got undefined which was working yesterday
Please look at this issue asap

We're facing the same issue! Is there a particular reason why these variables have been discontinued?

We're facing the same issue! Is there a particular reason why these variables have been discontinued?

Well Idk, they have changed some their urls too I guess

@the-wrong-guy thanks for reporting the issue. Could you post the endpoint that you are using?

@the-wrong-guy @sky-megh  These fields have not been updated for long. It's better if you calculate the testpositivity rate at your end from the cases and the tests conducted.
Also, you can get the state and district population that we are using from : https://api.covid19india.org/misc.json

@the-wrong-guy @sky-megh These fields have not been updated for long. It's better if you calculate the testpositivity rate at your end from the cases and the tests conducted.
Also, you can get the state and district population that we are using from : https://api.covid19india.org/misc.json

Well I have little confusion on which particular end point the error is happening cause while in my app I am getting different data but again testing in Postman I am getting different set of data. So again I will check and let you know soon

authors: sky-megh sudevschiz the-wrong-guy


text:
Delhi map does not show information

Describe the bug
Delhi map does not show information when you click on Delhi.
To Reproduce
Steps to reproduce the behavior:

Click on Delhi from the state list.
Select the Delhi map from the India map.
See error

Expected behavior
It should show information on the Delhi map like other states.
Screenshots

Desktop (please complete the following information):

OS: Windows 10
Browser: Chrome
Version: 80.0.3987.149

It is happening for
firefox too
on ubuntu

Probably happening because the name district and state is the same
and the bug starts happening when we start hovering, and the data initially shown is also of delhi as district not state

@jeremyphilemon Please review PR #303

covid19india/api/state_district_wise.json
in line 76 if you just change Delhi to New Delhi the bug would be solved just by adding simply one word


text:
localization support 2

Revision of #132, Closes #21
Changelog

localization using react-i18next
Compare to previous PR translations are not prebundled into code but instead will be loaded dynamically on switch

This is amazing! 🎉
I went through it and it looks great! It looks like it can use some polishes considering some of the words aren't getting translated, examples – district tables, the banner, and some of the map regions.
Let me know how much of the translations we can support, and how much tinkering we'd have to do to fully support all the words!

Thanks @jeremyphilemon ,
Currently banners and FAQ's are coming from https://api.covid19india.org which are not directly translatable, I have two suggestions for this let me know which one

we can add all of this to JSON files but then content editing using google sheets will be gone 😔
Make changes in API to generate multiple JSON's like website_data_en.json and faq_en.json once it's done and deployed we can easily make it multilingual

Meanwhile, I'll look into district translation and see what can be done.

I have added district level translation support as well,
If api changes are going to take time then there can be seprate PR, I am afraid of this PR getting outdated as well.
p.s. I'll be happy to make changes for that PR as well

@harshzalavadiya hey, I'm looking forward to merging this next! Can you fix those merge conflicts one last time, please? :)

Just now I found small bug I'll resolve it ASAP and then it will be ready for merge

@harshzalavadiya Sure, take your time :)

@jeremyphilemon Issue is fixed now, Just resolved last merge conflict in App.scss

authors: harshzalavadiya jeremyphilemon


text:
🛑 CoW Protocol - Docs is down

In ee25b8f, CoW Protocol - Docs (https://docs.cow.fi) was down:

HTTP code: 403
Response time: 93 ms

Resolved: CoW Protocol - Docs is back up in c9bf196.

repo: cowprotocol/uptime


text:
请问有没有新的支持CDN的安卓客户端？

通过修改影梭的v1.1.0a-apk已经在用，感觉不错。希望早日有支持CDN的客户端测试版可用。谢谢

Duplicate of 54

authors: coyove zhaodanyao

repo: coyove/goflyway


text:
Issue using MemGPT with AutoGen

When I try to run the sample code demonstrating how to use MemGPT with AutoGen, I get a runtime error:
"RuntimeError: asyncio.run() cannot be called from a running event loop".
I cannot seem to figure out what I am doing wrong.
Sample code: https://github.com/cpacker/MemGPT/discussions/65

Sorry if I am not smart.

See the new example introduced by #123, we did some refactoring that should have solved this.

@hframa which jupyter notebook are you referring to? We didn't publish any notebooks, just an example code snippet which is now also checked into the git repo here.
Or do you mean the example linked above works when you just run the python file, but fails when you try to take the code out into a Jupyter notebook? If that's the case, can you share the contents of the notebook eg via a google colab link so we can try to debug it?

Thank you, and sorry.
I think I messed up something on my part, which I cant seem to figure out.
Following is the link to the Jupyter Notebook: https://colab.research.google.com/drive/1boC1Ghsla8AISAy8nbgSWNZzX6xPLmgK?usp=sharing

can you open view access on the notebook?

authors: cpacker hframa vivi

repo: cpacker/MemGPT


text:
add coyote time for falling off ledges

add an on_ground_during_previous_frame flag, and a timer which starts when not is_on_ground, but on_ground_during_previoius_frame is true.
Don't transition to air until coyote time has elapsed.

Not enough time left to implement and troubleshoot this. There are more important bugs to worry about.


text:
Keep a high level changelog for each release

I was looking for a changelog to know what differences to expect (and possible changes I need to make in my tests) going from v3.6 to the upcoming v3.7, and I was disappointed to find your changelog just points to the Git commit history.
As someone not intimately immersed in the details of Cpputest, and just a user of the library, the raw Git commit log is not very informative: https://github.com/cpputest/cpputest/compare/v3.6...master
I know it's a little bit of extra work to keep a high level changelog, but I think the consumers of your tools would really appreciate and benefit from it. It would also help us understand the different features of your library, many of which seem to be undocumented.

How about that each of us who contributes a new feature, in the same way as we always have to submit tests to be considered for merging, we also have to add a suitable line to the change log.
That way, when it comes to a new release, we won't have to scratch our heads, or wade through gazillions of pull requests (shudder).
We have had a lot of very useful new features recently, and I am starting to lose track even of my own contributions, let alone those of others. Maybe the "release" change log doesn't need to contain every tiny bug fix. So we should have a detailed log, perhaps, that we are required to write in, and a user-oriented, abbreviated log, which @basvodde  updates with each release.

I'm a bit uncomfortable with updating the change log all the time as features don't always come in one piece but often come gradually. Also, I'm likely to forget it myself all the time :)
Besides, isn't that what we have version control for?

Just checking in to see if you would consider this again

Besides, isn't that what we have version control for?

I don't think so - consider this comment from a developer on my team who recently wanted to update the version of cpputest to see if it would help find a bug in our test suite:
"- There isn't a decent changelog, but we're ~700 commits behind, so let's just jump ahead."
I'll add "...and hope it works". It's really hard to tell from a 700 commit changelog if there were any API changes, and new CLI flags or features we might want to take advantage of, etc. I don't think you need to be militant about updating the changelog every commit, but every so often when you consider making a major or minor release, I think it's worth collecting all of the high-level changes in a concise format for your users.

@peplin I agree. We had loads of great new features added recently and if you asked me to list them I couldn't do it. Going through the commit history would be a daunting task - much easier to update the change log whenever a new feature is finished, or a bug fixed.

High level changelog is in the github releasing now

authors: arstrube basvodde peplin

repo: cpputest/cpputest


text:
CMake coverage report generation

As mentioned in #1139.
@basvodde I used gcovr instead of lcov as it's much easier to install and use. It can create coverage results, reports in various formats etc. in a single pass and provides support for configuration file. If the the lcov is still set, can migrate it back.
Should I change the make target to check_coverage as used in Makefile.am? Would keep it consistent.

Travis was unable to clone the repository!? :confused:

I might have overloaded it with my experimenting :)
I restarted the job.

Thanks, unfortunately git clone failed again.

Changing the Makefile.am is ok. Leaving it is also ok... at some point it will likely change then.

Great, thanks for merging. Feel free to rename the target, no preference from my side.
Btw. gcovr is simple enough so everyone can call it directly, no matter what build system is used.

authors: basvodde offa


text:
What is the state of Crafty in 2021?  (Is it abandoned?)

Can @starwed as the largest contributor answer please?

Well, I'm still alive at least.  :)
But, as the commit history (and lateness of this response) makes clear, haven't had time in a while to contribute or tend to crafty.  I think the last code I wrote was this POC of speeding up Crafty via compiled rust modules.
Maybe a glib answer, but ultimately as open source, it can't be truly abandoned per se by one person -- when I started working on Crafty, it was in a similar state.  I got a bit annoyed by various bugs and limitations, and set about fixing them.
If someone who has contributed to Crafty in the past wants to step up, I'll be glad to add them to the list of maintainers.  I'd also be glad to help folk if they want to fix or improve the codebase via PRs.  But I'm unlikely to be in a position to spend time actively investigating bug reports, etc.
Of course no one else might have the time or inclination for that, and that's also fine!  I'll wait a bit to see if anyone expresses interest, and if not add a note to the README indicating that the project currently lacks active contributors.

Thank you for your response!
On Mon, Nov 29, 2021 at 3:45 AM Tim Martin @.***> wrote:

Well, I'm still alive at least. :)
But, as the commit history (and lateness of this response) makes clear,
haven't had time in a while to contribute or tend to crafty. I think the
last code I wrote was this POC of speeding up Crafty via compiled rust
modules https://github.com/starwed/Crafty/tree/poc-wasm.
Maybe a glib answer, but ultimately as open source, it can't be truly
abandoned per se by one person -- when I started working on Crafty, it
was in a similar state. I got a bit annoyed by various bugs and
limitations, and set about fixing them.
If someone who has contributed to Crafty in the past wants to step up,
I'll be glad to add them to the list of maintainers. I'd also be glad to
help folk if they want to fix or improve the codebase via PRs. But I'm
unlikely to be in a position to spend time actively investigating bug
reports, etc.
Of course no one else might have the time or inclination for that, and
that's also fine! I'll wait a bit to see if anyone expresses interest, and
if not add a note to the README indicating that the project currently lacks
active contributors.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/craftyjs/Crafty/issues/1215#issuecomment-981241705,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACBHPTPZR62R36M6VJVOMEDUOLSNXANCNFSM5IKSYYQQ
.

@starwed I recently used Crafty to build a Game Rummy and also planning to build a new Game called Trinity. I have created an NFT of the Dev version
https://opensea.io/assets/0x495f947276749ce646f68ac8c248420045cb7b5e/65752281734232600592102686323841335515970524716795524261687884035767683514369
(It has a gameplay recording, the recording is the first recording after 9 test games once the FE/BE game engines were ready, Check it out).
I do want to maintain Crafty and I think the design is simple but sophisticated enough to build any arbitrary complex Game renderable via a browser and can be coded with relative ease. I have not actively maintained any open source project but I would like to take this responsibility, maybe starting as a contribution to fixing bugs or may feature improvements?

authors: 7aaa7 nekromoff starwed

repo: craftyjs/Crafty


text:
CrateDB: Make "CRATE SCHEMA" a no-op

About
Probably the quickest and smallest patch to resolve an error when connecting to CrateDB. Thanks again, @proddata.
InternalError_: line 1:8: no viable alternative at input 'CREATE SCHEMA'

References

GH-1
https://github.com/crate/crate/issues/14601

Backlog
Needs to be reworked to be provided on behalf of a dedicated dialect, instead of hacking the PostgreSQL adapter. Can be provided by a subsequent patch, the main goal is to get this going.

Closing this in favor of GH-3. Thanks, @proddata.

repo: crate-workbench/mage-ai


text:
Nested array storage supported/not-supported depending on statement.

CrateDB version
5.3
Problem description
Regression from 5.2. Looks like nested array is possible to store in a concrete way (insert from values) but is nt possible in some other ways.
Steps to Reproduce
create table t(a int) with (column_policy='dynamic')
looks like insert from values can store nested arrays in 5.3
insert into t(a, nest_arr) values (1, [[1,2,3]]);
INSERT OK, 1 row affected  (0.246 sec)

cr> select * from t;
+---+-------------+
| a | nest_arr    |
+---+-------------+
| 1 | [[1, 2, 3]] |

insert from sub-query cannot store nested array in 5.3
(but with different error message than 5.2 so it could be also improved)
insert into t(a, nest_arr) (select 1, [[1,2,3]] from sys.cluster);
SQLParseException[The type 'integer_array_array' of the insert source '[[1, 2, 3]]' is not convertible to the type 'bigint_array' of target column 'nest_arr']

Actual Result
by docs nested arrays storage is not supported.
https://crate.io/docs/crate/reference/en/5.3/general/ddl/data-types.html#nested-arrays

Nested arrays cannot be used directly in column definitions (i.e. ARRAY(ARRAY(DOUBLE)) is not accepted),

but there is at least one way to achieve that.
Expected Result
Either

really support nested array storage (insert from subquery should not fail) and update docs
make insert from values fail. And maybe improve error message for insert-from-subquery as well.

if go with 2, then this is behavior on 5.2:
cr> create table t(a int) with (column_policy='dynamic');
CREATE OK, 1 row affected  (1.606 sec)
cr> insert into t(a, nest_arr) values (1, [[1,2,3]]);
ElasticsearchParseException[nested arrays are not supported]
cr> insert into t(a, nest_arr) (select 1, [[1,2,3]] from sys.cluster);
INSERT OK, 0 rows affected  (0.016 sec)
cr> select * from t;
+---+
| a |
+---+
+---+
SELECT 0 rows in set (0.030 sec)

Fixed with https://github.com/crate/crate/pull/14324 and also created a issue to add support: https://github.com/crate/crate/issues/14328

authors: BaurzhanSakhariev mfussenegger

repo: crate/crate


text:
Maybe Problem in Where-Clause of Delete Statement?

In the WHERE clause of SELECT statements, terms can be exchanged. If I do the same in DELETE statements then I can see following behaviour in crate.io version "0.54.7".
First statement worked (TS is of type TIMESTAMP):
cr> DELETE FROM TestTable WHERE   TS < date_trunc('day', current_timestamp(0)-(10003600100));
DELETE OK, -1 rows affected (0.008 sec)
Second statement (with exchanged terms in where clause) failed:
cr> DELETE FROM TestTable WHERE    date_trunc('day', current_timestamp(0)-(10003600100)) > TS;
SQLActionException[io.crate.analyze.symbol.Reference cannot be cast to io.crate.analyze.symbol.Literal]

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/32367069-maybe-problem-in-where-clause-of-delete-statement?utm_campaign=plugin&utm_content=tracker%2F505659&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F505659&utm_medium=issues&utm_source=github).

Hi,
thanks for reporting the issue. It's already fixed in our master branch and i applied a fix for 0.54.* (https://github.com/crate/crate/pull/3393) now. The fix will be released with the next crate release.

authors: bogensberger githubmui


text:
fix: kill job on all participating nodes

if a node disconnects, all nodes receive a kill request if they participate
on a job context. This fixes an issue that could caused queries to hang if a
node disconnects.

@mfussenegger maybe you can take a 👀

Current coverage is 81.52% (diff: 93.93%)

No coverage report found for master at 1d8bce0.

Powered by Codecov. Last update 1d8bce0...8551cc6

authors: codecov-io mikethebeer


text:
release notes cluster checks

this adds the cluster checks docs for 1.1

#5105 should be merged before this one. and then this pr should be rebased against the release-notes-restructure story branch

Codecov Report

Merging #5135 into nomi/release-notes will increase coverage by 0.01%.
The diff coverage is n/a.

@@                   Coverage Diff                    @@
##             nomi/release-notes    #5135      +/-   ##
========================================================
+ Coverage                 82.44%   82.45%   +0.01%
- Complexity                10991    10999       +8
========================================================
  Files                      1330     1330
  Lines                     45008    45008
  Branches                   5654     5654
========================================================
+ Hits                      37105    37113       +8
+ Misses                     5257     5251       -6
+ Partials                   2646     2644       -2

Impacted Files
Coverage Δ
Complexity Δ

...n/java/io/crate/exceptions/JobKilledException.java
0% <0%> (-66.67%)
0% <0%> (-1%)

...ion/aggregation/impl/GeometricMeanAggregation.java
59.09% <0%> (-22.73%)
11% <0%> (ø)

...rc/main/java/io/crate/analyze/UnboundAnalyzer.java
75% <0%> (-15%)
2% <0%> (ø)

...a/io/crate/metadata/sys/SysSnapshotsTableInfo.java
82.85% <0%> (-5.72%)
6% <0%> (-1%)

...nce/sys/check/node/DiskWatermarkNodesSysCheck.java
66.66% <0%> (-3.71%)
7% <0%> (-1%)

...c/main/java/io/crate/exceptions/SQLExceptions.java
67.01% <0%> (-3.1%)
33% <0%> (-2%)

.../elasticsearch/action/bulk/BulkShardProcessor.java
74.44% <0%> (-1.86%)
46% <0%> (-2%)

...ql/src/main/java/io/crate/metadata/TableIdent.java
89.28% <0%> (-1.79%)
28% <0%> (-1%)

...io/crate/protocols/postgres/ConnectionContext.java
78.24% <0%> (-1.15%)
31% <0%> (ø)

...er/src/main/java/io/crate/sql/tree/AstVisitor.java
31.35% <0%> (-0.85%)
37% <0%> (-1%)

... and 16 more

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 0db6eaf...de7d4e4. Read the comment docs.

@matriv when we spoke in person you mentioned that there was somewhere in the docs main that could be linked through to the new release notes for 1.1. unfortunately I didn't write it down and I've been unable to find the section you pointed out to me

@nslater the cluster checks are here:
https://github.com/crate/crate/blob/master/blackbox/docs/sql/system.txt#L1168

authors: codecov-io matriv nslater


text:
[2.3] Remove the SubselectRewriter

The SubselectRewriter was a buggy (complex) component that was removed on master. This PR cherry picks the relevant changes in order to remove the SubselectRewriter.
Consequently, https://github.com/crate/crate/issues/7229 will be fixed in 2.3

This commit introduces a performance regression affecting JOINS
involving subqueries as the WHERE clause push-down, no longer happens
in all cases in the same way. There will be a follow-up to re-add this
using the LogicalPlan#tryOptimize functionality.

Shouldn't we also backport the follow up commits to avoid a performance regression?

@mfussenegger yep, good point!

I think https://github.com/crate/crate/commit/820cb9d76341f60d4709a991040c7eacb1e1556b might also be relevant.
Otherwise it's looking good.

authors: andreidan mfussenegger