GCE PD Data Loss

0.9.1 (edit: originally thought it was 0.9.2) in GCE and I'm seeing data disappear from GCE PDs after deleting the pod that mounts it.
I'm attaching some relevant looking bits from the kubelet log.
I0130 01:00:21.156131    4820 kubelet.go:1255] Killing unwanted container {podFullName:prometheus.default.api uid:6fcd7fc4-a7ff-11e4-85c6-42010af0b3db containerName:prometheus}
I0130 01:00:21.156169    4820 kubelet.go:863] Killing container with id "1f85b85dc825b218f9273869678d09b7f6c3a93307ac2b5edb9255f5a406dfb3" and name "/k8s_prometheus.95c0e9de_prometheus.default.api_6fcd7fc4-a7ff-11e4-85c6-42010af0b3db_0f4a949a"
I0130 01:00:21.156331    4820 event.go:117] Event(api.ObjectReference{Kind:"BoundPod", Namespace:"default", Name:"prometheus", UID:"6fcd7fc4-a7ff-11e4-85c6-42010af0b3db", APIVersion:"v1beta1", ResourceVersion:"", FieldPath:"spec.containers{node-exporter}"}): reason: 'killing' Killing b4bfcd6c3de50df86f1e6dfb5ddbcba94fb731c07375f849e907d685bde1c142 - /k8s_node-exporter.562dc0b8_prometheus.default.api_6fcd7fc4-a7ff-11e4-85c6-42010af0b3db_6354e686
I0130 01:00:21.322846    4820 event.go:117] Event(api.ObjectReference{Kind:"BoundPod", Namespace:"default", Name:"prometheus", UID:"6fcd7fc4-a7ff-11e4-85c6-42010af0b3db", APIVersion:"v1beta1", ResourceVersion:"", FieldPath:"spec.containers{prometheus}"}): reason: 'killing' Killing 1f85b85dc825b218f9273869678d09b7f6c3a93307ac2b5edb9255f5a406dfb3 - /k8s_prometheus.95c0e9de_prometheus.default.api_6fcd7fc4-a7ff-11e4-85c6-42010af0b3db_0f4a949a
E0130 01:00:21.354926    4820 kubelet.go:1345] Couldn't sync containers: remove /var/lib/kubelet/pods/6fcd7fc4-a7ff-11e4-85c6-42010af0b3db/volumes/kubernetes.io~gce-pd/prometheus-storage: device or resource busy
E0130 01:00:31.359134    4820 kubelet.go:1345] Couldn't sync containers: remove /var/lib/kubelet/pods/6fcd7fc4-a7ff-11e4-85c6-42010af0b3db/volumes/kubernetes.io~gce-pd/prometheus-storage: device or resource busy
E0130 01:00:41.363139    4820 kubelet.go:1345] Couldn't sync containers: remove /var/lib/kubelet/pods/6fcd7fc4-a7ff-11e4-85c6-42010af0b3db/volumes/kubernetes.io~gce-pd/prometheus-storage: device or resource busy
E0130 01:00:51.368149    4820 kubelet.go:1345] Couldn't sync containers: remove /var/lib/kubelet/pods/6fcd7fc4-a7ff-11e4-85c6-42010af0b3db/volumes/kubernetes.io~gce-pd/prometheus-storage: device or resource busy
E0130 01:01:01.372352    4820 kubelet.go:1345] Couldn't sync containers: remove /var/lib/kubelet/pods/6fcd7fc4-a7ff-11e4-85c6-42010af0b3db/volumes/kubernetes.io~gce-pd/prometheus-storage: device or resource busy

Around this point I ssh to the minion and ls -l the root of the PD and found nothing there. There was definitely data on the device before I deleted the pod.
Also, after this happens, I have to manually detach the disk using gcloud or the GCE console and then umount all of the places where the PD was mounted on the minion.

This pod is deployed stand-alone, not by a replication controller, in case that makes a difference. I've seen it with other pods as well, such as one running mysql.

Thanks for the report, I will try to look into it.
Can you grab the event stream (kubectl get events) next time it happens as
well?
Thanks
--brendan
On Thu, Jan 29, 2015 at 5:12 PM, Steve Reed<EMAIL_ADDRESS>wrote:

This pod is deployed stand-alone, not by a replication controller, in case
that makes a difference. I've seen it with other pods as well, such as one
running mysql.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72137041
.

Do you think this was related to the PR you just put in with RemoveAll?
This is why I suggested maybe re-checking isMountPoint() and ONLY
proceeding with Remove() if it is not...
On Thu, Jan 29, 2015 at 5:18 PM, Brendan Burns<EMAIL_ADDRESS>wrote:

Thanks for the report, I will try to look into it.
Can you grab the event stream (kubectl get events) next time it happens as
well?
Thanks
--brendan
On Thu, Jan 29, 2015 at 5:12 PM, Steve Reed<EMAIL_ADDRESS>wrote:

This pod is deployed stand-alone, not by a replication controller, in
case
that makes a difference. I've seen it with other pods as well, such as
one
running mysql.
--
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72137041>

.

--
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72137647
.

I'll grab events next time. I can repro this easily so I'll try to do it
first thing tomorrow.
On Thu, Jan 29, 2015, 17:18 Brendan Burns<EMAIL_ADDRESS>wrote:

Thanks for the report, I will try to look into it.
Can you grab the event stream (kubectl get events) next time it happens as
well?
Thanks
--brendan
On Thu, Jan 29, 2015 at 5:12 PM, Steve Reed<EMAIL_ADDRESS>wrote:

This pod is deployed stand-alone, not by a replication controller, in
case
that makes a difference. I've seen it with other pods as well, such as
one
running mysql.
—
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72137041>

.

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72137647
.

We really need an actual persistent data e2e :/
On Jan 29, 2015 7:50 PM, "Steve Reed"<EMAIL_ADDRESS>wrote:

I'll grab events next time. I can repro this easily so I'll try to do it
first thing tomorrow.
On Thu, Jan 29, 2015, 17:18 Brendan Burns<EMAIL_ADDRESS>wrote:

Thanks for the report, I will try to look into it.
Can you grab the event stream (kubectl get events) next time it happens
as
well?
Thanks
--brendan
On Thu, Jan 29, 2015 at 5:12 PM, Steve Reed<EMAIL_ADDRESS>wrote:

This pod is deployed stand-alone, not by a replication controller, in
case
that makes a difference. I've seen it with other pods as well, such as
one
running mysql.
—
Reply to this email directly or view it on GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72137041>

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72137647>

.

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72150082
.

These are the only events I see from kubectl get events from when I killed the pod.
Fri, 30 Jan 2015 01:00:21 +0000   prometheus                                           BoundPod            spec.containers{node-exporter}              killing             {kubelet kubernetes-minion-7.c.eternal-empire-754.internal}    Killing b4bfcd6c3de50df86f1e6dfb5ddbcba94fb731c07375f849e907d685bde1c142 - /k8s_node-exporter.562dc0b8_prometheus.default.api_6fcd7fc4-a7ff-11e4-85c6-42010af0b3db_6354e686
Fri, 30 Jan 2015 01:00:21 +0000   prometheus                                           BoundPod            implicitly required container net           killing             {kubelet kubernetes-minion-7.c.eternal-empire-754.internal}    Killing 7b850cb0c0ddf83a8a9772ae8f58a981ce77ffe1ed536ba08bd20882b8485cd7 - /k8s_net.ba9fd962_prometheus.default.api_6fcd7fc4-a7ff-11e4-85c6-42010af0b3db_925c3fed
Fri, 30 Jan 2015 01:00:21 +0000   prometheus                                           BoundPod            spec.containers{prometheus}                 killing             {kubelet kubernetes-minion-7.c.eternal-empire-754.internal}    Killing 1f85b85dc825b218f9273869678d09b7f6c3a93307ac2b5edb9255f5a406dfb3 - /k8s_prometheus.95c0e9de_prometheus.default.api_6fcd7fc4-a7ff-11e4-85c6-42010af0b3db_0f4a949a

One more repro, with hopefully more clues.
Pod is deployed, PD is attached properly, and data is being persisted.
root@kubernetes-minion-2:~# find /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/prometheus-storage | wc -l
890
root@kubernetes-minion-2:~# du -h --max-depth 0 /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/prometheus-storage
26M     /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/prometheus-storage

Now from my laptop I kubectl delete pod prometheus. Here's the output from kubectl get events shortly thereafter.
Fri, 30 Jan 2015 16:13:39 +0000   prometheus                                           BoundPod            implicitly required container net           killing             {kubelet kubernetes-minion-2.c.eternal-empire-754.internal}    Killing abdbe3ad74c4ac77e2d91f97a65afb0e84e1175b4c72deaa65ff11e8687523b6 - /k8s_net.ba9fd962_prometheus.default.api_91105043-a81b-11e4-85c6-42010af0b3db_385031d6
Fri, 30 Jan 2015 16:13:39 +0000   prometheus                                           BoundPod            spec.containers{node-exporter}              killing             {kubelet kubernetes-minion-2.c.eternal-empire-754.internal}    Killing 7afd3d877c53b0daa17b1339594a718f242fe798ef6eff74d92661d02a4e7a20 - /k8s_node-exporter.562dc0b8_prometheus.default.api_91105043-a81b-11e4-85c6-42010af0b3db_d04b2558
Fri, 30 Jan 2015 16:13:39 +0000   prometheus                                           BoundPod            spec.containers{prometheus}                 killing             {kubelet kubernetes-minion-2.c.eternal-empire-754.internal}    Killing ec41aaaab1f3af969735728699f91e026f1d69ff50edafb4663d3fe58ad03504 - /k8s_prometheus.95c0e9de_prometheus.default.api_91105043-a81b-11e4-85c6-42010af0b3db_10566093

If I run gcloud compute instances describe kubernetes-minion-2 here's the "disks" section:
disks:
- autoDelete: true
  boot: true
  deviceName: persistent-disk-0
  index: 0
  interface: SCSI
  kind: compute#attachedDisk
  mode: READ_WRITE
  source: https://www.googleapis.com/compute/v1/projects/eternal-empire-754/zones/us-central1-f/disks/kubernetes-minion-2
  type: PERSISTENT
- deviceName: prometheus-storage
  index: 1
  interface: SCSI
  kind: compute#attachedDisk
  mode: READ_WRITE
  source: https://www.googleapis.com/compute/v1/projects/eternal-empire-754/zones/us-central1-f/disks/prometheus-storage
  type: PERSISTENT

The disk is still attached, what about the contents of the disk?
root@kubernetes-minion-2:~# df -h | grep prom
/dev/disk/by-id/google-prometheus-storage               197G   60M  187G   1% /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/prometheus-storage
/dev/disk/by-id/google-prometheus-storage               197G   60M  187G   1% /var/lib/kubelet/pods/91105043-a81b-11e4-85c6-42010af0b3db/volumes/kubernetes.io~gce-pd/prometheus-storage

root@kubernetes-minion-2:~# du -h --max-depth 0 /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/prometheus-storage
4.0K    /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/prometheus-storage

root@kubernetes-minion-2:~# find /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/prometheus-storage | wc -l
1

Finally the output of kubectl version. Looks like I lied about running 0.9.2, we're running 0.9.1 on the servers (I'll update my original comment).
Running: ./../cluster/gce/../../platforms/linux/amd64/kubectl version
Client Version: version.Info{Major:"0", Minor:"9+", GitVersion:"v0.9.2-dirty", GitCommit:"013a97ea6e2a143f763035defdbcbcdc1b6d3411", GitTreeState:"dirty"}
Server Version: &version.Info{Major:"0", Minor:"9+", GitVersion:"v0.9.1-dirty", GitCommit:"3623a01bf0e90de6345147eef62894057fe04b29", GitTreeState:"dirty"}

@brendandburns it seems like your commit https://github.com/GoogleCloudPlatform/kubernetes/commit/a0b8429d2e57e15d559333a79f33ff58ad1cf34e would fix this. Looks like the old code was pretty clearly blowing everything away with os.RemoveAll before asking for the PD to be detached.

It SHOULD have been unmounted first, so there is still an open question of
why the data was visible there.  Maybe we should also change that RemoveAll
to a simple rmdir, which will fail if it is not empty.  Not sure if I can
rmdir a mount point, but I think not..
On Jan 30, 2015 9:00 AM, "Steve Reed"<EMAIL_ADDRESS>wrote:

@brendandburns https://github.com/brendandburns it seems like your
commit a0b8429
https://github.com/GoogleCloudPlatform/kubernetes/commit/a0b8429d2e57e15d559333a79f33ff58ad1cf34e
would fix this. Looks like the old code was pretty clearly blowing
everything away with os.RemoveAll before asking for the PD to be detached.
--
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72233151
.

Yeah, I'll update https://github.com/GoogleCloudPlatform/kubernetes/pull/3967 to just try to rmdir...

Ok, #3967 is merged. @smreed can you try to repro?
Thanks!

Probably not until tomorrow, but I will ASAP for sure.
On Tue Feb 03 2015 at 11:29:43 AM Brendan Burns<EMAIL_ADDRESS>wrote:

Ok, #3967 https://github.com/GoogleCloudPlatform/kubernetes/pull/3967
is merged. @smreed https://github.com/smreed can you try to repro?
Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72717296
.

Deployed 0.10.0 and tested this.
kube-down did not blow away any data on the disk, it was present after the new cluster was up and the pods were deployed.
Then, I deleted the pod w/ the PD. I saw this repeated in the kubelet.log:
E0204 21:34:15.454164    4722 kubelet.go:1359] Couldn't sync containers: remove /var/lib/kubelet/pods/3faea999-acb3-11e4-9b3d-42010af0f1f5/volumes/kubernetes.io~gce-pd/prometheus-storage: device or resource busy

The GCE console reported the disk as still being attached to the minion. The pod containers were not running.
Ran ls -al /var/lib/kubelet/plugins/kubernetes.io/gce-pd/mounts/prometheus-storage, the directory was empty.
Deployed the pod again, it landed on a different minion but stayed pending due to the fact that the disk was already attached elsewhere.
I manually detached the PD from the old minion, and the pod eventually deployed on the new one. I confirmed on this minion that the PD came in empty with no data.
kubectl version:
Client Version: version.Info{Major:"0", Minor:"10+", GitVersion:"v0.10.0-dirty", GitCommit:"71e26cbeb9c0bf1b6cc4c29b1f9d930e53513911", GitTreeState:"dirty"}
Server Version: version.Info{Major:"0", Minor:"10+", GitVersion:"v0.10.0-dirty", GitCommit:"71e26cbeb9c0bf1b6cc4c29b1f9d930e53513911", GitTreeState:"dirty"}
Adding output of kubectl events for this pod in the next comment.

Wed, 04 Feb 2015 21:17:39 +0000   prom-dash                                            BoundPod            implicitly required container POD           pulled              {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Successfully pulled image "kubernetes/pause:latest"
Wed, 04 Feb 2015 21:17:39 +0000   prometheus-push                                      BoundPod            implicitly required container POD           pulled              {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Successfully pulled image "kubernetes/pause:latest"
Wed, 04 Feb 2015 21:17:39 +0000   prom-dash                                            Pod                                                             scheduled           {scheduler }                                                   Successfully assigned prom-dash to kubernetes-minion-3.c.eternal-empire-754.internal
Wed, 04 Feb 2015 21:17:39 +0000   prom-dash                                            BoundPod            implicitly required container POD           created             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Created with docker id efcf5e1e2ee0e8988de356ec5adedeb28b6969b23ed60f0339e7b36a554fe8dd
Wed, 04 Feb 2015 21:17:39 +0000   prom-dash                                            BoundPod            implicitly required container POD           started             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Started with docker id efcf5e1e2ee0e8988de356ec5adedeb28b6969b23ed60f0339e7b36a554fe8dd
Wed, 04 Feb 2015 21:17:39 +0000   prometheus-push                                      Pod                                                             scheduled           {scheduler }                                                   Successfully assigned prometheus-push to kubernetes-minion-3.c.eternal-empire-754.internal
Wed, 04 Feb 2015 21:17:39 +0000   prometheus-push                                      BoundPod            implicitly required container POD           created             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Created with docker id 2e07f817cf2aabf7e55ee57447e65a4d8bc2ca164dce9ff6353b18163af76803
Wed, 04 Feb 2015 21:17:40 +0000   prometheus-push                                      BoundPod            implicitly required container POD           started             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Started with docker id 2e07f817cf2aabf7e55ee57447e65a4d8bc2ca164dce9ff6353b18163af76803
Wed, 04 Feb 2015 21:17:40 +0000   prometheus                                           Pod                                                             scheduled           {scheduler }                                                   Successfully assigned prometheus to kubernetes-minion-3.c.eternal-empire-754.internal
Wed, 04 Feb 2015 21:17:40 +0000   prometheus                                           BoundPod            implicitly required container POD           started             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Started with docker id f38347692abc3e75ff5652bb608bdde04cd08a990c2587ff5e917b2c0633f84f
Wed, 04 Feb 2015 21:17:40 +0000   prometheus                                           BoundPod            implicitly required container POD           created             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Created with docker id f38347692abc3e75ff5652bb608bdde04cd08a990c2587ff5e917b2c0633f84f
Wed, 04 Feb 2015 21:17:40 +0000   prometheus                                           BoundPod            implicitly required container POD           pulled              {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Successfully pulled image "kubernetes/pause:latest"
Wed, 04 Feb 2015 21:18:46 +0000   prometheus-push                                      BoundPod            spec.containers{prom-pushgateway}           started             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Started with docker id 83a4e9d913731cce6c6b6add9877aaa389c409965a80d026d50c212abcac9f8a
Wed, 04 Feb 2015 21:18:46 +0000   prometheus-push                                      BoundPod            spec.containers{prom-pushgateway}           created             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Created with docker id 83a4e9d913731cce6c6b6add9877aaa389c409965a80d026d50c212abcac9f8a
Wed, 04 Feb 2015 21:18:46 +0000   prometheus-push                                      BoundPod            spec.containers{prom-pushgateway}           pulled              {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Successfully pulled image "fish/prometheus-pushgateway"
Wed, 04 Feb 2015 21:19:55 +0000   prom-dash                                            BoundPod            spec.containers{prom-dash-db}               created             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Created with docker id a9f164c8264b2dd63f5788bc9a192ab32c519e7af41eea5614e82e5b9c1590ab
Wed, 04 Feb 2015 21:19:55 +0000   prom-dash                                            BoundPod            spec.containers{prom-dash-db}               pulled              {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Successfully pulled image "gcr.io/eternal_empire_754/core-prom-dash-db:latest"
Wed, 04 Feb 2015 21:19:55 +0000   prom-dash                                            BoundPod            spec.containers{prom-dash-db}               started             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Started with docker id a9f164c8264b2dd63f5788bc9a192ab32c519e7af41eea5614e82e5b9c1590ab
Wed, 04 Feb 2015 21:20:04 +0000   prometheus                                           BoundPod            spec.containers{prometheus}                 started             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Started with docker id 981ae37c7e2d71993e0439e4b955e0ef826684520938a6ad2cad52b03b83a6e0
Wed, 04 Feb 2015 21:20:04 +0000   prometheus                                           BoundPod            spec.containers{prometheus}                 pulled              {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Successfully pulled image "gcr.io/eternal_empire_754/core-prometheus-server:latest"
Wed, 04 Feb 2015 21:20:04 +0000   prometheus                                           BoundPod            spec.containers{prometheus}                 created             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Created with docker id 981ae37c7e2d71993e0439e4b955e0ef826684520938a6ad2cad52b03b83a6e0
Wed, 04 Feb 2015 21:21:11 +0000   prometheus                                           BoundPod            spec.containers{node-exporter}              started             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Started with docker id 84f3ebb3d0d650180deeb8568e6f9b9ddad07955c300917eb964d07b1faf8da9
Wed, 04 Feb 2015 21:21:11 +0000   prometheus                                           BoundPod            spec.containers{node-exporter}              pulled              {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Successfully pulled image "prom/node-exporter:latest"
Wed, 04 Feb 2015 21:21:11 +0000   prometheus                                           BoundPod            spec.containers{node-exporter}              created             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Created with docker id 84f3ebb3d0d650180deeb8568e6f9b9ddad07955c300917eb964d07b1faf8da9
Wed, 04 Feb 2015 21:21:41 +0000   prom-dash                                            BoundPod            spec.containers{prom-dash}                  started             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Started with docker id 9ed55637fa95cfef21daf59ae2fb221fa9c7e366160913428996d27714a1de10
Wed, 04 Feb 2015 21:21:41 +0000   prom-dash                                            BoundPod            spec.containers{prom-dash}                  created             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Created with docker id 9ed55637fa95cfef21daf59ae2fb221fa9c7e366160913428996d27714a1de10
Wed, 04 Feb 2015 21:21:41 +0000   prom-dash                                            BoundPod            spec.containers{prom-dash}                  pulled              {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Successfully pulled image "prom/promdash:latest"
Wed, 04 Feb 2015 21:33:40 +0000   prometheus                                           BoundPod            implicitly required container POD           killing             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Killing f38347692abc3e75ff5652bb608bdde04cd08a990c2587ff5e917b2c0633f84f - /k8s_POD.ebe10168_prometheus.default.api_3faea999-acb3-11e4-9b3d-42010af0f1f5_9e4499f8
Wed, 04 Feb 2015 21:33:40 +0000   prometheus                                           BoundPod            spec.containers{node-exporter}              killing             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Killing 84f3ebb3d0d650180deeb8568e6f9b9ddad07955c300917eb964d07b1faf8da9 - /k8s_node-exporter.708ae69c_prometheus.default.api_3faea999-acb3-11e4-9b3d-42010af0f1f5_d5b47239
Wed, 04 Feb 2015 21:33:41 +0000   prometheus                                           BoundPod            spec.containers{prometheus}                 killing             {kubelet kubernetes-minion-3.c.eternal-empire-754.internal}    Killing 981ae37c7e2d71993e0439e4b955e0ef826684520938a6ad2cad52b03b83a6e0 - /k8s_prometheus.88d40fd1_prometheus.default.api_3faea999-acb3-11e4-9b3d-42010af0f1f5_86124870
Wed, 04 Feb 2015 21:34:03 +0000   prometheus                                           Pod                                                             scheduled           {scheduler }                                                   Successfully assigned prometheus to kubernetes-minion-8.c.eternal-empire-754.internal
Wed, 04 Feb 2015 21:34:03 +0000   prometheus                                           BoundPod            implicitly required container POD           created             {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Created with docker id 3d3421caa75643055cd2335e4018c3baf1e0f924b3e00674c2e16434f98a9c58
Wed, 04 Feb 2015 21:34:03 +0000   prometheus                                           BoundPod            implicitly required container POD           pulled              {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Successfully pulled image "kubernetes/pause:latest"
Wed, 04 Feb 2015 21:34:03 +0000   prometheus                                           BoundPod            implicitly required container POD           started             {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Started with docker id 3d3421caa75643055cd2335e4018c3baf1e0f924b3e00674c2e16434f98a9c58
Wed, 04 Feb 2015 21:34:13 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:34:33 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:34:43 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:35:03 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:35:13 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:35:23 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:35:43 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:35:53 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:36:03 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:36:13 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:36:33 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:36:43 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:36:53 +0000   prometheus                                           BoundPod                                                        failedSync          {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Error syncing pod, skipping: Could not attach disk: Timeout after 10s
Wed, 04 Feb 2015 21:37:53 +0000   prometheus                                           BoundPod            spec.containers{prometheus}                 created             {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Created with docker id 2bd38f6305b6a714dc23d7ef8d1c7bda004db7827811d665ab49aaaa07e7561f
Wed, 04 Feb 2015 21:37:53 +0000   prometheus                                           BoundPod            spec.containers{prometheus}                 pulled              {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Successfully pulled image "gcr.io/eternal_empire_754/core-prometheus-server:latest"
Wed, 04 Feb 2015 21:37:54 +0000   prometheus                                           BoundPod            spec.containers{prometheus}                 started             {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Started with docker id 2bd38f6305b6a714dc23d7ef8d1c7bda004db7827811d665ab49aaaa07e7561f
Wed, 04 Feb 2015 21:38:44 +0000   prometheus                                           BoundPod            spec.containers{node-exporter}              pulled              {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Successfully pulled image "prom/node-exporter:latest"
Wed, 04 Feb 2015 21:38:44 +0000   prometheus                                           BoundPod            spec.containers{node-exporter}              created             {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Created with docker id 162e94ff66bb22136e53293b6827091fd68ca3ae30f19afa622afda901f0a20f
Wed, 04 Feb 2015 21:38:44 +0000   prometheus                                           BoundPod            spec.containers{node-exporter}              started             {kubelet kubernetes-minion-8.c.eternal-empire-754.internal}    Started with docker id 162e94ff66bb22136e53293b6827091fd68ca3ae30f19afa622afda901f0a20f

I'm going to try with a different container/pod just to be sure.

There are a couple more PRs in flight that might help fix this:
https://github.com/GoogleCloudPlatform/kubernetes/pull/4093
and
https://github.com/GoogleCloudPlatform/kubernetes/pull/4076
#4093 is merged into head
#4076 is on final approach...
--brendan
On Wed, Feb 4, 2015 at 2:53 PM, Steve Reed<EMAIL_ADDRESS>wrote:

I'm going to try with a different container/pod just to be sure.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-72957900
.

Those look nice, I'll push a build from master once #4076 lands in order to test this.

Nearly forgot, this does not seem dependent on the container I use.

Building kubelet off of master as I write this, and I'll copy it out to my minions (currently on 0.10.0) in a bit to test this out again. LMK if you'd rather have me test in a brand new cluster.

sgtm, let me know how it goes.
our e2e has been much cleaner with these two changes submitted...
i'm likely to cut them into a 0.10.1 today, esp. if we get confirmation
from you that it fixes your problems.
thanks
--brendan
On Thu, Feb 5, 2015 at 8:44 AM, Steve Reed<EMAIL_ADDRESS>wrote:

Building kubelet off of master as I write this, and I'll copy it out to
my minions (currently on 0.10.0) in a bit to test this out again. LMK if
you'd rather have me test in a brand new cluster.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-73079740
.

Success! Just deleted a pod, the disk was properly detached and unmounted. Re-created the pod and it ended up on a different minion, disk was attached correctly with all data intact.
@brendandburns

Awesome, great to hear (and sorry for the problems)
I will cut this into a 0.10.1 (along with
https://github.com/GoogleCloudPlatform/kubernetes/pull/4169 when it is
merged)
--brendan
On Thu, Feb 5, 2015 at 9:53 AM, Steve Reed<EMAIL_ADDRESS>wrote:

Success! Just deleted a pod, the disk was properly detached and unmounted.
Re-created the pod and it ended up on a different minion, disk was attached
correctly with all data intact.
@brendandburns https://github.com/brendandburns
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-73092973
.

Closing this for now, as user reports it fixed, please re-open if it re-occurs, and I will try to incorporate data read/write into a more extensive e2e test.

I'm seeing this behavior on two clusters I created today on Google Container Enginer. Deleting a pod manually does not detach the disk and deletes the files.
Blew away all of my data -- I was migrating from a persistentDisk in an older cluster. :scream: Luckily I had a backup.
$ gcloud preview container kubectl -n test-cluster version
Client Version: version.Info{Major:"0", Minor:"9+", GitVersion:"v0.9.1-dirty", GitCommit:"3623a01bf0e90de6345147eef62894057fe04b29", GitTreeState:"dirty"}
Server Version: &version.Info{Major:"0", Minor:"10+", GitVersion:"v0.10.0-dirty", GitCommit:"71e26cbeb9c0bf1b6cc4c29b1f9d930e53513911", GitTreeState:"dirty"}

Ugh!  Sorry about that!  Is this on 10.1?
I'll take another splunk through the code.  I was fairly certain we now
guard the remove call sites...
Brendan
On Feb 11, 2015 10:51 PM, "Max Goodman"<EMAIL_ADDRESS>wrote:

I'm seeing this behavior on two clusters I created today on Google
Container Enginer. Deleting a pod manually does not detach the disk and
deletes the files.
Blew away all of my data -- I was migrating from a persistentDisk in an
older cluster. [image: :scream:] Luckily I had a backup.
$ gcloud preview container kubectl -n test-cluster version
Client Version: version.Info{Major:"0", Minor:"9+", GitVersion:"v0.9.1-dirty", GitCommit:"3623a01bf0e90de6345147eef62894057fe04b29", GitTreeState:"dirty"}
Server Version: &version.Info{Major:"0", Minor:"10+", GitVersion:"v0.10.0-dirty", GitCommit:"71e26cbeb9c0bf1b6cc4c29b1f9d930e53513911", GitTreeState:"dirty"}
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-74025678
.

The server is running 71e26cbeb9c0bf1b6cc4c29b1f9d930e53513911 (which is what Google Container Engine created this evening), which appears to be after #3967 but doesn't include the fixes in #4093 and #4076. This is affecting my new clusters in production on GCE.

Ok, yeah we are in the process of getting 10.1 rolled out to GKE.  I hope
it will be out today.
Brendan
On Feb 11, 2015 11:50 PM, "Max Goodman"<EMAIL_ADDRESS>wrote:

The server is running 71e26cb
https://github.com/GoogleCloudPlatform/kubernetes/commit/71e26cbeb9c0bf1b6cc4c29b1f9d930e53513911
(which is what Google Container Engine created this evening), which appears
to be after #3967
https://github.com/GoogleCloudPlatform/kubernetes/pull/3967 but doesn't
include the fixes in #4093
https://github.com/GoogleCloudPlatform/kubernetes/pull/4093 and #4076
https://github.com/GoogleCloudPlatform/kubernetes/pull/4076. This is
affecting my new clusters in production on GCE.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/3965#issuecomment-74030618
.

I'm currently experiencing this problem as well.  I've tried "kubectl stop ... " and "kubectl delete ..." and had all of my persistent data erased when the pod that mounted it was stopped using either command.  Here is the output of "gcloud alpha container kubectl version" on my local system:
Client Version: version.Info{Major:"0", Minor:"15", GitVersion:"v0.15.0", GitCommit:"831f3e60d7cd64c61a775d6c78acce1673dd8aa9", GitTreeState:"clean"}
Server Version: version.Info{Major:"0", Minor:"16+", GitVersion:"v0.16.0-1-gfc76242f4afd2c", GitCommit:"fc76242f4afd2c7e41ae943f4f3f518f3df9377e", GitTreeState:"clean"}

@vardaofthevalier Hmm.. I was not able to reproduce this. Is it possible you are running into the issue fixed in #7503?


Please add: Error trapping of the (preview) rendering engine

Error trapping of the (preview) rendering engine (what makes the engine stumble), in my client's deployment we've identified they have one Word doc template that contains a page break that consistently breaks the rendering)

Hey @JP-WHO,
As discussed, the rendering engine is part of SF core and we are delegating to the preview screen beyond the File Explorer boundary. I believe you raised a ticket to SF support direct to address this?
ta
Paul


Add SHELL_PLUS_PRINT_SQL option

Add the configuration option  SHELL_PLUS_PRINT_SQL equivalent to command line option --print-sql.

Coverage decreased (-0.4%) to 35.783% when pulling b86015e8b67775dae4501e37d656f5d9859c7bf4 on yasuyk:print-sql-option into cb0445ab45fe4d5ab9dcba2ee8b3f4bd0d833080 on django-extensions:master.

Could you please update the documentation as well ?

Coverage decreased (-0.4%) to 35.783% when pulling 83436389ecc9251fef0a5056445e398bdda863ca on yasuyk:print-sql-option into cb0445ab45fe4d5ab9dcba2ee8b3f4bd0d833080 on django-extensions:master.

@trbs Updating the documentation is done.

great thanks !

@trbs Thank you for merging! 😄

No problem, hope to have a new release out next week.


I was wondering if I am allowed to add the site.

Thank you for asking. I suppose I would prefer not to and keep the list "clean".


[Bug]: Dashboard doesn't register DataSciencePipelinesApplication (DataScience server) with different names than pipelines-definition

Is there an existing issue for this?

[X] I have searched the existing issues

Deploy type
OpenDataHub core version (eg. v1.6.0)
Version
incubation (2.4.0)
Current Behavior
When I create DataPipelines server via CR (DataSciencePipelinesApplication) and it doesn't have name pipelines-definition the dashboard doesn't show it and user still has to create new one to run DataSciencePipelines.__### ###
Expected Behavior
Dashboard will register every DataSciencePipelinesApplication or the operator will not reconcile the ones without proper naming -> proper documentation should be available.
Steps To Reproduce

Deploy ODH
Deploy DSC - https://github.com/skodjob/deployment-hub/blob/main/open-data-hub/install/data-science-cluster.yaml
Create DataScienceProject and DataSciencePipelinesApplication with different name than pipelines-definition

Workaround (if any)
No response
What browsers are you seeing the problem on?
No response
Anything else
No response

Yeah, this is something we are aware of... there are big changes coming in v2 of Pipelines, I imagine we will address this part of that effort.
The effort has been moved to Jira: https://issues.redhat.com/browse/RHOAIENG-331

Great, thanks for the info!

@andrewballantyne Can you move it to Jira please?

Moved to Jira under the v2 DS Pipelines effort.
https://issues.redhat.com/browse/RHOAIENG-945


Provide suggestion when stack file is missing

If any commands are run which relate to stack, but a stack file isn't present, prompt the user to create a new stack.
commands:

nitric stack up
nitric stack down
nitric stack list maybe not this one?
all aliases of the above (e.g. nitric up)

The output should be something like this:
No stacks were found for the current project. If you haven't created one yet run `nitric stack new`.

done here: https://github.com/nitrictech/cli/blob/develop/pkg/stack/options.go#L53


New example, VM with Nvidia extension based on condition

New example, creating a VM with an VM extension that installs the NVidia GPU Drivers based on an condition.

Tests are failing - looks like you need to rerun bicep build on at least on of the files. Also, just to confirm there is more than one example in this PR. Is that intentional?

@alex-frankel, no I intended to only add single Bicep+json example, I will create a new PR

Tests are failing - looks like you need to rerun bicep build on at least on of the files. Also, just to confirm there is more than one example in this PR. Is that intentional?


tree 开启roam鼠标缩放和平移漫游，点击节点时，如何将点击的节点移到居中位置。好像并不能获取到节点相对树图的距离吧

What problem does this feature solve?
聚焦点击的节点展开
What does the proposed API look like?
支持动态居中

see #20098  #18961

参见#20098  #18961

是tree，不是treemap哦

参见#20098  #18961

是tree，不是treemap哦

clicked tree node to center - Demo.
📌 please close issue if problem solved.

clicked tree node to center - Demo. 📌 please close issue if problem solved.

clicked tree node to center - Demo. 📌 please close issue if problem solved.

nb,解决了十分感谢


Lines.RMatrix, Lines.XMatrix and Lines.CMatrix don't get correct value when using line geometry

Let's say I have the following file:
Clear

new circuit.TestFeeder
~ basekv=4.16 pu=1.0000 phases=3 bus1=SourceBus
~ Angle=0
~ MVAsc3=200000 MVASC1=200000

New Line.sourcedestination Units=km Length=1 Bus1=SourceBus.1.2.3 Bus2=DestinationBus.1.2.3 phases=3

Solve

If I change Length=1 to Length=0.5, I get the same value for RMatrix. This is expected, since RMatrix returns the rmatrix per unit length.
julia> dss("Redirect ./test.dss"); # length = 1

julia> Lines.RMatrix()
3×3 Array{Float64,2}:
 0.0981333  0.0401333  0.0401333
 0.0401333  0.0981333  0.0401333
 0.0401333  0.0401333  0.0981333

julia> Properties.Value("rmatrix")
"[0.09813333 |0.04013333 0.09813333 |0.04013333 0.04013333 0.09813333 ]"

julia> dss("Redirect ./test.dss"); # length = 0.5

julia> Lines.RMatrix()
3×3 Array{Float64,2}:
 0.0981333  0.0401333  0.0401333
 0.0401333  0.0981333  0.0401333
 0.0401333  0.0401333  0.0981333

julia> Properties.Value("rmatrix")
"[0.09813333 |0.04013333 0.09813333 |0.04013333 0.04013333 0.09813333 ]"

However, if I have the following file:
Clear

new circuit.TestFeeder
~ basekv=4.16 pu=1.0000 phases=3 bus1=SourceBus
~ Angle=0
~ MVAsc3=200000 MVASC1=200000

New WireData.Wire_336.4_aac_oh GMRac=0.006400800000000001 GMRunits=m Diam=0.0169164 Radunits=m normamps=515.0 emergamps=595.0 Rac=0.00020666857220972575 Runits=m

New LineGeometry.Geometry_1 Nconds=4 Nphases=3 Units=ft Cond=1 Wire=Wire_336.4_aac_oh X=0.0 H=38.9 Normamps=515.0 Emergamps=595.0 Cond=2 Wire=Wire_336.4_aac_oh X=3.5 H=38.9 Normamps=515.0 Emergamps=595.0 Cond=3 Wire=Wire_336.4_aac_oh X=10.0 H=38.9 Normamps=515.0 Emergamps=595.0 Cond=4 Wire=Wire_336.4_aac_oh X=5.2 H=35.0 Normamps=515.0 Emergamps=595.0 Reduce=y

New Line.sourcedestination Units=km Length=0.5 Bus1=SourceBus.1.2.3 Bus2=DestinationBus.1.2.3 phases=3 geometry=Geometry_1

Solve

And if I change Length=1 to Length=0.5, I get the following:
julia> dss("Redirect ./test.dss"); # length = 1

julia> Lines.RMatrix()
3×3 Array{Float64,2}:
 0.269308   0.0686486  0.0664062
 0.0686486  0.274694   0.0689824
 0.0664062  0.0689824  0.269908

julia> Properties.Value("rmatrix")
"[0.2693081 |0.06864857 0.2746939 |0.06640624 0.06898236 0.2699083 ]"

julia> dss("Redirect ./test.dss"); # length = 0.5

julia> Lines.RMatrix()
3×3 Array{Float64,2}:
 0.134654   0.0343243  0.0332031
 0.0343243  0.137347   0.0344912
 0.0332031  0.0344912  0.134954

julia> Properties.Value("rmatrix")
"[0.2693081 |0.06864857 0.2746939 |0.06640624 0.06898236 0.2699083 ]"

Here, RMatrix is not per unit length but the actual RMatrix. This results in subtle hard to identify bugs.
I'm not sure why the Version is returning unknown but I'm using the latest tagged version of OpenDSSDirect.jl.
julia> Basic.Version()
"DSS C-API Library version DEV revision UNKNOWN based on OpenDSS SVN UNKNOWN (v7/classic variation) MVMULT (64-bit build);
License Status: Open "

The same issue happens in the official version, it's one more inconsistency (probably bug) in the Lines interface. I think the best would be to document all of the issues with the line interface, report to EPRI, and hope it's addressed there first (I can probably provide a patch too).
Otherwise, I see a couple of less desirable scenarios:

Create a new Lines interface to fix most of the issues we saw so far. Use this new interface by default, but add a switch to toggle the official behavior; or
Keep as is, but document every inconsistency. Not very fun from the user's point of view

I'm not sure why the Version is returning unknown but I'm using the latest tagged version of OpenDSSDirect.jl.

Could you test if that's fixed in https://github.com/dss-extensions/OpenDSSDirect.jl/pull/60?

Almost there: https://sourceforge.net/p/electricdss/code/3175/ 🙂

Here, RMatrix is not per unit length but the actual RMatrix. This results in subtle hard to identify bugs.

Nowadays, when using LineGeometry, both lines return the same matrix.
Still, some of the behavior of the line impedance properties can be somewhat confusing. I think adding either adding an option/property to return the effective impedance or to convert the all lines may be useful for some analysis. This would remove a lot of work for users that just want to export the impedances to use in another method/software. Currently Yprim could be used but it's not exactly the same.


Who is core team packages? And where are the docs? This needs a Wiki.

I have these packages that I no longer use, e.g. Ext2Explore, or partition tools, which have apparently too many users who keep bugging me for updates.
So I thought, nice packages for Core Team packages. But the process is vague. All the repo says is this:

These packages are managed by the chocolatey core team. To get a package added here, the official Chocolatey Account has to have push access to the package on chocolatey.org.

So I added the chocolatey user, but basically the feedback I get is:

This is not a dumping ground for offloading packages that folks are no longer interested in maintaining.

However, for my package KeePassX I was approached by someone advising me to put it on core team packages because I don't update fast enough.
So how does this work? Is the process of packages that get or would get accepted arbitrary? Subjective to the people that are "in" the core team?
This needs a wiki with clear instructions on how to get a package nominated, accepted, added, how to transfer the package, how to transfer the package source code, if and how to request help when your package is not an autopackage, etc.
For now, for some of the most popular packages I have found some random other users who were willing to host the autopackage. But in the light of trustworthiness and the future plan of trusted certificates for package maintainers, the core team would me a safer bet.
Also, who are the core team members?

TomOne
gep13
ferventcoder

I'm not particularly interested in (icons of) old versions, but since the team urges me to go the extra mini-mile, I feel like adding my second two cents:
I'm not sure depending on GitHub's CDN for old icon versions is a sturdy solution. If we lose GitHub or their CDN, or if we want to cater to countries where GitHub is blocked off and on, like Russia, it will be a tedious task to rebuild the history of icons for each package, and it would require manual labor to make these icons available on some other CDN. It's better to have full the icon history available in a file (version) tree in HEAD. This would make the icon base more sturdy and portable.

I would like to know who has access to the ketarin machine.
What needs to be done from a pullrequest to having the package aumatically updated through chocolatey?
We need someone with that power to take a few moments to look over the pending PR's and merge/fix/add them.

 This is becoming a problem because no one (including new users) is motivated to make fixes anymore if they are never merged.

Currently, me, Rob and Tom have access to this machine, but we can certainly have a chat about opening this up to a wider group.
@ferventcoder do you have a script for auto importing xml files into ketatin on each execution, so as to ensure most up to date configuration after the pull?
Sent from my Windows Phone

From: Sander AKA<EMAIL_ADDRESS>Sent: 16/10/2015 20:30
To<EMAIL_ADDRESS>Cc: Gary Ewan<EMAIL_ADDRESS>Subject: Re: [chocolatey-coreteampackages] Who is core team packages? And where are the docs? This needs a Wiki. (#20)
I would like to know who has access to the ketarin machine.
What needs to be done from a pullrequest to having the package aumatically updated through chocolatey?
We need someone with that power to take a few moments to look over the pending PR's and merge/fix/add them.

 This is becoming a problem because no one (including new users) is motivated to make fixes anymore if they are never merged.

Reply to this email directly or view it on GitHub:
https://github.com/chocolatey/chocolatey-coreteampackages/issues/20#issuecomment-148813317

@gep13 can you tell me the exact code the ketarin machine uses for all the batch jobs?
And where do you put this global code in stead of per-package code?

@Redsandro sorry, I am not clear on what you are asking for.  Are you talking about the scheduled task that is running on the ketarin machine to execute ketarin every hour?

Yes - I think.
I think it was you - but don't be angry if I'm mistaken - who told me that in this repository, ketarin settings for packages need no execution commands. There is a one size fits all command. It's probably documented somewhere, but not in this repo.
I want that command so I can tell, if it works in a VM, it will work on the ketarin machine.

Ah, I see what you are getting at.  :smile_cat:
Yes, on the Ketarin instance, there is a global execute command that runs for all packages that are contained within the Ketarin instance.
This is the command:
chocopkgup /p "{appname}" /v "{version}" /u "{preupdate-url}" /u64 "{url64}" /pp "{file}"

@gep13 Really? It uses the preupdate-url? That's always the one in the URL field in the download source, right? So if we need to regex, we need to regex a variable and put that variable in the URL field?

Really? It uses the preupdate-url? That's always the one in the URL field in the download source, right? So if we need to regex, we need to regex a variable and put that variable in the URL field?

Sorry, I am not exactly clear on what you are referring to.  Can you elaborate?  This might not be the optimal way of doing this.  Perhaps @TomOne or @dtgm might be able to help with this.
This is the way that this Ketarin machine has been set up for almost two years.

@gep13 thank you for pointing the commands out. Now I get what's going on. :smile:
As for the "preupdate-url", I mean that the url is actually not a value called url (like url64 is a value called url64, but rather the contents of the download url field in the ketarin package settings. This is a bit misleasing and I never understood this until just now.

@Redsandro said...
This is a bit misleasing and I never understood this until just now.

Ok, cool, sounds like everything is in order then, right?

Yes, all is clear!

I know who have access to the ketarin machine now. I think this issue can be closed.

I do have a script that auto updates ketarin by importing all ketarin scripts in a particular directory. So I only have to merge.

@ferventcoder do you have a link to that script, so that we can put that on the Ketarin machine? Thanks!

Should implement some sanity checking.
How are (previously working) broken packages detected now?
Does ketarin do something like info>stdout error>stderr? It would be nice to pipe the output log of only the errors to some website where we can see packages that need fixing.

Does ketarin do something like info>stdout error>stderr? It would be nice to pipe the output log of only the errors to some website where we can see packages that need fixing.

Not as far as I'm aware.

@gep13 the script is at https://github.com/ferventcoder/chocolatey-packages. I'm starting you there so you can see that all of the ketarin.xml files have been extracted to a singular folder, like @dtgm has done. Then inside of there is a files directory that contains this gem - https://github.com/ferventcoder/chocolatey-packages/blob/master/ketarin/files/ketarinupdate.cmd
The version of ketarin needs to be the latest or it will stay open after import.

@ferventcoder perfect thanks, I will take a look, and let you know if I run into any problems. Cheers!

@gep13 the really nice thing about this script is that I can set it on a new machine and it will import all of the jobs into ketarin.

@ferventcoder agreed.  That has always been my concern about the "portability" of the current ketarin machine we are using.

@gep13 We don't even have to change the structure.
iirc you can look one level deep in subfolders using FOR /D %%F IN, or recursively through all folders (probably some overhead because of all the tools directories) using FOR /R.

@Redsandro although we "might" be able to do something, I think there is something to be said for consistency.  If this is what both @ferventcoder and @dtgm have opted for, I think we should follow their lead.

@gep13 while I agree consistency is an important thing, I also like to point out that things like Javascript, ES, HTML5 and the likes wouldn't exist if we all just went for consistency rather than improvement.
The best approach to any kind of package - for clarity, portability and maintainability's sake - is always to have it as self-contained as possible.
For that reason, the fact that we chose to separate icons from packages in their own icons directory is something of a bad decision in that regard.
If we now introduce a third location we need to take into account for package maintenance, we're just going against common sense.
Just my two cents. I will play along either way.

More of keeping the ketarin.xml file away from the autopackage so it doesn't get sucked up by the generating tool. But that can be addressed in other ways.

And for the sake of argument that the ketarin bit isn't really part of the package - which is a fallacy, it is part of what builds the package.

.gitignore, Gruntfile.js, thumbs.db GMTA :wink:


remove -network flag

By removing this flag, #64 will be resolved. Not sure what impact this has on other OSes outside of macOS.

Hey Ellisio,
I fixed it already. But thanks for the help and this PR.


Problem with fulfillment

Hi Mish,
I get the following error in my fulfillment.
Any clue what's going on?
TypeError: Cannot read property 'source' of undefined
    at V2Agent.processRequest_ (/user_code/node_modules/dialogflow-fulfillment/src/v2-agent.js:108:86)
    at new WebhookClient (/user_code/node_modules/dialogflow-fulfillment/src/dialogflow-fulfillment.js:201:17)
    at exports.dialogflowFirebaseFulfillment.functions.https.onRequest (/user_code/index.js:17:19)
    at cloudFunction (/user_code/node_modules/firebase-functions/lib/providers/https.js:37:41)
    at /var/tmp/worker/worker.js:686:7
    at /var/tmp/worker/worker.js:670:9
    at _combinedTickCallback (internal/process/next_tick.js:73:7)
    at process._tickDomainCallback (internal/process/next_tick.js:128:9)

Regards,
Thomas

Make sure your fulfilment is properly connected via Dialogflow and the code is fine, I tested it with my fulfilment, got no error
Also note, that the client libraries sometimes have no connection to server, because of Google making updates!

@MishUshakov Still getting errors.
Im using Dialog fulfilment inline editor.
Errors:
TypeError: Cannot read property 'source' of undefined     at V2Agent.processRequest_ (/user_code/node_modules/dialogflow-fulfillment/src/v2-agent.js:108:86)     at new WebhookClient (/user_code/node_modules/dialogflow-fulfillment/src/dialogflow-fulfillment.js:201:17)     at exports.dialogflowFirebaseFulfillment.functions.https.onRequest (/user_code/index.js:13:19)     at cloudFunction (/user_code/node_modules/firebase-functions/lib/providers/https.js:37:41)     at /var/tmp/worker/worker.js:686:7     at /var/tmp/worker/worker.js:670:9     at _combinedTickCallback (internal/process/next_tick.js:73:7)     at process._tickDomainCallback (internal/process/next_tick.js:128:9)
My fulfilment code:
const functions = require('firebase-functions');
const firebaseAdmin = require('firebase-admin');
const {WebhookClient} = require('dialogflow-fulfillment');
const {Card, Suggestion} = require('dialogflow-fulfillment');

process.env.DEBUG = 'dialogflow:debug'; // enables lib debugging statements

exports.dialogflowFirebaseFulfillment = functions.https.onRequest((request, response) => {
    const agent = new WebhookClient({ request, response });
    const reqBody = request.body;
    console.log('Dialogflow Request headers: ' + JSON.stringify(request.headers));
    console.log('Dialogflow Request body: ' + JSON.stringify(reqBody));

    function testFunctionHandler(agent){
        agent.add(new Card({
                title: `Je nieuwe wachtwoord is:`,
                imageUrl: 'https://developers.google.com/actions/images/badges/XPM_BADGING_GoogleAssistant_VER.png',
                buttonText: 'Klik hier om in te loggen',
                buttonUrl: 'google.com  '
              })
            );
    }

    let intentMap = new Map();
    intentMap.set('Test intent', testFunctionHandler);

    agent.handleRequest(intentMap);

});

And screenshots:

@thomasgcompany does your service-worker work/load?
because mine doesn't.
console showing me this:
The script has an unsupported MIME type ('text/x-js').
Failed to load resource: net::ERR_INSECURE_RESPONSE
(index):1 Uncaught (in promise) DOMException: Failed to register a ServiceWorker: The script has an unsupported MIME type ('text/x-js').
so the fulfillment is not working on my own domain,
but it is working on facebook's messenger and dialogflow test dialog in the console.

@kimneu  im not really sure what you mean but this is the output of my console.
Do you think there is a problem in my code?
Could you give me an example fulfilment code that does work?

Hi Guys,
I tried with the example fulfillment but no luck:
It gives me errors on:
const agent = new WebhookClient({ request, response });
https://github.com/dialogflow/dialogflow-fulfillment-nodejs/blob/master/samples/quick-start/functions/index.js
I would be very happy if you could help me figure out whats the problem.
Regards,
Thomas

hey @thomasgcompany
so basically I have the same problem, I think.
my thought was, that it could have something todo with the service-worker.js, since I have troubles loading this file on my live version. but in the end, why should the webhook / fulfillment be affected by the service-worker. 🤷♂

@kimneu Yes you have the same problem!

@thomasgcompany  @kimneu honestly i doesnt know what you are talking about, do you use V2 API?

Any examples/guides on how to implement fulfillment?

Yes! I just switched from V2 to V1 and then I don't get errors but it does not show a card.
Do you require API V2 or V1?
If you require V1 can I help upgrade the code to use the V2 API?

@MishUshakov
Sorry thomas-vl is my private account...
I think its not wise to try and rebuild the entire ApiAiClient library.
I can just rewrite everything that uses the Library to use the reset api.
Do you want to create a different branch for the V2 development?
Regards,
Thomas

@thomasgcompany
Yep, just fork the lib and create your REST client(I recommend using fetch API) if you want, shouln't be hard I think :D
Thank you for your investigation ❤

@MishUshakov,
I think we have to stick to v1 for a while unless you have some brilliant idea how to get oAuth 2.0 with service account done in javascript.
See the guide:
https://dialogflow.com/docs/reference/v2-auth-setup
Regards,
Thomas

@thomasgcompany check this https://developers.google.com/identity/protocols/OAuth2UserAgent

@MishUshakov Yes, that does only do Login oAuth to authenticate a user or oAuth1.0 with a token.
We need this one https://developers.google.com/identity/protocols/OAuth2ServiceAccount
There are a couple of ways to move forward:
Build a serverside controller to run all the API requests and host the complete thing on App Engine
Build a Cloud Function to handle authentication, send the Token to the the client and make the API requests Client side.

@thomasgcompany yeah, actually I doesn't want to build a whole OAuth 2.0 server for just authentication, in many ways it can be insecure and it also will cost addition money to serve. I will try to find other ways to connect V2 Projects into web apps, because for me as developer it is a frustrating experience if the standard javascript library from dialogflow, which I use can not handle V2.
I will have to wait for a stable dialogflow JS-Client release, which supports the service accounts and V2 etc.
Thank you for your support on this question 👍

@thomasgcompany sorry to chip in so late, but did you get the fulfillment working on the web?
i still have this issue, using V1. can't get my head around why..


Move label and milestone checks on github

What does this PR do?
Move label & milestone tests from circleci to github to benefit from appropriate events detection.
These checks are now run only at PR creation and modification of labels and/or milestone (AND not more on new commits on the PR)

Motivation
Do not need to manually restart the job in case we missed to update labels or milestones at PR creation. Relates to #21566

Additional Notes
Here are the different tests:

for labels
for milestone

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided. Except if the qa/skip-qa label, with required either qa/done or qa/no-code-change labels, are applied.
[ ] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[ ] If applicable, the config template has been updated.

/merge


editor starts with broodlings

the editor spawns as zerg and kills all units.  However, when killing the zerg units, broodlings are spawned which are left to the user to delete or wait until their duration ends and they die automatically.

Initial broodlings from hatchery are auto removed.


Erroneous METOC Symbols

This issue is supporting symbols for 2525D
From @csmoore on October 2, 2015 11:59
While @Dbarnes1 was testing (creating a test dataset for METOC points, lines, and areas ), he found this set of symbols that should be fixed/improved :

Fixed
SIDC
Name
Feature Type

- [X]
45110505
Pressure Systems-Pressure Tendency-Steady
Atmospheric Point

- [X]
46110304
Ice Systems-Dynamic Processes-Ice Drift (Direction)
Oceanographic Point

- [X]
46120310
Hydrography-Ports and Harbors- Fish Wiers (Point)
Oceanographic Point

- [X]
46120506
Hydrography-Dangers/Hazards-Kelp/Seaweed (Point)
Oceanographic Point

- [X]
45110401
Pressure Systems-Lines-Trough Axis
Atmospheric Line

- [X]
45110408
Pressure Systems-Lines-Convergance Line
Atmospheric Line

- [X]
45180700
Isopleths-Operator Defined-Freeform
Atmospheric Line

- [X]
46120512
Hydrography-Dangers/Hazards-Reef
Oceanographic Line

- [X]
45162004
Weather Symbols-Tropical Storm Systems-Tropical Storm Wind Areas and Date/Time Labels
Atmospheric Area

- [X]
46120507
Hydrography-Dangers/Hazards-Kelp/Seaweed (Area)
Oceanographic Area

- [X]
45170200
Bounded Areas of Weather - Marginal Visual Flight Rule (MVFR), (Area)
Atmospheric Area

Link to original comment
Open the attribute table of test dataset linked for a full description of the issue with that symbol.
Copied from original issue: Esri/military-features-data#146

45110202 - seems fixed
110505 - symbol is blue, should be black
110304 - seems correct to me

@lfunkhouser - Just wanted to verify that Pro 2.1/CIM2.1 is the earliest version that uses the 2525D stylx?
Checking in order to know what version of Pro to use for making edits to the stylx.

@csmoore - I'm editing the 2525D stylx using Pro 2.0 - that is working fine, but I find that I cannot edit the mil2525d-lines-areas-labels-base-template.stylx using Pro 2.0

@BobBooth - this makes sense - it looks like this style ( mil2525d-lines-areas-labels-base-template.stylx )  was updated (from Pro 1.2) to Pro 2.1 in this PR 330 (also links to issue 297 in that repo) - if the repo should be targeting Pro 2.0 instead we can probably go back to that commit and upgrade to 2.0 instead). Things could get a bit confusing if app6d targets Pro 2.1 and mil2525d targets 2.0 so we may need a different approach for this file.

@csmoore - Probably it was just my decision to go with 2.0 that is wrong.  I will upgrade to Pro 2.1 and continue.

120200 - Bounded Areas : Marginal Visual Flight Rule (MVFR)

Looking at this issue closer we need to move the following two issues into thier own issue to allow this issue to be closed. The two issues that can be put into seperate issue are:
45110202	Pressure Systems-High Pressure Center-Tropopause High	Atmospheric Point
45171000	Bounded Areas of Weather-Operator Defined-Freeform	Atmospheric Area

@BobBooth please create those issues.

@topowright - I've pulled those two out into these two issues
https://github.com/Esri/military-symbology/issues/294
https://github.com/Esri/military-symbology/issues/295

To test, get the mil2525d.stylx from the repo and copy to C:\Program Files\ArcGIS\Pro\Resources\Dictionaries\mil2525d
Open the METOCall.ppkx (attached as a zipfile)
METOCall.zip
Find the symbol in the appropriate "issues" sub-layer, zoom to it, and verify that it is now drawing correctly.

@topowright - I think I fixed https://github.com/Esri/military-symbology/issues/295, you can test that one too.

This will be moved to no count. Each symbol issue now is being tracked in separate issues.


[Draft] - Add a chapter to help users configure USS

Is there a related issue for this PR?
Issue number: #1195

@NayerNajafi - i've written this chapter in draft mode - I've never set up USS before so this is mostly information that a customer told us on their prez.    Can you take a look and add more info to how to set up Java HEAP correctly,  information on OMVS segment site (I believe you've run into problems with customers where you needed to increase that) and all the other great nuggets you'v'e collected while you've supported Zowe customers and we can build up this chapter over time.   Feel free to just commit to the branch directly any updates you have

Hi @Joe-Winchester I've started providing/adding some information about OMVS segment and what user needs to consider while installing Zowe. The draft work is https://github.com/zowe/docs-site/pull/1228
Once completed, i will send for your review.
Thanks!

@NayerNajafi - many thanks for your PR to the branch.  I've merged your changes and made a few formatting edits.  I can't add you as a formal reviewer because github knows you are one of the PR authors, but could you take a quick look to make sure it still reads well, and once you're happy then @nannanli can do a final check and hopefully this can get into 1.12 which will be great.

@Joe-Winchester sounds good to me. Thanks!

@NayerNajafi @Joe-Winchester I edited this topic and added it to the TOC/left-hand navigation. Please review the latest one.

@nannanli - this looks really good and thank you for adding it to the pages.json so it appears on the left hand bar.

@nannanli Thanks Ashley!


Write a Java program to find sum of numbers

Description
Write a Java program to find sum of numbers
Input  : 1 2 3 4 5
Output : 15

How to contribute

Save the solution in FindSumOfNumbers.java file
Add FindSumOfNumbers.java file in find-sum-of-numbers folder

!assign


[Expedidor] Use ember-metrics to send stats to our Matomo server

Addon URL: https://github.com/poteto/ember-metrics

Replicate this https://github.com/tpportugal/tpp_registo_de_feeds/commit/951442be80bb56ed29370405368997f6c39924c0


Update icu pin

Substitutes https://github.com/conda-forge/texlive-core-feedstock/pull/9

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

OS X is failing with:
aking all in texk
Making all in .
=== configuring in web2c (/Users/travis/miniconda3/conda-bld/recipe_1486330273206/work/texlive-20160523-source/tmp_build/texk/web2c)
configure: error: Sorry, could not find X include and library files required for Metafont.
=== configuring in web2c failed
make[2]: *** [recurse] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
Traceback (most recent call last):

Full log: https://travis-ci.org/conda-forge/texlive-core-feedstock/builds/198658582
Merging this as is and working on the OS X issue later.


Crash on rpc error(s)

Should probably gracefully handle this:
thread 'tokio-runtime-worker' panicked at /home/runner/work/helios/helios/execution/src/evm.rs:76:47:
called `Result::unwrap()` on an `Err` value: rpc error on method: get_proof, message: Deserialization Error: invalid type: string "too many requests, we recommend you to use free api key", expected struct JsonRpcError at line 1 column 67. Response: {"error": "too many requests, we recommend you to use free api key","id":39, "project": "11307768e6d77951256a33cc9abd40851f6f5ce8"}

Location:
    execution/src/rpc/http_rpc.rs:54:30
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped)

Ah yeah that is a good idea. We do handle retries right now via ethers but it seems depending on what type of RPC provider you are using it may fail. We should add a fallback retry in case ethers retries blows up.

Is this still open?

adding that im currently observing an intermittent panic, presumably caused by alchemy on base throwing get_proof errors. Here's what it looks like:
2024-12-08T15:42:50.345212Z  INFO helios_opstack::consensus: unsafe head updated: block=23441611 age=1s
2024-12-08T15:42:52.477125Z  INFO helios_opstack::consensus: unsafe head updated: block=23441612 age=1s
thread 'tokio-runtime-worker' panicked at /home/runner/work/helios/helios/core/src/execution/evm.rs:69:47:
called `Result::unwrap()` on an `Err` value: rpc error on method: get_proof, message: server returned an error response: error code -32602: distance to target block exceeds maximum proof window

Location:
    /home/runner/work/helios/helios/core/src/execution/rpc/http_rpc.rs:58:30
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped)


Update npm dependencies based on npm audit results

Please update npm dependencies based on npm audit results

I think that all relevant information is included.


Plugin not finding test assembly

When I try to run the tests, I get an error:
Unable to run xUnit.net tests - File not found \artifacts\bin\Tests\Tests.dll
This is the contents of artifacts\bin\Tests folder after build:
\artifacts\bin\Tests\Debug\dnx451\Tests.dll
\artifacts\bin\Tests\Debug\dnx452\Tests.dll
\artifacts\bin\Tests\Debug\dnxcore50\Tests.dll

DNX isn't supported right now. We're hoping to get this into ReSharper 10.1, although it also depends on timing with DNX/dotnet-cli releases. I'm closing this in favour of #38


diff everything on removal

In our CI/CD we're running the command diff-quality --violations sqlfluff --compare-branch=master --fail-under=100 on version 7.7.0 on a branch that has only deleted/removed files. We have hundreds of files. Normally, if any file is modified or added, diff-quality only checks those files and takes several seconds. When the branch only has removals it's scanning everything and taking 40 minutes.

interesting, ill have to find some time to see if I can reproduce this and see whats up

An update: This issue is non-deterministic.
Scenario: We have a file that would fail a lint/violation check, but it shouldn't be scanned in our given scenario. I've confirmed via git diff --name-only master the file failing is not present, only the removed files are. My expectation is diff-quality would pass 0 files to the violations tool. (as I write this, I realize I'm making some assumptions on how the interaction between diff_cover and the sqlfluff plugin might work)
When attempting to replicate locally, my first attempt running diff-quality passed. I re-traced my steps to ensure I did the same thing as CI/CD and got it to fail on the file that wasn't modified. I then re-ran the exact same command listed in my first comment 5 times in succession. The result was 4 failures and 1 pass.

Upgraded to 8.0 with same result. Using Python 3.9.9.

So its not immediately obvious to me why diff cover would be acting differently on removed files.
the basic algorithm is
run the quality tool command over the project
Run
'git -c diff.mnemonicprefix=no -c diff.noprefix=no diff --no-color --no-ext-diff -U0 origin/main...HEAD'
compare the lines reported the quality tool to the lines in the diff.
Now, I do think sql fluff is a bit different in that it runs over each and every file. https://github.com/sqlfluff/sqlfluff/blob/9579127595333037aa893adb4384d7612c32e0ed/src/sqlfluff/diff_quality_plugin.py#L63
@barrywhart do you have any insight on anything on this issue?
@cboden do you have an example repo we can use to debug this at all? Also the branch with the deleted files. Can you share if its a ton of deleted files? Or just s small number?

No immediate insights, but I see that the SQLFluff plugin logs the SQLFluff command before running it. It may be helpful to look at that.
One random thought (no evidence, just brainstorming) -- is it possible it's running SQLFluff against one or more directory paths, hence processing all the files in that directory?

Two more thoughts:

A sample repo would definitely be useful. I can't help but wonder if the user's repo or their git installation is corrupted somehow.
Maybe the core diff-quality command (not using SQLFluff plugin) has the same issue. As they say, "absence of evidence is not evidence of absence." From this code, it's clear that both branches (batch or non-batch handling) process src_paths_changed.

do you have an example repo we can use to debug this at all? Also the branch with the deleted files. Can you share if its a ton of deleted files? Or just s small number?

It's a small number and is happening on every PR we open like it. The latest PR had the following changes to a dbt repository:

33 line .sql file removed
15 lines removed from a medium sized .md file
40 lines removed from a medium sized .yml file
5 lines removed from a huge .yml file

My guess is that this is not a bug; that the repo is corrupted somehow.

My guess is that this is not a bug; that the repo is corrupted somehow.

How can we test/confirm this? How would a corruption apply to diff_cover or sqlfluff?

Run the same git command that diff-cover uses and see if it includes more files than it should.

I've confirmed via git diff --name-only master the file failing is not present, only the removed files are.

Is there another git command I should test?


⚠ GitLab Server has degraded performance

In 4373170, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 7004 ms

Resolved: GitLab Server performance has improved in 655e156.


megamenu support

Megamenu support for chaise navbar is intended to extend the current navbar dropdown implementation to be more similar to recent web page styles. One example can be found at https://viterbischool.usc.edu/. When you hover over the "About" or "Academics" navbar option, a megamenu shows under the navbar with all the options and suboptions shown to the user.
In our case, we want this to be able to support any number options in each navbar menu and any number of nested menus. We need it to be flexible to cover all cases. One thing to also consider is the responsiveness of this menu when the screen is smaller or wider. How does it change when there are a lot of options available in a tiny amount of screen space?
Another important piece is to allow this to be customizable. Classes or identifiers should be used in appropriate places so each deployment can customize the megamenu the way they want to.
Here is a good reference to learn from Nielsen Norman Group.
https://www.nngroup.com/articles/mega-menus-work-well/

FWIW, I've looked at a few megamenus, and I think the implementation makes a big difference for usability. The two factors that the good menus seem to have are requiring a click to open the menu and having strong visual clues that you're looking at a menu and haven't just navigated to a different page.
Bad example: https://osteopathic.org/
Good example: https://www.who.int/
where "good" and "bad " are defined as "liked by Laura" and "disliked by Laura" (how else would you define them?).

I concur with this assessment.  I find the WHO site more intuitive and less confusing.
Megamenus would seem in general to be a good way to go.
Carl

Dr. Carl Kesselman
Dean’s Professor, Epstein Department of Industrial and Systems Engineering
Fellow, Information Sciences Institute Viterbi School of Engineering Professor,
Preventive Medicine Keck School of Medicine
University of Southern California
4676 Admiralty Way, Suite 1001, Marina del Rey, CA  90292-6695
Phone:  +1<PHONE_NUMBER>
Email<EMAIL_ADDRESS>Web: http://www.isi.edu/~carl
On Mar 11, 2020, 8:12 PM -0700, ljpearlman<EMAIL_ADDRESS>wrote:
FWIW, I've looked at a few megamenus, and I think the implementation makes a big difference for usability. The two factors that the good menus seem to have are requiring a click to open the menu and having strong visual clues that you're looking at a menu and haven't just navigated to a different page.
Bad example: https://osteopathic.org/
Good example: https://www.who.int/
where "good" and "bad " are defined as "liked by Laura" and "disliked by Laura" (how else would you define them?).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/informatics-isi-edu/chaise/issues/1907#issuecomment-597984575, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3OGXXVFM5UIBNPYIHZO33RHBHJJANCNFSM4K3WLTCQ.

@DamCousik
Background knowledge
The current navbar that you see in all chaise apps is dynamic. There are multiple chaise-config properties that dictate how navbar should look like. The notable properties are:

customCSS: the location of a css file that will be included in every chaise page.
navbarBrand , navbarBrandText , navbarBrandImage
navbarMenu : the navbar menu definition.

You don't need to know how these properties are used, but you have to keep in mind that the new megamenu should be customizable as well. Most probably we're going to have to change how navbarMenu is defined when we adopt the new megamenu design. You might realize that changing the structure might actually help the design or responsiveness of the navbar.
How to approach this task
This task can be broken down into two steps:
1. Designing a static megamenu that is responsible.
The focus is mainly on responsiveness. You have to make sure it's behaving properly in different screen/viewport sizes. Your megamenu should be able to handle having different numbers of menu items or levels.  The CSS that you're writing should not assume a very strict structure. However while designing your megamenu you might realize that making some reasonable assumptions about the structure might actually help the responsiveness. In those cases you should consult with the team.
To start working on a static megamenu you can,

create a index.html under your public_html folder in your user directory of dev.rbk. Then you should be able to access it by going to https://dev.rebuildingakidney.org/~cousik/ (you can add it to a folder if you want, it's up to you.)
make sure you're including these css files from chaise

<head>
<link rel='stylesheet' type='text/css' href='/~cousik/chaise/styles/vendor/bootstrap.min.css'>
<link rel='stylesheet' type='text/css' href='/~cousik/chaise/styles/vendor/fontawesome.min.css'>
<link rel='stylesheet' type='text/css' href='/~cousik/chaise/common/styles/app.css'>
</head>

Add your megamenu HTML (and possibly js code) to the HTML file that you've created. You can copy the main content of the dev.rbk if you want too. Just so your HTML page looks more like an actual website. You can use the body content of /var/www/html/index.html (or dev.rebuildingakidney.org) for that matter.

The CSS rules for navbar are defined here. You can remove the old rules or modify them. Any rules that are going to be in that file should be only based on your new design (remove any unused old rules).

As I mentioned you're going to add your CSS rules to Chaise, so in order to test your static site, you need to run make install anytime that you changed the _navbar.scss file.

2. Integrating the static megamenu with chaise and making it dynamic.

You are probably already thinking of this... but as we move forward, we need to make sure that as much of the configuration information is stored in the catalog as possible as we currently do with the current navbar.
Carl

Dr. Carl Kesselman
Dean’s Professor, Epstein Department of Industrial and Systems Engineering
Fellow, Information Sciences Institute Viterbi School of Engineering Professor,
Preventive Medicine Keck School of Medicine
University of Southern California
4676 Admiralty Way, Suite 1001, Marina del Rey, CA  90292-6695
Phone:  +1<PHONE_NUMBER>
Email<EMAIL_ADDRESS>Web: http://www.isi.edu/~carl
On May 26, 2020, 6:07 PM -0700, Aref Shafaei<EMAIL_ADDRESS>wrote:
@DamCousikhttps://github.com/DamCousik
Background knowledge
The current navbar that you see in all chaise apps is dynamic. There are multiple chaise-config properties that dictate how navbar should look like. The notable properties are:

customCSS: the location of a css file that will be included in every chaise page.
navbarBrand , navbarBrandText , navbarBrandImage
navbarMenu : the navbar menu definition.

You don't need to know how these properties are used, but you have to keep in mind that the new megamenu should be customizable as well. Most probably we're going to have to change how navbarMenu is defined when we adopt the new megamenu design. You might realize that changing the structure might actually help the design or responsiveness of the navbar.
How to approach this task
This task can be broken down into two steps:

Designing a static megamenu that is responsible.

The focus is mainly on responsiveness. You have to make sure it's behaving properly in different screen/viewport sizes. Your megamenu should be able to handle having different numbers of menu items or levels. The CSS that you're writing should not assume a very strict structure. However while designing your megamenu you might realize that making some reasonable assumptions about the structure might actually help the responsiveness. In those cases you should consult with the team.
To start working on a static megamenu you can,

create a index.html under your public_html folder in your user directory of dev.rbk. Then you should be able to access it by going to https://dev.rebuildingakidney.org/~cousik/ (you can add it to a folder if you want, it's up to you.)
make sure you're including these css files from chaise

Add your megamenu HTML (and possibly js code) to the HTML file that you've created. You can copy the main content of the dev.rbk if you want too. Just so your HTML page looks more like an actual website. You can use the body content of /var/www/html/index.html (or dev.rebuildingakidney.org) for that matter.

The CSS rules for navbar are defined herehttps://github.com/informatics-isi-edu/chaise/blob/master/common/styles/scss/_navbar.scss. You can remove the old rules or modify them. Any rules that are going to be in that file should be only based on your new design (remove any unused old rules).

As I mentioned you're going to add your CSS rules to Chaise, so in order to test your static site, you need to run make install anytime that you changed the _navbar.scss file.

Integrating the static megamenu with chaise and making it dynamic.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/informatics-isi-edu/chaise/issues/1907#issuecomment-634363097, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3OGXVBR2WWXDB3AKJLO6TRTRRTBANCNFSM4K3WLTCQ.

This issue doesn't change the flow of information, therefore no change to how to get the chaise-config parameters. The chaise config can be supplied through the old chaise-config.js deployed with chaise or catalog annotation.

From: Carl Kesselman<EMAIL_ADDRESS>Sent: Wednesday, May 27, 2020 7:58 AM
To: informatics-isi-edu/chaise<EMAIL_ADDRESS>Cc: Hongsuda Tangmunarunkit<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [informatics-isi-edu/chaise] megamenu support (#1907)
You are probably already thinking of this... but as we move forward, we need to make sure that as much of the configuration information is stored in the catalog as possible as we currently do with the current navbar.
Carl

Dr. Carl Kesselman
Dean’s Professor, Epstein Department of Industrial and Systems Engineering
Fellow, Information Sciences Institute Viterbi School of Engineering Professor,
Preventive Medicine Keck School of Medicine
University of Southern California
4676 Admiralty Way, Suite 1001, Marina del Rey, CA 90292-6695
Phone: +1<PHONE_NUMBER>
Email<EMAIL_ADDRESS>Web: http://www.isi.edu/~carl
On May 26, 2020, 6:07 PM -0700, Aref Shafaei<EMAIL_ADDRESS>wrote:
@DamCousikhttps://github.com/DamCousik
Background knowledge
The current navbar that you see in all chaise apps is dynamic. There are multiple chaise-config properties that dictate how navbar should look like. The notable properties are:

customCSS: the location of a css file that will be included in every chaise page.
navbarBrand , navbarBrandText , navbarBrandImage
navbarMenu : the navbar menu definition.

You don't need to know how these properties are used, but you have to keep in mind that the new megamenu should be customizable as well. Most probably we're going to have to change how navbarMenu is defined when we adopt the new megamenu design. You might realize that changing the structure might actually help the design or responsiveness of the navbar.
How to approach this task
This task can be broken down into two steps:

Designing a static megamenu that is responsible.

The focus is mainly on responsiveness. You have to make sure it's behaving properly in different screen/viewport sizes. Your megamenu should be able to handle having different numbers of menu items or levels. The CSS that you're writing should not assume a very strict structure. However while designing your megamenu you might realize that making some reasonable assumptions about the structure might actually help the responsiveness. In those cases you should consult with the team.
To start working on a static megamenu you can,

create a index.html under your public_html folder in your user directory of dev.rbk. Then you should be able to access it by going to https://dev.rebuildingakidney.org/~cousik/ (you can add it to a folder if you want, it's up to you.)
make sure you're including these css files from chaise

Add your megamenu HTML (and possibly js code) to the HTML file that you've created. You can copy the main content of the dev.rbk if you want too. Just so your HTML page looks more like an actual website. You can use the body content of /var/www/html/index.html (or dev.rebuildingakidney.org) for that matter.

The CSS rules for navbar are defined herehttps://github.com/informatics-isi-edu/chaise/blob/master/common/styles/scss/_navbar.scss. You can remove the old rules or modify them. Any rules that are going to be in that file should be only based on your new design (remove any unused old rules).

As I mentioned you're going to add your CSS rules to Chaise, so in order to test your static site, you need to run make install anytime that you changed the _navbar.scss file.

Integrating the static megamenu with chaise and making it dynamic.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/informatics-isi-edu/chaise/issues/1907#issuecomment-634363097, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3OGXVBR2WWXDB3AKJLO6TRTRRTBANCNFSM4K3WLTCQ.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/informatics-isi-edu/chaise/issues/1907#issuecomment-634719155, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AADFIDEQT5YE4Z4V54PRAA3RTUTCHANCNFSM4K3WLTCQ.

Perfect.
Carl

Dr. Carl Kesselman
Dean’s Professor, Epstein Department of Industrial and Systems Engineering
Fellow, Information Sciences Institute Viterbi School of Engineering Professor,
Preventive Medicine Keck School of Medicine
University of Southern California
4676 Admiralty Way, Suite 1001, Marina del Rey, CA  90292-6695
Phone:  +1<PHONE_NUMBER>
Email<EMAIL_ADDRESS>Web: http://www.isi.edu/~carl
On May 27, 2020, 10:20 AM -0700, Hongsuda<EMAIL_ADDRESS>wrote:
This issue doesn't change the flow of information, therefore no change to how to get the chaise-config parameters. The chaise config can be supplied through the old chaise-config.js deployed with chaise or catalog annotation.

From: Carl Kesselman<EMAIL_ADDRESS>Sent: Wednesday, May 27, 2020 7:58 AM
To: informatics-isi-edu/chaise<EMAIL_ADDRESS>Cc: Hongsuda Tangmunarunkit<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [informatics-isi-edu/chaise] megamenu support (#1907)
You are probably already thinking of this... but as we move forward, we need to make sure that as much of the configuration information is stored in the catalog as possible as we currently do with the current navbar.
Carl

Dr. Carl Kesselman
Dean’s Professor, Epstein Department of Industrial and Systems Engineering
Fellow, Information Sciences Institute Viterbi School of Engineering Professor,
Preventive Medicine Keck School of Medicine
University of Southern California
4676 Admiralty Way, Suite 1001, Marina del Rey, CA 90292-6695
Phone: +1<PHONE_NUMBER>
Email<EMAIL_ADDRESS>Web: http://www.isi.edu/~carl
On May 26, 2020, 6:07 PM -0700, Aref Shafaei<EMAIL_ADDRESS>wrote:
@DamCousikhttps://github.com/DamCousik
Background knowledge
The current navbar that you see in all chaise apps is dynamic. There are multiple chaise-config properties that dictate how navbar should look like. The notable properties are:

customCSS: the location of a css file that will be included in every chaise page.
navbarBrand , navbarBrandText , navbarBrandImage
navbarMenu : the navbar menu definition.

You don't need to know how these properties are used, but you have to keep in mind that the new megamenu should be customizable as well. Most probably we're going to have to change how navbarMenu is defined when we adopt the new megamenu design. You might realize that changing the structure might actually help the design or responsiveness of the navbar.
How to approach this task
This task can be broken down into two steps:

Designing a static megamenu that is responsible.

The focus is mainly on responsiveness. You have to make sure it's behaving properly in different screen/viewport sizes. Your megamenu should be able to handle having different numbers of menu items or levels. The CSS that you're writing should not assume a very strict structure. However while designing your megamenu you might realize that making some reasonable assumptions about the structure might actually help the responsiveness. In those cases you should consult with the team.
To start working on a static megamenu you can,

create a index.html under your public_html folder in your user directory of dev.rbk. Then you should be able to access it by going to https://dev.rebuildingakidney.org/~cousik/ (you can add it to a folder if you want, it's up to you.)
make sure you're including these css files from chaise

Add your megamenu HTML (and possibly js code) to the HTML file that you've created. You can copy the main content of the dev.rbk if you want too. Just so your HTML page looks more like an actual website. You can use the body content of /var/www/html/index.html (or dev.rebuildingakidney.org) for that matter.

The CSS rules for navbar are defined herehttps://github.com/informatics-isi-edu/chaise/blob/master/common/styles/scss/_navbar.scss. You can remove the old rules or modify them. Any rules that are going to be in that file should be only based on your new design (remove any unused old rules).

As I mentioned you're going to add your CSS rules to Chaise, so in order to test your static site, you need to run make install anytime that you changed the _navbar.scss file.

Integrating the static megamenu with chaise and making it dynamic.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/informatics-isi-edu/chaise/issues/1907#issuecomment-634363097, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3OGXVBR2WWXDB3AKJLO6TRTRRTBANCNFSM4K3WLTCQ.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/informatics-isi-edu/chaise/issues/1907#issuecomment-634719155, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AADFIDEQT5YE4Z4V54PRAA3RTUTCHANCNFSM4K3WLTCQ.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/informatics-isi-edu/chaise/issues/1907#issuecomment-634815194, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3OGXVXM7J7L2FXSJL7C73RTVDU7ANCNFSM4K3WLTCQ.

Moving to wishlist. We should create a new issue with more information if we would like to implement this.


different F1 with the same seed

Hi, I try to use your code with our own dataset.Every time I train, the results on the dev or test dataset are slightly different, maybe 0.1 F1, but I can't find the specific location in your code where this situation occurs. Have you ever tried to use the same seed, run more times and check whether the results are consistent? Thank you.

Hi, I try to use your code with our own dataset.Every time I train, the results on the dev or test dataset are slightly different, maybe 0.1 F1, but I can't find the specific location in your code where this situation occurs. Have you ever tried to use the same seed, run more times and check whether the results are consistent? Thank you.

Hello，I check this again. And F1 can fluctuate 2 ~ 3  %. Please check this problem if you are free. Thank you.

Hi, are you training the entity model or the relation model?
I have checked this at an early stage and with the same seed, the code should be able to produce the same results with the same hardware settings and CUDA version. But it is possible that I modified some code later on, which may cause this.


TimePicker buttons have insufficient contrast

Currently 2.24, suggested is at least 3.00

Moving all button contrast issues to https://github.com/flutter/flutter/issues/19946


Remove duplicate log entry from sentry

Sentry was logging the "Starting Dapr Sentry" message twice. The first log was also before the call to logger.ApplyOptionsToAllLogger, so it would have not been JSON-formatted if that's what users wish.

@ItalyPaleAle Can this PR be rebased against release-1.12 branch?

Done


with inside a identifer is mistaken as keyword

/cc @MangelMaxime

Thank you @forki
Yes we are slowly getting everything colored. Still some edge cases to fix to make the colors consistent :)


Update binding filter to accept bindings with a form with a call but no call

Summary
We are currently removing all bindings that have no call object. But a binding with a form that has a call should also be valid.
This PR cover that, and piggybacks some minor aesthethic changes removes the repeated options on in post bindings on cleanup.
Ticket Link
https://mattermost.atlassian.net/browse/MM-33824
Related Pull Requests
This change will be piggybacked on mobile on this PR: https://github.com/mattermost/mattermost-mobile/pull/5655
Screenshots
None
Release Note
NONE

@DHaussermann The latest (today's) test app should have a new command /test valid callInForm. Before this PR, that command should have been filtered (with some message of missing call in the server logs). Now the command should appear and work correctly (call the OK endpoint of the app and return an OK ephemeral post).


Update doesn't work

Whenever i try to update a stream, it doesn't work only way to update is to delete and recreate the channel, tested it directly on a ADT-1 and on  the phone

Thanks for letting me know. I'll mark this as a bug and should get a fix ready in the next few days.

See #72


Add Dependent Fields Support

Adds the ability to use ->dependsOn(...) with this field.

@lptn The dependsOn logic only applies to to create/edit and yes I can confirm it works on create/edit and show and the index does not show any errors.

Cool, thanks a lot!


dead code?

oops? https://github.com/yoshuawuyts/nanotick/blob/master/index.js#L19-L23

Haha yeah lines under that should take args not arguments - spotted that on
my way out but guess someone noticed before I could fix it :D - PR welcome
tho!
On Mon, Dec 12, 2016, 14:36 Joseph Werle<EMAIL_ADDRESS>wrote:

oops? https://github.com/yoshuawuyts/nanotick/blob/master/index.js#L19-L23
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/yoshuawuyts/nanotick/issues/1, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWleghovIGmqHOM7rT4a5Yd_VNEi7x6ks5rHU33gaJpZM4LKjWt
.

ah well fixed; v1.0.2 :tada: :grin:

nice! 👍 💯


Applies source{d} branding to CodeMirror UAST Modal

The full rationale of these changes can be seen on the source{d} branding design doc.
Do not merge yet, if reviewed & approved, it still needs some product validation.
Before:

After:

@dpordomingo Solved :)