Issues bringing up 200-node GCE cluster

I attempted to bring up a 200-node GCE cluster which is something that worked fairly reliably for me before (indeed, I've managed to bring up 1,000 node clusters that pass cluster validation before) but now this does not seem to work anymore. After the initial cluster validation failure I waited and re-tried but got no further. The step that fails is the enumeration of the minions (we've previously done some work to speed this up) and the actual error we see has its source in etcd.
Action item: investigate LIST MINIONS and etcd to debug performance.
Attempt 1 to check Docker on node kubernetes-minion-196 ... [working]
Attempt 1 to check Docker on node kubernetes-minion-197 ... [working]
Attempt 1 to check Docker on node kubernetes-minion-198 ... [working]
Attempt 1 to check Docker on node kubernetes-minion-199 ... [working]
Attempt 1 to check Docker on node kubernetes-minion-200 ... [working]

Kubernetes cluster is running.  The master is running at:

  https://<IP_ADDRESS>

The user name and password to use is located in ~/.kubernetes_auth.

... calling validate-cluster
Project: kubernetes-scale
Zone: asia-east1-b
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
F0203 14:01:25.284908   29117 get.go:143] 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes$ cluster/validate-cluster.sh
Project: kubernetes-scale
Zone: asia-east1-b
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions -o template -t {{range.items}}{{.id}}
{{end}}
F0203 14:15:33.088271    3206 get.go:143] 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]

Is this with etcd 2.0 or the old version?

satnam@kubernetes-master:/var/log$ etcd --version
etcd version 2.0.0

Creating a 100 node cluster got us a little further but there was an error about the monitoring pods not scheduling. Will check health otherwise.
Attempt 1 at checking Kubelet installation on node k100-minion-98 ... [working]
Attempt 1 at checking Kubelet installation on node k100-minion-99 ... [working]
Attempt 1 at checking Kubelet installation on node k100-minion-100 ... [working]
Cluster validation succeeded
... calling setup-monitoring-firewall
Setting up firewalls to Heapster based cluster monitoring.
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-scale/global/firewalls/k100-monitoring-heapster].
NAME                     NETWORK SRC_RANGES RULES                    SRC_TAGS TARGET_TAGS
k100-monitoring-heapster default <IP_ADDRESS>/0  tcp:80,tcp:8083,tcp:8086          k100-minion
waiting for monitoring pods to be scheduled.
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Monitoring pods failed to be scheduled!
... calling setup-logging-firewall
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-scale/global/firewalls/k100-fluentd-elasticsearch-logging].
NAME                               NETWORK SRC_RANGES RULES                      SRC_TAGS TARGET_TAGS
k100-fluentd-elasticsearch-logging default <IP_ADDRESS>/0  tcp:5601,tcp:9200,tcp:9300          k100-minion
waiting for logging services to be created by the master.
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get services -l name=kibana-logging -o template -t {{range.items}}{{.id}}{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get services -l name=elasticsearch-logging -o template -t {{range.items}}{{.id}}{{end}}

Cluster logs are ingested into Elasticsearch running at http://<IP_ADDRESS>:9200
Kibana logging dashboard will be available at http://<IP_ADDRESS>:5601

satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes$ cluster/kubectl.sh get pods
Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods
POD                                          IP                  CONTAINER(S)            IMAGE(S)                            HOST                                         LABELS                                   STATUS
elasticsearch-logging-controller-fplln                           elasticsearch-logging   dockerfile/elasticsearch            k100-minion-4.c.kubernetes-scale.internal/   name=elasticsearch-logging               Unknown
kibana-logging-controller-gziey                                  kibana-logging          kubernetes/kibana:1.0               k100-minion-1.c.kubernetes-scale.internal/   name=kibana-logging                      Unknown
monitoring-heapster-controller-oh43e                             heapster                kubernetes/heapster:v0.6            k100-minion-6.c.kubernetes-scale.internal/   name=heapster,uses=monitoring-influxdb   Unknown
monitoring-influx-grafana-controller-0133o                       influxdb                kubernetes/heapster_influxdb:v0.3   k100-minion-3.c.kubernetes-scale.internal/   name=influxGrafana                       Unknown
                                                                 grafana                 kubernetes/heapster_grafana:v0.3
skydns-ls6k1                                                     etcd                    quay.io/coreos/etcd:latest          k100-minion-4.c.kubernetes-scale.internal/   k8s-app=skydns                           Unknown
                                                                 kube2sky                kubernetes/kube2sky:1.0
                                                                 skydns                  kubernetes/skydns:2014-12-23-001

That etcd error is really tiresome - can we try to understand what it
really means and what to do when it happens?  Maybe engage the coreos folks
and see - is this something we should retry?  is it fatal?
On Tue, Feb 3, 2015 at 3:08 PM, Satnam Singh<EMAIL_ADDRESS>wrote:

satnam@kubernetes-master:/var/log$ etcd --version
etcd version 2.0.0
--
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/4078#issuecomment-72756074
.

+1. This is at the root of many failures. It is also intermittent: running a command again might succeed (e.g. get pods). Next week I am happy to devote some time to this because for me this is intricately tied up with scalability work. Until then, perhaps we should make a wrapper library for etcd which builds in retries and other resilience?

rule out etcd issue: etcd_server is running, and records related minions are created properly by using etcdctl
rule out disk issue too

From kube-apiserver.log, there are tons of 500
I0203 23:11:12.486678    5260 handlers.go:107] GET /api/v1beta1/pods?fields=Status.Host%3Dkubernetes-minion-40.c.kubernetes-scale.internal: (331.764µs) 500
goroutine 9550 [running]:
github.com/GoogleCloudPlatform/kubernetes/pkg/httplog.(*respLogger).WriteHeader(0xc20d6d18c0, 0x1f4)
        /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/httplog/log.go:182 +0x9a
github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver.writeJSON(0x1f4, 0x7f09776526a0, 0xc20801c5e0, 0x7f0977652868, 0xc208a54c00, 0x7f0977660568, 0xc20d6d18c0)
        /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver/apiserver.go:447 +0x232
github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver.errorJSON(0x7f0977656370, 0xc20b8e0b10, 0x7f09776526a0, 0xc20801c5e0, 0x7f0977660568, 0xc20d6d18c0)
        /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver/apiserver.go:454 +0xa3
github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver.(*RESTHandler).handleRESTStorage(0xc208130cc0, 0xc2081f7ab0, 0x1, 0x1, 0xc209dd40d0, 0x7f0977660568, 0xc20d6d18c0, 0x7f09776564c0, 0xc208
0e3820, 0x0, ...)
        /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver/resthandler.go:173 +0xbe9
github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver.(*RESTHandler).ServeHTTP(0xc208130cc0, 0x7f0977660568, 0xc20d6d18c0, 0xc209dd40d0)
        /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver/resthandler.go:56 +0x1f7
net/http.func·012(0x7f0977660568, 0xc20d6d18c0, 0xc209dd40d0)
        /usr/src/go/src/net/http/server.go:1297 +0xe1
net/http.HandlerFunc.ServeHTTP(0xc208170020, 0x7f0977660568, 0xc20d6d18c0, 0xc209dd40d0)
        /usr/src/go/src/net/http/server.go:1265 +0x41
github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver.func·001(0xc20b8e0750, 0xc2084fd9a0)
        /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver/a
E0203 23:11:12.502507    5260 errors.go:52] apiserver received an error that is not an api.Status: 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0
]
I0203 23:11:12.502673    5260 handlers.go:107] GET /api/v1beta1/services: (346.697µs) 500
goroutine 691658 [running]:
github.com/GoogleCloudPlatform/kubernetes/pkg/httplog.(*respLogger).WriteHeader(0xc20db621e0, 0x1f4)
        /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/httplog/log.go:182 +0x9a
github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver.writeJSON(0x1f4, 0x7f09776526a0, 0xc20801c5e0, 0x7f0977652868, 0xc208a54d00, 0x7f0977660568, 0xc20db621e0)
        /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver/apiserver.go:447 +0x232
github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver.errorJSON(0x7f0977656370, 0xc20b8e1260, 0x7f09776526a0, 0xc20801c5e0, 0x7f0977660568, 0xc20db621e0)
        /go/src/github.com/GoogleCloudPlatform/kubernetes/_output/dockerized/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver/apiserver.go:454 +0xa3
github.com/GoogleCloudPlatform/kubernetes/pkg/apiserver.(*RESTHandler).handleRESTStorage(0xc208130cc0, 0xc2081c7b30, 0x1, 0x1, 0xc20b8ee820, 0x7f0977660568, 0xc20db621e0, 0x7f0977656510, 0xc208
0eb8c0, 0x0, ...)

Dawn: is this from the 200-node cluster with master kubernetes-master or is it from the 100 node cluster with master k100-master? Thanks.

@satnam6502: From 200-node cluster. I haven't looked at 100 one yet.

Again, with a 50-node cluster.

Created [https://www.googleapis.com/compute/v1/projects/kubernetes-scale/global/firewalls/k50-monitoring-heapster].
NAME                    NETWORK SRC_RANGES RULES                    SRC_TAGS TARGET_TAGS
k50-monitoring-heapster default <IP_ADDRESS>/0  tcp:80,tcp:8083,tcp:8086          k50-minion
waiting for monitoring pods to be scheduled.
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}}
Monitoring pods failed to be scheduled!
... calling setup-logging-firewall
Created [https://www.googleapis.com/compute/v1/projects/kubernetes-scale/global/firewalls/k50-fluentd-elasticsearch-logging].
NAME                              NETWORK SRC_RANGES RULES                      SRC_TAGS TARGET_TAGS
k50-fluentd-elasticsearch-logging default <IP_ADDRESS>/0  tcp:5601,tcp:9200,tcp:9300          k50-minion
waiting for logging services to be created by the master.
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get services -l name=kibana-logging -o template -t {{range.items}}{{.id}}{{end}}
Running: cluster/../cluster/gce/../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get services -l name=elasticsearch-logging -o template -t {{range.items}}{{.id}}{{end}}

Cluster logs are ingested into Elasticsearch running at http://<IP_ADDRESS>:9200
Kibana logging dashboard will be available at http://<IP_ADDRESS>:5601

Done
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes$ cluster/kubectl.sh get pods
Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods
POD                                          IP                  CONTAINER(S)            IMAGE(S)                            HOST                                        LABELS                                   STATUS
elasticsearch-logging-controller-fplln                           elasticsearch-logging   dockerfile/elasticsearch            k50-minion-6.c.kubernetes-scale.internal/   name=elasticsearch-logging               Unknown
kibana-logging-controller-gziey                                  kibana-logging          kubernetes/kibana:1.0               k50-minion-6.c.kubernetes-scale.internal/   name=kibana-logging                      Unknown
monitoring-heapster-controller-0133o                             heapster                kubernetes/heapster:v0.6            k50-minion-4.c.kubernetes-scale.internal/   name=heapster,uses=monitoring-influxdb   Unknown
monitoring-influx-grafana-controller-ls6k1                       influxdb                kubernetes/heapster_influxdb:v0.3   k50-minion-4.c.kubernetes-scale.internal/   name=influxGrafana                       Unknown
                                                                 grafana                 kubernetes/heapster_grafana:v0.3
skydns-oh43e                                                     etcd                    quay.io/coreos/etcd:latest          k50-minion-4.c.kubernetes-scale.internal/   k8s-app=skydns                           Unknown
                                                                 kube2sky                kubernetes/kube2sky:1.0
                                                                 skydns                  kubernetes/skydns:2014-12-23-001
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes$ cluster/kubectl.sh get minions
Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get minions
NAME                                        LABELS              STATUS
k50-minion-1.c.kubernetes-scale.internal    <none>              Ready
k50-minion-10.c.kubernetes-scale.internal   <none>              Ready
k50-minion-11.c.kubernetes-scale.internal   <none>              Ready
k50-minion-12.c.kubernetes-scale.internal   <none>              Ready
k50-minion-13.c.kubernetes-scale.internal   <none>              Ready
k50-minion-14.c.kubernetes-scale.internal   <none>              Ready
k50-minion-15.c.kubernetes-scale.internal   <none>              Ready
k50-minion-16.c.kubernetes-scale.internal   <none>              Ready
k50-minion-17.c.kubernetes-scale.internal   <none>              Ready
k50-minion-18.c.kubernetes-scale.internal   <none>              Ready
k50-minion-19.c.kubernetes-scale.internal   <none>              Ready
k50-minion-2.c.kubernetes-scale.internal    <none>              Ready
k50-minion-20.c.kubernetes-scale.internal   <none>              Ready
k50-minion-21.c.kubernetes-scale.internal   <none>              Ready
k50-minion-22.c.kubernetes-scale.internal   <none>              Ready
k50-minion-23.c.kubernetes-scale.internal   <none>              Ready
k50-minion-24.c.kubernetes-scale.internal   <none>              Ready
k50-minion-25.c.kubernetes-scale.internal   <none>              Ready
k50-minion-26.c.kubernetes-scale.internal   <none>              Ready
k50-minion-27.c.kubernetes-scale.internal   <none>              Ready
k50-minion-28.c.kubernetes-scale.internal   <none>              Ready
k50-minion-29.c.kubernetes-scale.internal   <none>              Ready
k50-minion-3.c.kubernetes-scale.internal    <none>              Ready
k50-minion-30.c.kubernetes-scale.internal   <none>              Ready
k50-minion-31.c.kubernetes-scale.internal   <none>              Ready
k50-minion-32.c.kubernetes-scale.internal   <none>              Ready
k50-minion-33.c.kubernetes-scale.internal   <none>              Ready
k50-minion-34.c.kubernetes-scale.internal   <none>              Ready
k50-minion-35.c.kubernetes-scale.internal   <none>              Ready
k50-minion-36.c.kubernetes-scale.internal   <none>              Ready
k50-minion-37.c.kubernetes-scale.internal   <none>              Ready
k50-minion-38.c.kubernetes-scale.internal   <none>              Ready
k50-minion-39.c.kubernetes-scale.internal   <none>              Ready
k50-minion-4.c.kubernetes-scale.internal    <none>              Ready
k50-minion-40.c.kubernetes-scale.internal   <none>              Ready
k50-minion-41.c.kubernetes-scale.internal   <none>              Ready
k50-minion-42.c.kubernetes-scale.internal   <none>              Ready
k50-minion-43.c.kubernetes-scale.internal   <none>              Ready
k50-minion-44.c.kubernetes-scale.internal   <none>              Ready
k50-minion-45.c.kubernetes-scale.internal   <none>              Ready
k50-minion-46.c.kubernetes-scale.internal   <none>              Ready
k50-minion-47.c.kubernetes-scale.internal   <none>              Ready
k50-minion-48.c.kubernetes-scale.internal   <none>              Ready
k50-minion-49.c.kubernetes-scale.internal   <none>              Ready
k50-minion-5.c.kubernetes-scale.internal    <none>              Ready
k50-minion-50.c.kubernetes-scale.internal   <none>              Ready
k50-minion-6.c.kubernetes-scale.internal    <none>              Ready
k50-minion-7.c.kubernetes-scale.internal    <none>              Ready
k50-minion-8.c.kubernetes-scale.internal    <none>              Ready
k50-minion-9.c.kubernetes-scale.internal    <none>              Ready

kubectl.sh get minions seems fast (so cache is working). However, the pods don't seem to transition out of the Unknown state: even with a 50 node cluster.

what is the output of kubectl describe pods ? Noticed from the logs pasted above, there is an error related to scheduling:
Monitoring pods failed to be scheduled!

50-node cluster doesn't have 500 stacktrace in kube-apiserver.log pasted above.
checked etcd again, no crash, no disk issue
Taking pod monitoring-heapster-controller as an example, boundpods record is created properly under /registry/nodes/k50-minion-4/boundpods
checked kubelet, Pod is running happily

root@k50-minion-4:/var/log# docker ps -a |grep controller-0133o
00a5b661a4e6        kubernetes/heapster:v0.6               "/run.sh"              35 minutes ago      Up 35 minutes
                            k8s_heapster.ae7eda7c_monitoring-heapster-controller-0133o.default.api_675004db-ac03-11e4-a607-42010af0ccba_1ae30c2a
9fa98f6038df        kubernetes/pause:go                    "/pause"               37 minutes ago      Up 37 minutes
                            k8s_POD.332bdea_monitoring-heapster-controller-0133o.default.api_675004db-ac03-11e4-a607-42010af0ccba_b77eaf62

Please re-run kubectl get pods to see if you still observe above issue?

For the 50-node cluster:
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes$ cluster/kubectl.sh get pods
Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods
POD                                          IP                  CONTAINER(S)            IMAGE(S)                            HOST                                        LABELS                                   STATUS
elasticsearch-logging-controller-fplln                           elasticsearch-logging   dockerfile/elasticsearch            k50-minion-6.c.kubernetes-scale.internal/   name=elasticsearch-logging               Unknown
kibana-logging-controller-gziey                                  kibana-logging          kubernetes/kibana:1.0               k50-minion-6.c.kubernetes-scale.internal/   name=kibana-logging                      Unknown
monitoring-heapster-controller-0133o                             heapster                kubernetes/heapster:v0.6            k50-minion-4.c.kubernetes-scale.internal/   name=heapster,uses=monitoring-influxdb   Unknown
monitoring-influx-grafana-controller-ls6k1                       influxdb                kubernetes/heapster_influxdb:v0.3   k50-minion-4.c.kubernetes-scale.internal/   name=influxGrafana                       Unknown
                                                                 grafana                 kubernetes/heapster_grafana:v0.3
skydns-oh43e                                                     etcd                    quay.io/coreos/etcd:latest          k50-minion-4.c.kubernetes-scale.internal/   k8s-app=skydns                           Unknown
                                                                 kube2sky                kubernetes/kube2sky:1.0
                                                                 skydns                  kubernetes/skydns:2014-12-23-001
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes$ cluster/kubectl.sh describe pods monitoring-heapster-controller-0133o
Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl describe pods monitoring-heapster-controller-0133o
Name:                           monitoring-heapster-controller-0133o
Image(s):                       kubernetes/heapster:v0.6
Host:                           k50-minion-4.c.kubernetes-scale.internal/
Labels:                         name=heapster,uses=monitoring-influxdb
Status:                         Unknown
Replication Controllers:        monitoring-heapster-controller (1/1 replicas created)
Events:
Time                            From                                                    SubobjectPath                           Reason                  Message
Wed, 04 Feb 2015 00:18:54 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:18:55 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:18:57 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:19:01 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:19:09 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:19:25 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:19:57 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:20:46 +0000 {scheduler }                                                                                scheduled               Successfully assigned monitoring-heapster-controller-0133o to k50-minion-4.c.kubernetes-scale.internal
Wed, 04 Feb 2015 00:22:00 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      implicitly required container POD       pulled                  Successfully pulled image "kubernetes/pause:latest"
Wed, 04 Feb 2015 00:22:00 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      implicitly required container POD       created                 Created with docker id 9fa98f6038dfdaa04b46c8521c7ce7bdcf4037e0970607f86e03ba3f741a4d87
Wed, 04 Feb 2015 00:22:01 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      implicitly required container POD       started                 Started with docker id 9fa98f6038dfdaa04b46c8521c7ce7bdcf4037e0970607f86e03ba3f741a4d87
Wed, 04 Feb 2015 00:24:19 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      spec.containers{heapster}               pulled                  Successfully pulled image "kubernetes/heapster:v0.6"
Wed, 04 Feb 2015 00:24:19 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      spec.containers{heapster}               created                 Created with docker id 00a5b661a4e6398107fe68347dd0705d67fd7f5a46d33a668fcbe085ac740309
Wed, 04 Feb 2015 00:24:19 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      spec.containers{heapster}               started                 Started with docker id 00a5b661a4e6398107fe68347dd0705d67fd7f5a46d33a668fcbe085ac740309

satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes$ cluster/kubectl.sh describe pods monitoring-influx-grafana-controller-ls6k1
Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl describe pods monitoring-influx-grafana-controller-ls6k1
Name:                           monitoring-influx-grafana-controller-ls6k1
Image(s):                       kubernetes/heapster_influxdb:v0.3,kubernetes/heapster_grafana:v0.3
Host:                           k50-minion-4.c.kubernetes-scale.internal/
Labels:                         name=influxGrafana
Status:                         Unknown
Replication Controllers:        monitoring-influx-grafana-controller (1/1 replicas created)
Events:
Time                            From                                                    SubobjectPath                           Reason                  Message
Wed, 04 Feb 2015 00:18:54 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:18:55 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:18:57 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:19:01 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:19:09 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:19:25 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:19:57 +0000 {scheduler }                                                                                failedScheduling        Error scheduling: no minions available to schedule pods
Wed, 04 Feb 2015 00:20:46 +0000 {scheduler }                                                                                scheduled               Successfully assigned monitoring-influx-grafana-controller-ls6k1 to k50-minion-4.c.kubernetes-scale.internal
Wed, 04 Feb 2015 00:22:00 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      implicitly required container POD       pulled                  Successfully pulled image "kubernetes/pause:latest"
Wed, 04 Feb 2015 00:22:01 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      implicitly required container POD       started                 Started with docker id c938c536c2dfd8f1800bf267e4a37e4b8bd271102720862925cf19adf1d86c4c
Wed, 04 Feb 2015 00:22:01 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      implicitly required container POD       created                 Created with docker id c938c536c2dfd8f1800bf267e4a37e4b8bd271102720862925cf19adf1d86c4c
Wed, 04 Feb 2015 00:24:13 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      spec.containers{influxdb}               pulled                  Successfully pulled image "kubernetes/heapster_influxdb:v0.3"
Wed, 04 Feb 2015 00:24:14 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      spec.containers{influxdb}               started                 Started with docker id 20759f682ebc317c5b2bf6866840bb201bf703bfc6add73cca4a3a7626c03172
Wed, 04 Feb 2015 00:24:14 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      spec.containers{influxdb}               created                 Created with docker id 20759f682ebc317c5b2bf6866840bb201bf703bfc6add73cca4a3a7626c03172
Wed, 04 Feb 2015 00:26:09 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      spec.containers{grafana}                pulled                  Successfully pulled image "kubernetes/heapster_grafana:v0.3"
Wed, 04 Feb 2015 00:26:09 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      spec.containers{grafana}                created                 Created with docker id d4ca55abf6b1ff7b76c84fe5600085b20877c9a0edc26836ba5c4e93d6c35b64
Wed, 04 Feb 2015 00:26:09 +0000 {kubelet k50-minion-4.c.kubernetes-scale.internal}      spec.containers{grafana}                started                 Started with docker id d4ca55abf6b1ff7b76c84fe5600085b20877c9a0edc26836ba5c4e93d6c35b64

From the latest output of kubectl describe, I think 50-nodes cluster should work as intended. Here is the hyperthesis I have: When you run kubectl get pods, nodes' status is just changed to READY, so that scheduler couldn't schedule pods.

So the pods that were created at first are still Unknown but pods I launched later seem to have gone into the Running state (although the service is not working yet).
$../../../cluster/kubectl.sh get pods
Running: ../../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get pods
POD                                          IP                  CONTAINER(S)            IMAGE(S)                            HOST                                                        LABELS                                   STATUS
elasticsearch-logging-controller-fplln                           elasticsearch-logging   dockerfile/elasticsearch            k50-minion-6.c.kubernetes-scale.internal/                   name=elasticsearch-logging               Unknown
kibana-logging-controller-gziey                                  kibana-logging          kubernetes/kibana:1.0               k50-minion-6.c.kubernetes-scale.internal/                   name=kibana-logging                      Unknown
monitoring-heapster-controller-0133o                             heapster                kubernetes/heapster:v0.6            k50-minion-4.c.kubernetes-scale.internal/                   name=heapster,uses=monitoring-influxdb   Unknown
monitoring-influx-grafana-controller-ls6k1                       influxdb                kubernetes/heapster_influxdb:v0.3   k50-minion-4.c.kubernetes-scale.internal/                   name=influxGrafana                       Unknown
                                                                 grafana                 kubernetes/heapster_grafana:v0.3
serve-hostnames-02qp4                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-27.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-14m58                        <IP_ADDRESS>          serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-5.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-182tv                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-16.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-1gypq                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-30.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-26873                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-36.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-29g6u                        <IP_ADDRESS>          serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-2.c.kubernetes-scale.internal/<IP_ADDRESS>     name=serve-hostnames                     Running
serve-hostnames-2nrtl                        <IP_ADDRESS>          serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-9.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-2plmk                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-21.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-40noe                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-22.c.kubernetes-scale.internal/<IP_ADDRESS>     name=serve-hostnames                     Running
serve-hostnames-4s9mi                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-43.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-51wgg                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-17.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-5m1zc                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-18.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-5v48c                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-32.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-7kq8u                        <IP_ADDRESS>          serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-10.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-9gvmk                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-41.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-apz01                        <IP_ADDRESS>          serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-1.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-ca0qm                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-20.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-cegta                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-14.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-ckjdw                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-23.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-ckn42                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-28.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-dbfhf                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-40.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-ehq23                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-15.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-eql4y                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-13.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-f0fyy                        <IP_ADDRESS>          serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-7.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-gb50a                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-39.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-gfw5j                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-46.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-h3x9k                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-47.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-hh2gd                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-34.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-i7hvs                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-50.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-ilbb7                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-24.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-ir0xc                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-31.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-jmxbo                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-37.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-jzjpe                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-48.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-kjqd6                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-44.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-mhlnm                        <IP_ADDRESS>          serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-8.c.kubernetes-scale.internal/<IP_ADDRESS>     name=serve-hostnames                     Running
serve-hostnames-nxnds                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-35.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-nyxxv                        <IP_ADDRESS>          serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-3.c.kubernetes-scale.internal/<IP_ADDRESS>     name=serve-hostnames                     Running
serve-hostnames-pjzb3                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-42.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-sb5qi                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-38.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-ta0op                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-11.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-unlpf                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-12.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-uxshy                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-33.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-v5drx                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-29.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-wn1dx                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-25.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-xuc9u                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-27.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-y9eqi                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-22.c.kubernetes-scale.internal/<IP_ADDRESS>     name=serve-hostnames                     Running
serve-hostnames-yp7fy                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-26.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-zi4hx                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-19.c.kubernetes-scale.internal/<IP_ADDRESS>    name=serve-hostnames                     Running
serve-hostnames-zicap                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-49.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
serve-hostnames-zwk1b                        <IP_ADDRESS>         serve-hostname          kubernetes/serve_hostname:1.1       k50-minion-45.c.kubernetes-scale.internal/<IP_ADDRESS>   name=serve-hostnames                     Running
skydns-oh43e                                                     etcd                    quay.io/coreos/etcd:latest          k50-minion-4.c.kubernetes-scale.internal/                   k8s-app=skydns                           Unknown
                                                                 kube2sky                kubernetes/kube2sky:1.0
                                                                 skydns                  kubernetes/skydns:2014-12-23-001
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes/test/scalability/serve_hostnames$ ../../../cluster/kubectl.sh get replicationControllers
Running: ../../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get replicationControllers
CONTROLLER                             CONTAINER(S)            IMAGE(S)                            SELECTOR                     REPLICAS
elasticsearch-logging-controller       elasticsearch-logging   dockerfile/elasticsearch            name=elasticsearch-logging   1
kibana-logging-controller              kibana-logging          kubernetes/kibana:1.0               name=kibana-logging          1
monitoring-heapster-controller         heapster                kubernetes/heapster:v0.6            name=heapster                1
monitoring-influx-grafana-controller   influxdb                kubernetes/heapster_influxdb:v0.3   name=influxGrafana           1
                                       grafana                 kubernetes/heapster_grafana:v0.3
serve-hostnames                        serve-hostname          kubernetes/serve_hostname:1.1       name=serve-hostnames         50
skydns                                 etcd                    quay.io/coreos/etcd:latest          k8s-app=skydns               1
                                       kube2sky                kubernetes/kube2sky:1.0
                                       skydns                  kubernetes/skydns:2014-12-23-001
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes/test/scalability/serve_hostnames$ ../../../cluster/kubectl.sh get services
Running: ../../../cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get services
NAME                    LABELS                                    SELECTOR                     IP                  PORT
elasticsearch-logging   name=elasticsearch-logging                name=elasticsearch-logging   <IP_ADDRESS>         9200
kibana-logging          name=kibana-logging                       name=kibana-logging          <IP_ADDRESS>          5601
kubernetes              component=apiserver,provider=kubernetes   <none>                       <IP_ADDRESS>            443
kubernetes-ro           component=apiserver,provider=kubernetes   <none>                       <IP_ADDRESS>            80
monitoring-grafana      <none>                                    name=influxGrafana           <IP_ADDRESS>          80
monitoring-heapster     <none>                                    name=heapster                <IP_ADDRESS>        80
monitoring-influxdb     <none>                                    name=influxGrafana           <IP_ADDRESS>          80
serve-hostnames         name=serve-hostnames                      name=serve-hostnames         <IP_ADDRESS>         9500
skydns                  k8s-app=skydns                            k8s-app=skydns               <IP_ADDRESS>           53
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes/test/scalability/serve_hostnames$ make net
gcloud compute forwarding-rules --project kubernetes-scale describe --region asia-east1 serve-hostnames
IPAddress: <IP_ADDRESS>
IPProtocol: TCP
creationTimestamp: '2015-02-03T17:20:59.788-08:00'
id: '3940834679997910829'
kind: compute#forwardingRule
name: serve-hostnames
portRange: 9500-9500
region: https://www.googleapis.com/compute/v1/projects/kubernetes-scale/regions/asia-east1
selfLink: https://www.googleapis.com/compute/v1/projects/kubernetes-scale/regions/asia-east1/forwardingRules/serve-hostnames
target: https://www.googleapis.com/compute/v1/projects/kubernetes-scale/regions/asia-east1/targetPools/serve-hostnames
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes/test/scalability/serve_hostnames$ curl <IP_ADDRESS>:9500
curl: (7) Failed to connect to <IP_ADDRESS> port 9500: Connection refused

Looking at a specific instance of serve_hostname via the service the right thing seems to be happening:
root@k50-minion-6:/home/satnam# docker exec -ti 30dca480436b bash
$ curl <IP_ADDRESS>:9500
serve-hostnames-f0fyy$  curl <IP_ADDRESS>:9500
serve-hostnames-ir0xc$  curl <IP_ADDRESS>:9500
serve-hostnames-gfw5j

Although the services does not seem to be reachable via its external IP.
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes/test/scalability/serve_hostnames$ make net
gcloud compute forwarding-rules --project kubernetes-scale describe --region asia-east1 serve-hostnames
IPAddress: <IP_ADDRESS>
IPProtocol: TCP
creationTimestamp: '2015-02-03T17:20:59.788-08:00'
id: '3940834679997910829'
kind: compute#forwardingRule
name: serve-hostnames
portRange: 9500-9500
region: https://www.googleapis.com/compute/v1/projects/kubernetes-scale/regions/asia-east1
selfLink: https://www.googleapis.com/compute/v1/projects/kubernetes-scale/regions/asia-east1/forwardingRules/serve-hostnames
target: https://www.googleapis.com/compute/v1/projects/kubernetes-scale/regions/asia-east1/targetPools/serve-hostnames
satnam@satnam-linux:~/gocode/src/github.com/GoogleCloudPlatform/kubernetes/test/scalability/serve_hostnames$ curl <IP_ADDRESS>:9500
curl: (7) Failed to connect to <IP_ADDRESS> port 9500: Connection refused

Looking into it (default firewall is set up for tcp 9500).

Does the Unknown state only for those built-in pods?  If so, it's likely we have a race in cluster bootstrapping between scheduler and node controller, similar to what @dchen1107 suggested.  Looking at scheduler code, seems it doesn't try to reschedule the failed pods.  Can you check controller-manager log and compare the timestamp with scheduler to rule out the possibility (or hopefully found the problem)? I don't have access to the large cluster unfortunately.

Well those pods are just regular pods that are kicked off by the addons process that @zmerlynn added so there is nothing that special about most of them (unlike the pods launched from manifest files). I'll poke around the logs when I get a moment -- still trying to debug why I can't get the external IP to work. The create services call did crash with an unhelpful error :-)

You can check if there was anything weird about the startup by checking the
/var/log/kube-addons.log on the master.
On Tue, Feb 3, 2015 at 6:23 PM, Satnam Singh<EMAIL_ADDRESS>wrote:

Well those pods are just regular pods that are kicked off by the addons
process that @zmerlynn https://github.com/zmerlynn added so there is
nothing that special about most of them (unlike the pods launched from
manifest files). I'll poke around the logs when I get a moment -- still
trying to debug why I can't get the external IP to work. The create
services call did crash with an unhelpful error :-)
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/4078#issuecomment-72778634
.

See also #4095

I can now contact the service using the external IP and get a valid response. Perhaps this bug needs to be renamed -- but the add ons don't seem to work -- at least Elasticsearch and Kibana are not accessible via their external IPs.

When I dial up the replicas from 100 to 1,000 I sometimes get this error when I try to list any kind of resources: 501: All the given peers are not reachable (Tried to connect to each peer twice and failed) [0]

I am going to close this issue and do more investigation early next week and file more specific issues.


Error: The terraform-provider-snowflake_v0.81.0 plugin crashed!

Terraform CLI and Provider Versions
Terraform 1.5.7
Provider 0.81.0
Terraform Configuration
terraform {
  backend "local" {
    path = "terraform.tfstate"
  }

required_providers {
    snowflake = {
      source  = "Snowflake-Labs/snowflake"
      version = "~> 0.81"
    }
  }
}

import {
  to = snowflake_database.staging_db
  id = "STAGING"
}

import {
  to = snowflake_schema.staging_common
  id = "STAGING.COMMON"
}

resource "snowflake_database" "staging_db" {
  provider     = snowflake.sysadmin
  name         = "STAGING"
  is_transient = false
}

resource "snowflake_schema" "staging_common" {
  provider     = snowflake.sysadmin
  database     = snowflake_database.staging_db.name
  name         = "COMMON"
  is_managed   = true
  is_transient = false
}

Expected Behavior
Already existing schema should be imported correctly. For the database it worked fine.
Actual Behavior
Stack trace from the terraform-provider-snowflake_v0.81.0 plugin:
panic: interface conversion: sdk.ObjectIdentifier is sdk.AccountObjectIdentifier, not sdk.DatabaseObjectIdentifier
goroutine 37 [running]:
github.com/Snowflake-Labs/terraform-provider-snowflake/pkg/resources.ReadSchema(0x14000f90300, {0x103f2c820?, 0x14000becc30?})
github.com/Snowflake-Labs/terraform-provider-snowflake/pkg/resources/schema.go:108 +0x780
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).read(0x103f6e018?, {0x103f6e018?, 0x14000baf710?}, 0xd?, {0x103f2c820?, 0x14000becc30?})
github.com/hashicorp/terraform-plugin-sdk/v2@v2.30.0/helper/schema/resource.go:783 +0x134
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).RefreshWithoutUpgrade(0x14000b19b20, {0x103f6e018, 0x14000baf710}, 0x140008565b0, {0x103f2c820, 0x14000becc30})
github.com/hashicorp/terraform-plugin-sdk/v2@v2.30.0/helper/schema/resource.go:1089 +0x430
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadResource(0x14000ab8210, {0x103f6e018?, 0x14000baf4d0?}, 0x14000055b80)
github.com/hashicorp/terraform-plugin-sdk/v2@v2.30.0/helper/schema/grpc_provider.go:661 +0x3e4
github.com/hashicorp/terraform-plugin-mux/tf5to6server.v5tov6Server.ReadResource({{0x103f82c78?, 0x14000ab8210?}}, {0x103f6e018?, 0x14000baf4d0?}, 0x14000055980?)
github.com/hashicorp/terraform-plugin-mux@v0.12.0/tf5to6server/tf5to6server.go:119 +0x228
github.com/hashicorp/terraform-plugin-mux/tf6muxserver.(*muxServer).ReadResource(0x103f6e050?, {0x103f6e018?, 0x14000baec60?}, 0x14000055980)
github.com/hashicorp/terraform-plugin-mux@v0.12.0/tf6muxserver/mux_server_ReadResource.go:35 +0x184
github.com/hashicorp/terraform-plugin-go/tfprotov6/tf6server.(*server).ReadResource(0x140008ebc20, {0x103f6e018?, 0x14000bae480?}, 0x14000ab4e40)
github.com/hashicorp/terraform-plugin-go@v0.19.1/tfprotov6/tf6server/server.go:787 +0x390
github.com/hashicorp/terraform-plugin-go/tfprotov6/internal/tfplugin6._Provider_ReadResource_Handler({0x103ed3300?, 0x140008ebc20}, {0x103f6e018, 0x14000bae480}, 0x14000f90000, 0x0)
github.com/hashicorp/terraform-plugin-go@v0.19.1/tfprotov6/internal/tfplugin6/tfplugin6_grpc.pb.go:431 +0x164
google.golang.org/grpc.(*Server).processUnaryRPC(0x140000ccd20, {0x103f6e018, 0x14000bae3f0}, {0x103f7e300, 0x14000602820}, 0x1400056c120, 0x14000baf5c0, 0x104dcea08, 0x0)
google.golang.org/grpc@v1.59.0/server.go:1343 +0xb8c
google.golang.org/grpc.(*Server).handleStream(0x140000ccd20, {0x103f7e300, 0x14000602820}, 0x1400056c120)
google.golang.org/grpc@v1.59.0/server.go:1737 +0x990
google.golang.org/grpc.(*Server).serveStreams.func1.1()
google.golang.org/grpc@v1.59.0/server.go:986 +0x88
created by google.golang.org/grpc.(*Server).serveStreams.func1 in goroutine 22
google.golang.org/grpc@v1.59.0/server.go:997 +0x160
Error: The terraform-provider-snowflake_v0.81.0 plugin crashed!
This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.
Steps to Reproduce

terraform apply or terraform plan

How much impact is this issue causing?
High
Logs
No response
Additional Information
No response

Hey @juliankeppel. Thanks for reporting the issue.
Could you please try the ID conforming with the docs: https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/schema#import? (in this case "STAGING|COMMON")

@sfc-gh-asawicki Oh yes, I'm sorry. I overlooked that and it's a little bit unintuitive. But I'm sure it has it's reasons!
Thank you for this very quick response!


1.6.2 patch release

We have a couple of fixes in the master branch that is not yet available in a public release yet. Following is a list of commits/PRs that are pending for being backported. If you have some other commits in mind please let me know in the comments.

To be backported

[x] 8ba4722d0 * Remove pyarrow workaround. (#7884)
[x] db80671d6 * Fix monotone constraint with tuple input. (#7891)
[x] d314680a1 * Verify shared object version at load. (#7928)
[x] 8f8bd8147 * Fix LTR with weighted Quantile DMatrix. (#7975)
[x] dcaf58047 * Fix Python package source install. (#8036)
[ ] 579ab23b1 * Check cudf lazily (#8084)
[x] 5156be0f4 * Limit max_depth to 30 for GPU. (#8098)
[x] 2cba1d9fc * Fix compatibility with latest cupy. (#8129)
[x] https://github.com/dmlc/xgboost/pull/8018
[ ] https://github.com/dmlc/xgboost/pull/8149

Optional

These are optional and will be backported if it blocks the CI.

[ ] d285d6ba2 * Reduce regularization in GPU gblinear test. (#8010)
[ ] 4a87ea49b * Reduce regularization for CPU gblinear. (#8013)
[ ] f24bfc768 * Bump R cache version. (#8044)
[ ] a5bc8e2c6 * Fix mypy error with the latest dask. (#8052)
[x] 895962283 * [dask] Use an invalid port for test. (#8064)
[ ] 36cf979b8 * [CI] Fix S3 uploads (#8069)
[ ] 0ce80b7bc * Mitigate flaky GPU test. (#8078)
[x] e44a08262 * [jvm-packages] update nccl version to 2.12.12-1 (#8015)
[x] bcc8679a0 * Update CUDA docker image and NCCL. (#8139) (need jvm)

Can you add https://github.com/dmlc/xgboost/pull/8149?

@natmod Thanks, will backport it as well.

Will make the Python release once all backports are merged. (likely tomorrow).

Python packages are uploaded to pypi @hcho3 Would you like to help upload the jvm packages?

@trivialfis The JVM packages are now up.

Great. I will close the issue now since there's no fix for cran package.

Are there any estimates perhaps for #8084?


fix(Charts): Set max row limit + removed the option to use an empty row limit value

SUMMARY

Can no longer clear/remove the row limit
New validator that checks if a value is larger than a given input

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Before:

After:

This looks great @CorbinBullard!


Update README.md

Hi, the readme has changed since, please open a new PR according to the Contributing section of the repository, thanks.


Static images not found

Hi, I'm trying to use your plugin and it looks pretty good, I just have one issue: my static images are deleted. The /public/ dir has no /static/ subdir after building.
If I try to launch gatsby build --prefix-paths I get the following error which seems related:
failed Building production JavaScript and CSS bundles - 23.500s

 ERROR #98123  WEBPACK

Generating JavaScript bundles failed

Can't resolve '../../public/static/d/2612610553.json' in '/Users/corentinsmith/projects/dashdoc-static-website/src/hooks'

I'm investigating but it looks like it's not linked to the use of this plugin


[enhance] Add enhenced SE

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation
Add Enhance SE-layer to support both Regnet, Efficientnet and RepVGG.
Modification
add base_channels
mmcls/models/utils/se_layer.py
BC-breaking (Optional)
No.
Use cases (Optional)
If this PR introduces a new feature, it is better to list some use cases here and update the documentation.
Checklist
Before PR:

[ ] Pre-commit or other linting tools are used to fix the potential lint issues.
[ ] Bug fixes are fully covered by unit tests, the case that causes the bug should be added in the unit tests.
[ ] The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
[ ] The documentation has been modified accordingly, like docstring or example tutorials.

After PR:

[ ] If the modification has potential influence on downstream or other related projects, this PR should be tested with those projects, like MMDet or MMSeg.
[ ] CLA has been signed and all committers have signed the CLA in this PR.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: Ezra-Yu:x: yuzhaohuiyuzhaohui seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


add availableLanguage only if procurementMethodType not competitiveDialogueEU

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Це готовий пул-реквест? Чи будуть ще коміти?

Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable

Готовий.

Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable

Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable


getTile unit tests

Critical information about this issue
This issue should not cover testing of making HTTP request, that kind of test will be made later if viable.
This issue is dedicated to writing unit tests for the getTile functionality. In the future, we will also set up HTTP error testing if we can figure that out, but this will happen a bit further down the line. Cecilia will research if/how it's feasible to make HTTP request tests before we add it as an actual issue and start implementing this.
Parent issue: #43

The getTile functionality has been refactored, and a lot of the functionality has been moved or doesn't exist anymore. I'm closing this issue based on that.


Introduce Key attestation feature

This change introduces a new feature called Key attestation. This feature allows customers to extract certificates and attestation blob(s) to validate that a given key has been created within the Hardware security module. In case of a symmetric key, only private key portion attestation blob is returned whereas in case of an asymmetric key, the public and private key portion attestation blobs are returned. This feature does not return the private key, only the attestation of private key portion.

/azp run

#sign-off

Fix the LintDiff and SemanticValidation error (missing required property) and this should be good to go. The breaking change is not specific to your changes, it seems. /cc @mikekistler @JeffreyRichter

The LintDiff and semantic validations are due to the missing required property. In this case, key-verison is not a required property. Could you please help check this PR in ?


👑 pro-table ++ editable-table?

Is there anyway of merging the abilities of the pro-table and editable-table?

give a pr？


Facebook SDK returned an error: Connection timed out after 10000 milliseconds

Facebook SDK returned an error: Connection timed out after 10000 milliseconds

If attempt to communicate with provider times out there's nothing the plugin can do.

there must be a curl timeout in plugin

The actual communication with auth providers is done by the HybridAuth lib so you should inquire there. This plugin is just a bridge for using that lib with AuthComponent.


Update cumulusci.yml to exclude @beta tags

Critical Changes
Changes
Issues Closed

@chrismcmahon do you still need this?

No longer needed, closing without merging.


/fr/docs/Web/HTTP/CSP

Request type

[] Please close this issue, I accidentally submitted it without adding any details
[ ] New documentation
[x ] Correction or update

Details

The French translation of the Content Security Policy on MDN web docs needs to be properly reviewed. It contains a lot anglicisms, untranslated English terms, typographical errors, an is not always faithful to the English text.

@chrisdavidmills thanks for the heads up :)
@AO-Loclab this page needed some fixes but it did not contain a lot of anglicism. Could you please describe the terms and errors if you report them?
I did a rewrite of some parts of the page and it looks OK to me. I used Grammalecte to check for errors too.
Also, please note that MDN is open for everyone to contribute and fix typos/errors so feel free to improve/fix any content! If you have questions or need help doing so, please do not hesitate to reach out.


logger move to uORB::SubscriptionInterval

Requires a higher level design review and #12040 before merging.

@PX4/testflights could you give this an initial flight test?

Tested on Pixhawk 4 V5
Modes Tested
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.
- Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
Logs:
https://review.px4.io/plot_app?log=8653da75-a92a-4c73-98ec-e274a611947c
https://review.px4.io/plot_app?log=dc323f18-7838-47ff-986a-2c43c3d6be60
Comparison to master
https://review.px4.io/plot_app?log=f3bf829a-b204-444e-be36-77dab0d1fcb9

@Tony3dr @jorge789 those logs seem to be from https://github.com/PX4/Firmware/pull/12162. Can you try again with the current state of this PR? Thanks.

@Tony3dr @jorge789 those logs seem to be from #12162. Can you try again with the current state of this PR? Thanks.

@dagar thanks for pointing that out, we will test the PR today.

Tested on Pixhawk 2 Cube V3:
Modes Tested
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.
- Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
Logs
https://review.px4.io/plot_app?log=170541f1-b7d5-4825-85e3-69a723d88945
Comparison to master
https://review.px4.io/plot_app?log=b31999c2-52eb-40e0-a440-a9c510e05ab8

Tested on Pixhawk 4 V5 f-450
Modes Tested
Position Mode: no issue
Altitude Mode: no issue
Stabilized Mode: no issue
Mission Plan Mode: : no issue
RTL:  no issue
Notes:
No issues noted, good flight in general.
pr tested log:
https://review.px4.io/plot_app?log=ad5bf2db-4a36-4ab8-b253-23776d01e5e2
master log:
https://review.px4.io/plot_app?log=0c295146-ffb9-4920-8821-bf2c3141ff15

Thanks for the early test. This still needs more work.

Tested on Pixhawk 4 mini v5
Modes Tested

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

- Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
Logs:
PR 12123

https://review.px4.io/plot_app?log=a7185769-56ba-494f-b3df-78ed98464358

Master

https://review.px4.io/plot_app?log=e3db6d5c-dd0c-45da-99ce-8d2aaead010b

Ready for review and testing.

Tested on Pixhawk 4 mini v5
Modes Tested

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
Logs:
PR 12123

https://review.px4.io/plot_app?log=abeb557c-8411-4d2a-bbd3-3dae17eb1ddf

Master

https://review.px4.io/plot_app?log=b014c23c-c92a-45fd-8bc7-062bac5d909e

Tested on Pixhawk 4 V5
Modes Tested
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

Procedure
Arm and Take off in stabilized mode, position mode, altitude, and mission mode

Notes:
No issues noted good flight in general.
pr Log:
https://review.px4.io/plot_app?log=454e6011-9440-47cc-b1be-3edb97a54ec0
master log:
https://review.px4.io/plot_app?log=71a5aa74-1e6e-4c9c-ae20-2baff55f3daf

Tested on PixRacer V4:
Modes Tested
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.
- Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
Logs:
https://review.px4.io/plot_app?log=75328eb9-432f-45a0-b1ce-634a7bdda0f4

Probably best reviewed by @bkueng.

most importantly: _subscription is a constant block of almost 3kB. At this point I prefer something more dynamic: either a linked list or a linked list with ~10 LoggerSubscription per node might be a good trade-off (90 elements will probably also not be enough for extensive setups, I already see 69 being used on a pixracer w/o any peripheral).

Yes I'd also like it to be more dynamic (to log even more). I was thinking about refactoring the topic initialization so that a fixed size _subscriptions can be allocated once. We can do this separately though. As soon as this PR settles it's already safe to decrease CONFIG_NFILE_DESCRIPTORS from 54 -> 20, and it won't be too long until it can decrease again to 10. Decreasing CONFIG_NFILE_DESCRIPTORS to 20 saves ~ 10kB of ram.

would be nice if we did not have to distinguish between single vs multi topics, but it's something we can address later.

I think we'd ultimately be better off making the max number of topics a fixed property of the topic itself and possibly segregating the orb API a bit. The majority of topics should only ever be single instances and when dealing with multi the instance should explicit. This would remove the possibility of misuse, allow varying the size of each separately, enable a few internal orb optimizations, and make it easier to get back to a single logger add_topic(). Bigger discussion for a followup issue/PR.

TODO: replay https://github.com/PX4/Firmware/pull/12123#discussion_r297090221

Can you please separate the commits better? For example the _ulog_stream_pub change is independent from the rest.

Tested on Pixhawk 2 Cube V3:
Modes Tested
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.
- Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
log:
https://review.px4.io/plot_app?log=11da5031-a782-413d-8c2b-e3a2adef78f6
Tested on PixRacer V4:
Modes Tested
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.
- Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
Log:
https://review.px4.io/plot_app?log=59163d2a-ec8a-461a-9a11-449825d9cc68
Tested on CUAC+ V5:
Modes Tested
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.
- Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
Log:
https://review.px4.io/plot_app?log=b10c72cc-f335-4a13-b94a-e412ae1281a0

@jorge789 those are the logs for https://github.com/PX4/Firmware/pull/12224

@jorge789 those are the logs for #12224

Thanks for the observation, I got an error when I opened Jenkins and just proceeded to reload, that might have been the issue.

Tested on Pixhawk Pro v4
Modes Tested

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
Logs:

https://review.px4.io/plot_app?log=43fb8dd7-9706-4837-bb29-06bc1006d1e8

Tested on Pixhawk 4 mini v5
Modes Tested

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
Logs:

https://review.px4.io/plot_app?log=53012b02-5683-4551-9718-2cd235c5ecb1

Tested on NXP FMUK66 v3
Modes Tested

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.
Notes:
No issues noted, good flight in general.
Logs:

https://review.px4.io/plot_app?log=47d26960-bddf-41a9-92e0-926023ab6e74

Can you please separate the commits better? For example the _ulog_stream_pub change is independent from the rest.

I can bring that in separately if it helps.

Separate commits is enough.

Rebased on master with the other pieces merged.


Another example on real data

So I compared the result v.s. real distance. (The focal is from iphone) It seems that there is still a large gap. The relative error is 33% and 36% in the two measurements.
Some examples in figure 7 also shows this big error, so I guess this is what to expect. This is not a bug, just some report.

Thank you for your case! We hope more data and stronger models shall help us shrink metric errors in the future.


Compiler warnings: -Wmissing-prototypes

When enabling this option I get a lot of hits in the various C code
../../dist/crypto/blake3/blake3_avx512.c:292:6: warning: no previous prototype for 'blake3_compress_xof_avx512' [-Wmissing-prototypes]
void blake3_compress_xof_avx512(const uint32_t cv[8],
^~~~~~~~~~~~~~~~~~~~~~~~~~
Would it be possible to make sure all functions are either local to a module and static or defined in a header?

Sure, we have some declarations in blake3_dispatch.c, and we could probably move those out into a header file.

https://github.com/BLAKE3-team/BLAKE3/commit/eec458d03ee7828225dda4f08138563d4ff8bb6d

I wonder if I should add something like -Werror -Wmissing-prototypes to all of our compiler invocations in CI. Any other best-practice flags you guys know of?

For what it's worth, I think -Wmissing-prototypes is one of the most pointless warnings you can enable. In fact it is not enabled with -Wall -Wextra for good reason---it's highly noisy, and rarely if ever finds real bugs.

Fair enough. I'm going to go ahead and close this one.


Columns to consume full width of fin-hypergrid canvas

Hi,
Is there any way to achieve below functionality.
If  a grid has 5 columns can they consume full size of the canvas having equal distribution. and if no of columns increased by certain limit a horizontal scroll bar should get added.
Please take a look at fin-hypergrid example  in this a lot of white space is left between the last column Travel and the scroll bar. (I do not want to resize it manually)
I want fin-hypergrid to consume fill size of canvas in such scenario. and after certain limit scrollbar should get added.

Duplicate of https://github.com/openfin/fin-hypergrid/issues/550
@91c5ex Let's discuss this on the link posted above


Pattern doesn't work with ! at the beginning

There doesn't appear to be a way to get a $ at the beginning of a pattern it blows up with a length exception.

@owlyowl I ran into the same issue trying to get the euro currency to the left of the amount.
If you look a the source code it has the default patterns, EUR has a default of '#,##0.00 !', so using the pattern <Currency pattern="!#,##0.00" ... seems to work.

@owlyowl I ran into the same issue trying to get the euro currency to the left of the amount.
If you look a the source code it has the default patterns, EUR has a default of '#,##0.00 !', so using the pattern <Currency pattern="!#,##0.00" ... seems to work.


Repository is out of Sync with Hackage

Background: xmonad-extras doesn't compile with ghc-8.2 as libmpd build fails, so I wanted to send a PR to this repo to fix this.
But If I see the cabal file here, the latest version according to it seems to be <IP_ADDRESS>. But If I go and see it's hackage page, the version according to it is <IP_ADDRESS>.
So why is the cabal file outdated and the repository out of sync ?

The hackage releases are based on https://github.com/vimus/libmpd-haskell/commits/libmpd-0.9. I'll upload a new version soonish. Sorry for the inconvenience.

Ah, I see. I have sent a relevant PR to that branch fixing the Stackage issue: https://github.com/vimus/libmpd-haskell/pull/95
It would be informative if the branch thing can be mentioned in README.md. Would be glad to see a new version of libmpd. I have already bumped the package version in the PR.

Fixes are still intended to go into master first.  I'll consider adding a note about the stable branch at some point.


AB relevance testing for notes fields

This has been made available to the client here

No discernible difference in the distribution of clicks - I'm happy to close this and fold notes into the list of fields we query. Will be worth coming back to this when we run another set of tests on how we boost fields, but for now, it doesn't look like it's having an adverse affect.
@jtweed @taceybadgerbrook @jamesgorrie

@jennpb fyi for the relevance testing of notes fields in search

No longer considered resolved https://github.com/wellcometrust/platform/issues/4019

Closed for now as per resolution of #4019


async/await not highlight

for async/await method in class, it works.
but for functions, it doesn't

Hi, this is what I see:

I will need code snippets to reproduce your issue.

Not highlighted:
foo()
(async () => ...)

Highlighted:
foo();
(async () => ...)

Not highlighted:
var spam = async function () {
}

maybe some other plugin has conflict with this. After I delete all other plugins, this works good. Maybe I should try to find which plugin conflict with this. Thanks for your quick response and hard work.


Fixed effects issue

Dear Professor Müller,
Thank you for writing this package!
I encountered an issue when using your command in this specific setting: I am using it to correct for spacial correlation when clustering the errors at the regional level. However, I have fixed effects at the municipality level (which is smaller than region). When I use areg and then run your command, it returns an error: "not sorted".
In my modest attempt to understand what could cause this issue, I read your code and I believe it may be because of the sorting: even though it sorts by cluster in the beginning, this sorting is reverted when it sorts by fixed effect. Could this be the issue?
Thank you so much once again!
Best regards,
Catarina Gaspar

Hi Catarina,
Thank you for your interest!
As you could probably tell from the code, I'm not much of a STATA
programmer at all. I will try to look into it, but it will take a while,
and I might not be able to get SCPC to run with areg...
As a workaround, can you use reg instead after explicitly generating the
dummies? Or are there so many that this is not possible in your application?
Alternatively you could also demean all variables (including the dependent
variable) on the municipality level and then simply run reg without any
municipality dummies. That should give you the same result.
Best wishes,
Ulrich
On Thu, Nov 17, 2022, 5:18 AM catarina-gaspar @.***>
wrote:

Dear Professor Müller,
Thank you for writing this package!
I encountered an issue when using your command in this specific setting: I
am using it to correct for spacial correlation when clustering the errors
at the regional level. However, I have fixed effects at the municipality
level (which is smaller than region). When I use areg and then run your
command, it returns an error: "not sorted".
In my modest attempt to understand what could cause this issue, I read
your code and I believe it may be because of the sorting: even though it
sorts by cluster in the beginning, this sorting is reverted when it sorts
by fixed effect. Could this be the issue?
Thank you so much once again!
Best regards,
Catarina Gaspar
—
Reply to this email directly, view it on GitHub
https://github.com/ukmueller/SCPC/issues/3, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQISWNZTWTJ6V7BLHFDYT43WIYA7NANCNFSM6AAAAAASDGNCXQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Dear Professor Müller,
Thank you so much for your answer! Yes, since I have too many fixed effects, I actually demeaned them as you suggested.
All the best,
Catarina

Dear Professor Müller,
We wanted to update our results based on your more recent paper regarding improvements on the SCPC method (particularly, the implementation of the conditional-SCPC method). However, reading the help file of your command in STATA, it is not clear for me whether there is an option to apply this new robustified version of the SCPC correction. Is it the case that using the command already considers this more recent method?
Thank you so much once again!
All the best,
Catarina

Hi Catarina,
Yes, by default, scpc computes the "conditional" critical values. You can override this default by using the option "uncond".
Let me know if that answers your question.
Best wishes,
Ulrich


Undo issue fix 26201 in Gradle User Manual - symlinks

Details
This is a Documentation change ONLY.
Context
Undo doc change for @lptr : https://github.com/gradle/gradle/issues/26201
Reviewers:
1 min review

I've triggered a build for you. Click here to see all failures if there's any.


Bring Window to Foreground or Set to Topmost Window

Is there a way to keep the eel application on top of all other open windows.
Desktop :

OS: Windows 7
Browser: Chrome

This is probably an exercise for the developer. It may be configurable on a per-browser basis, but it doesn't feel like something for Eel to control. Try having a look at Chrome's command-line flags to see if there's one that keeps the window on top. If there is, you can apply it through the cmdline_args argument to eel.start


Poor quality after upgrade from <IP_ADDRESS>/<IP_ADDRESS> to 2.9.0/4.12.0

We're experiencing a drop in quality on resized images since we upgraded to the latest versions of the ImageProcessor and sup projects.
Upgrades:
ImageProcessor: <IP_ADDRESS> to 2.9.0
ImageProcessor.Web: <IP_ADDRESS> to 4.12.0
ImageProcessor.Web.Config: <IP_ADDRESS>to 2.6.0
ImageProcessor.Web.PostProcessor: 1.1.2 to 2.0.0
We also have the ImageProcessor.Plugins.WebP 1.3.0 installed, but since we see the same problem without format=webp, I don't see how that would matter.
When resizing https://www.obviuse.se/static/um.jpg to either 780 or 390 in width the text in the logotype get really poor jpg quality. We also see a big drop in file size.
https://www.wherever.com/um.jpg?width=390 results:
https://www.obviuse.se/static/um-4.10-390.jpg 30k
https://www.obviuse.se/static/um-4.12-390.jpg 17k
https://www.wherever.com/um.jpg?width=780 results:
https://www.obviuse.se/static/um-4.10-780.jpg 120k
https://www.obviuse.se/static/um-4.12-780.jpg 67k
Adding &quality=100 gives us the exact same result.
Been trying to adjust the output with gaussian sharpen, but that wouldn't be the correct way of solving the problem. We would want quality=100 to be somewhat lossless, as expected.
The lower file size is of course a really good thing, but we can't figure out how to force the resize to get the best quality possible. Is it a bug or a configuration issue?
We use .NET 4.72 on a Win 2012 R2 server (and Win 10 when developing).
Cheers´
Anders Brohäll

That said, we're not too happy about the quality of the previous version neither. Maybe there is a way of improving the quality all-in-all.
When resizing the image - with all default settings and saved with max quality (12) - in Photoshop, the result is:
https://www.obviuse.se/static/um-ps-390.jpg 135k
https://www.obviuse.se/static/um-ps-780.jpg 439k
Of course the file size is a lot bigger than the rendered ones, but i would prefer being able to adjust that myself with fiddeling with the quality setting in ImageProcessor.
Without any record of it, I remember the older versions of the ImageProcessor being virtually lossless using quality=100. But i might be remembering it wrong?

ImageProcessor.Web.PostProcessor: 1.1.2 to 2.0.0

Using a post processor will definitely reduce the file size vs Photoshop. The post processor uses MozJpeg under the cover to .
Since there's no before before/after examples I cannot tell if there is a difference in the output with or without the post processor. If anything, the default output should be better with later versions as we've cranked up all the System.Drawing settings to maximum.

Without any record of it, I remember the older versions of the ImageProcessor being virtually lossless using quality=100. But i might be remembering it wrong?

The main difference I see between the Photoshop version and the ImageProcessor version is chroma subsampling. System.Drawing always subsamples which is not great for high quality jpegs. That behavior has and will not ever change.

If quality is important, you should uninstall the PostProcessor plug-in, as that will always lower the quality (even if ImageProcessor is saving the image with as quality of 100%). Like @JimBobSquarePants mentions, ImageProcessor depends on what System.Drawing can provide, which might not equal other programs like Photoshop.


Support client key password for HTTPS connections #7418

I've tested password protected PEM file format keys that use RSA. I've also tested the inverse case using a non password protected key and this still works. Provided the element client_key_password is null or client_key_password_len is 0.

 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.

resolves #7418

Thanks for your contribution.

@AshUK Thank for the review. @joncmaloney can you please update the changes. I think that should be enough to merge this PR.

@AshUK Thanks for the feedback. I've updated the changes suggested and rebased to espressif/esp-idf:master

@AdityaHPatwardhan
Will this PR apply to v4.3? (It's a trivial change, the low level API already supports client key password)

Hi @AxelLin, so if it is required  we may apply this change to v4.3 as well.


can't connect to kali servers after updating wsl to v2

Microsoft Windows [Version 10.0.19041.388]
i installed kali linux on WSL version 1 it was working and every thing was so good
i then updated my WSL to version 2
and used this command to change the kali to be working on WSL 2
wsl --set-version kali-linux 2
and then it went successfully i tried to do sudo apt-get update
and oops timeout
i check internet nothing is working though my windows is connected correctly i hope u help me please

Call this /dupe #4183 which is close enough for a still-open landing zone. Tangentially similar #4223 #4171, others.

i tried all the solutions mentioned and nothing fixed my problem
i can ping any ip any website

i tried all the solutions and nothing fixed my problem
i can do ping for any ip and any website
and nslookup also
but can't do apt uipdate
or curl or wget

this took me days searching trying installing and reinstalling i could finally fix this by using these commands in power shell
wsl --shutdown netsh winsock reset netsh int ip reset all netsh winhttp reset proxy ipconfig /flushdns
and rebobted then went to avast firewall allow all inboud and outbound connection and it worked for me

this took me days searching trying installing and reinstalling i could finally fix this by using these commands in power shell
wsl --shutdown netsh winsock reset netsh int ip reset all netsh winhttp reset proxy ipconfig /flushdns
and rebobted then went to avast firewall allow all inboud and outbound connection and it worked for me

Thank. It worked for me too.
I had similar issue when tried to run docker pull <some image>, docker login or docker-compose up. I've been got timeout everytime I run any of those command. Nslookup, ping and curl were working with no issues.

┌──(pnvs㉿LAPTOP-0TJ1JHA7)-[~]
└─$ sudo apt update
[sudo] password for pnvs:
Ign:1 http://http.kali.org/kali kali-last-snapshot InRelease
Ign:1 http://http.kali.org/kali kali-last-snapshot InRelease
Ign:1 http://http.kali.org/kali kali-last-snapshot InRelease
Err:1 http://http.kali.org/kali kali-last-snapshot InRelease
Temporary failure resolving 'http.kali.org'
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: Failed to fetch http://http.kali.org/kali/dists/kali-last-snapshot/InRelease  Temporary failure resolving 'http.kali.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.


Extensible Resource Deployment Observability Improvements

Kyle is now driving the design and development as part of the stacks and extensibility integration efforts.


No result returned when using a hard separator within phrase search

Describe the bug
According to the documentation, using a hard separator within a phrase search effectively splits it into separate phrase searches: “Octavia.Butler” will return the same results as “Octavia” “Butler”.
To Reproduce
Steps to reproduce the behavior:

Download the movies.json dataset and index it to Meilisearch.
Phrase search "Four.Rooms" returns no result.

Expected behavior
Phrase search "Four.Rooms" should return a result as "Four" "Rooms"
Screenshots

Meilisearch version: v0.29.1
Additional context
Additional information that may be relevant to the issue.
[e.g. architecture, device, OS, browser]

Thanks @oluademola
We will look into this soon

Hello @curquiza and @oluademola,
This issue is not a bug, but a feature to handle non-separating dots like 3.5, node.js.
It is related to https://github.com/meilisearch/charabia/issues/62
Trying "Four. Rooms" instead of "Four.Rooms" should work.

Thanks @ManyTheFish
@oluademola is it something a user asked for or something you think inconsistent regarding the docs?
Indeed, as Many explained, this is something we changed because the users wanted to find "S.O.S" when typing "sos", or "node.js" when typing "nodejs"
If it's something a user asked for, could you open a product discussion with more details @oluademola? I mean the context of the user, whey they need this.

Thank you @ManyTheFish and @curquiza
@curquiza, a user was trying to achieve this by following the instructions in the docs because it says so. I'd go with this and communicate this feedback to the user.
Thanks again.

Ok @oluademola, thanks for letting us know. The user is more than welcome to open a discussion in the product discussion if needed 😄
I close this issue then!


Add functions from Histogram v1 Lua to C

I am not sure why we use private_nan here over a math.h-NAN. But it's use is consistent with hist_approx_quantile, so LGTM


feat: Added Purolator shipper and Intelcom shipper (used by Amazon Canada) …

…for Canada
Proposed change

Type of change

[ ] Dependency upgrade
[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (which adds functionality)
[ ] Breaking change (fix/feature causing existing functionality to break)
[ ] Code quality improvements to existing code or addition of tests
[ ] Documentation update
[X] Adds a new shipper
[ ] Update existing shipper

Additional information

You'd actually want to base your changes on the dev branch not master.

Ah, got it. Thanks for your patience!
Garnet

On Jan 3, 2023, at 2:04 PM, Chris @.***> wrote:
You'd actually want to base your changes on the dev branch not master.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

You'll want to redo the edits from the dev branch, changing it here just causes a mess.

Will do, sorry about that - I wondered about that but didn’t want to create more confusion.

On Jan 3, 2023, at 6:04 PM, Chris @.***> wrote:
You'll want to redo the edits from the dev branch, changing it here just causes a mess.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Delete to re-issue PR under dev branch