E2E on AWS + OSP: Timeouts in 6 out of 12 tests

After setting up Submariner on AWS cluster and OSP Cluster (Upshift, behind NAT), the connection was tested, and is working:
[submariner-operator]$ KUBECONFIG=/home/nmanos/automation/ocp-install/nmanos-cluster-a/auth/kubeconfig oc exec netshoot-785ffd8c8-42bxq -- curl --output /dev/null -m 30 --progress-bar --verbose --head --fail <IP_ADDRESS>
*   Trying <IP_ADDRESS>:80...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 80 (#0)
> HEAD / HTTP/1.1
> Host: <IP_ADDRESS>
> User-Agent: curl/7.65.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.17.6
< Date: Mon, 23 Dec 2019 09:58:57 GMT
< Content-Type: text/html
< Content-Length: 612
< Last-Modified: Tue, 19 Nov 2019 15:14:41 GMT
< Connection: keep-alive
< ETag: "5dd406e1-264"
< Accept-Ranges: bytes

However, running the E2E tests, has failed on timeouts in 6 out of 12 tests:
Summarizing 6 Failures:

[Fail] [redundancy] Gateway fail-over tests when two gateway nodes are configured with one submariner engine replica and the gateway node fails [It] should start a new submariner engine pod on the second gateway node and be able to connect from another cluster
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/framework/framework.go:327

[Fail] [dataplane] Basic TCP connectivity tests across clusters without discovery when a pod connects via TCP to a remote pod when the pod is not on a gateway and the remote pod is on a gateway [It] should have sent the expected data from the pod to the other pod
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/framework/framework.go:327

[Fail] [redundancy] Gateway fail-over tests when one gateway node is configured and the submariner engine pod fails [It] should start a new submariner engine pod and be able to connect from another cluster
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/framework/framework.go:327

[Fail] [dataplane] Basic TCP connectivity tests across clusters without discovery when a pod connects via TCP to a remote pod when the pod is on a gateway and the remote pod is on a gateway [It] should have sent the expected data from the pod to the other pod
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/framework/framework.go:327

[Fail] [dataplane] Basic TCP connectivity tests across clusters without discovery when a pod connects via TCP to a remote service when the pod is on a gateway and the remote service is on a gateway [It] should have sent the expected data from the pod to the other pod
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/framework/framework.go:327

[Fail] [dataplane] Basic TCP connectivity tests across clusters without discovery when a pod connects via TCP to a remote service when the pod is not on a gateway and the remote service is on a gateway [It] should have sent the expected data from the pod to the other pod
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/framework/framework.go:327

Ran 12 of 13 Specs in 495.063 seconds
FAIL! -- 6 Passed | 6 Failed | 1 Pending | 0 Skipped

Full deployment + E2E output

The tests failed due to issues querying the k8s API servers and not due to cross-cluster connectivity issues. The first gateway test failure was the first test run and failed with:
STEP: Found gateway node "ip-10-0-71-143.ec2.internal" on "admin"
STEP: Found non-gateway node "ip-10-0-129-38.ec2.internal" on "admin"
STEP: Destroying namespace "e2e-tests-gateway-redundancy-4tlzq" for this suite on all clusters.

• Failure [62.394 seconds]
[redundancy] Gateway fail-over tests
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/redundancy/gateway_failover.go:13
  when two gateway nodes are configured with one submariner engine replica and the gateway node fails
  /home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/redundancy/gateway_failover.go:22
    should start a new submariner engine pod on the second gateway node and be able to connect from another cluster [It]
    /home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/redundancy/gateway_failover.go:23

    Failed to find pods for app submariner-engine. Actual pod count 0 does not match the expected pod count 1
    Unexpected error:
        <*errors.errorString | 0xc00024eb20>: {
            s: "timed out waiting for the condition",
        }
        timed out waiting for the condition
    occurred

    /home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/framework/framework.go:327

So it failed to find the submariner-engine pod on the gateway node which seems to indicate submariner wasn't fully deployed yet.
The second test was a pod2pod dataplane test from non-gateway to non-gateway that succeeded.
The third test was a pod2pod dataplane test that failed due to the listener pod still in the Pending state:
STEP: Creating a listener pod in cluster "admin_cluster_b", which will wait for a handshake over TCP
STEP: Destroying namespace "e2e-tests-dataplane-conn-nd-6jmt7" for this suite on all clusters.

• Failure [61.269 seconds]
[dataplane] Basic TCP connectivity tests across clusters without discovery
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/dataplane/tcp_pod_connectivity.go:12
  when a pod connects via TCP to a remote pod
  /home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/dataplane/tcp_pod_connectivity.go:22
    when the pod is not on a gateway and the remote pod is on a gateway
    /home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/dataplane/tcp_pod_connectivity.go:31
      should have sent the expected data from the pod to the other pod [It]
      /home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/dataplane/tcp_pod_connectivity.go:17

      Failed to await pod ready. Pod "tcp-check-listener2dvtp" is still pending
      Unexpected error:
          <*errors.errorString | 0xc00024eb20>: {
              s: "timed out waiting for the condition",
          }
          timed out waiting for the condition
      occurred

      /home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/framework/framework.go:327

The 3 other dataplane test failures were due to the same issue. We wait a total of 1 minute with retries every 5 sec. We can increase the timeout (we should make it configurable) but it's strange why it takes at least a minute half the time for pods to be scheduled and run.

The gateway test failures indicate there is a node, "ip-10-0-71-143.ec2.internal",  on cluster "admin" labeled as a gateway however there's no submariner-engine pod running. That indicates submariner either wasn't installed on "admin" or "ip-10-0-71-143.ec2.internal" is a master node, in which case k8s won't schedule pods on it, or k8s didn't schedule it for some other reason.
The dataplane tests that fail involve connecting from cluster "admin" to a gateway node on cluster "admin_cluster_b" - the listener pod created on cluster "admin_cluster_b" stays pending which indicates there's either no node labeled as a gateway or k8s didn't schedule it for the same reasons as above.
So it seems there's no submariner-engine pod running in either cluster. Given that, it seems odd that the dataplane tests involving a non-gateway node on cluster "admin_cluster_b" succeed. That seems to indicate the pod/service IPs are somehow accessible cross-cluster via some other means outside of submariner.

@tpantelis, I made sure SubM is not installed, before E2E execution, and no connection was possible between the two clusters.
Please take a look on the log:
Before SubM installed - At line 850: Curl connection timed out.
After SubM installed - At line 1250: Curl connection established.
So the reason for test failure is probably in the test logic, not in SubM deployment.

So the reason for test failure is probably in the test logic, not in SubM deployment.

I don't think so based on the failure output. The tests don't even get to the point of testing connectivity - they fail in setup and prerequisite checks. As I mentioned above, in one failure, it doesn't find a submariner engine pod running and the other failures indicate the test pod wasn't scheduled/run by k8s which probably means there's no node labeled as a gateway.
Before running the tests please ensure via kubectl that there is a node in each cluster labeled as a gateway and there's submariner engine pods running in each cluster (except the broker cluster is it's separate from the dataplane clusters).

Running with latest SubM code, I see more info now in E2E output.
I made sure gateway label defined on a worker node on each cluster.
Here's the full output:
submariner_test_07012020_1752.log
And here's just the first test failure:
``
[redundancy] Gateway fail-over tests when two gateway nodes are configured with one submariner engine replica and the gateway node fails
should start a new submariner engine pod on the second gateway node and be able to connect from another cluster
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/redundancy/gateway_failover.go:23
STEP: Creating kubernetes clients
STEP: Building namespace api objects, basename gateway-redundancy
STEP: Creating a namespace e2e-tests-gateway-redundancy-zjqhr to execute the test in
STEP: Destroying namespace "e2e-tests-gateway-redundancy-zjqhr" for this suite on all clusters.
• Failure [1.216 seconds]
[redundancy] Gateway fail-over tests
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/redundancy/gateway_failover.go:13
when two gateway nodes are configured with one submariner engine replica and the gateway node fails
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/redundancy/gateway_failover.go:22
should start a new submariner engine pod on the second gateway node and be able to connect from another cluster [It]
/home/nmanos/go/src/github.com/submariner-io/submariner/test/e2e/redundancy/gateway_failover.go:23
Expected only one gateway node on "admin"
Expected
    <[]*v1.Node | len:2, cap:2>: [
        {
            TypeMeta: {Kind: "", APIVersion: ""},
            ObjectMeta: {
                Name: "ip-10-0-130-131.ec2.internal",
                GenerateName: "",
                Namespace: "",
                SelfLink: "/api/v1/nodes/ip-10-0-130-131.ec2.internal",
                UID: "db3eb6f4-307c-11ea-b5f1-0a4e6e2bcb67",
                ResourceVersion: "527485",
                Generation: 0,
                CreationTimestamp: {
                    Time: 2020-01-06T14:05:40+02:00,
                },
                DeletionTimestamp: nil,
                DeletionGracePeriodSeconds: nil,
                Labels: {
                    "beta.kubernetes.io/instance-type": "m4.large",
                    "failure-domain.beta.kubernetes.io/region": "us-east-1",
                    "kubernetes.io/arch": "amd64",
                    "node.openshift.io/os_id": "rhcos",
                    "submariner.io/gateway": "true",
                    "node-role.kubernetes.io/worker": "",
                    "beta.kubernetes.io/arch": "amd64",
                    "beta.kubernetes.io/os": "linux",
                    "failure-domain.beta.kubernetes.io/zone": "us-east-1a",
                    "kubernetes.io/hostname": "ip-10-0-130-131",
                    "kubernetes.io/os": "linux",
                },
                Annotations: {
                    "volumes.kubernetes.io/controller-managed-attach-detach": "true",
                    "machine.openshift.io/machine": "openshift-machine-api/nmanos-cluster-a-8chvz-worker-us-east-1a-trdf2",
                    "machineconfiguration.openshift.io/currentConfig": "rendered-worker-30c2d51dc025dfbd851e6a0dc06385ad",
                    "machineconfiguration.openshift.io/desiredConfig": "rendered-worker-30c2d51dc025dfbd851e6a0dc06385ad",
                    "machineconfiguration.openshift.io/state": "Done",
                },
                OwnerReferences: nil,
                Initializers: nil,
                Finalizers: nil,
                ClusterName: "",
            },
            Spec: {
                PodCIDR: "",
                ProviderID: "aws:///us-east-1a/i-0dc09b53e40a7f73d",
                Unschedulable: false,
                Taints: nil,
                ConfigSource: nil,
                DoNotUse_ExternalID: "",
            },
            Status: {
                Capacity: {
                    "attachable-volumes-aws-ebs": {
                        i: {value: 39, scale: 0},
                        d: {Dec: nil},
                        s: "39",
                        Format: "DecimalSI",
                    },
                    "cpu": {
                        i: {value: 2, scale: 0},
                        d: {Dec: nil},
                        s: "2",
                        Format: "DecimalSI",
                    },
                    "hugepages-1Gi": {
                        i: {value: 0, scale: 0},
                        d: {Dec: nil},
                        s: "0",
                        Format: "DecimalSI",
                    },
                    "hugepages-2Mi": {
                        i: {value: 0, scale: 0},
                        d: {Dec: nil},
                        s: "0",
                        Format: "DecimalSI",
                    },
                    "memory": {
                        i: {value:<PHONE_NUMBER>, scale: 0},
                        d: {Dec: nil},
                        s: "",
                        Format: "BinarySI",
                    },
                    "pods": {
                        i: {value: 250, scale: 0},
                        d: {Dec: nil},
                        s: "250",
                        Format: "DecimalSI",
                    },
                },
                Allocatable: {
                    "attachable-volumes-aws-ebs": {
                        i: {value: 39, scale: 0},
                        d: {Dec: nil},
                        s: "39",
                        Format: "DecimalSI",
                    },
                    "cpu": {
                        i: {value: 1500, scale: -3},
                        d: {Dec: nil},
                        s: "1500m",
                        Format: "DecimalSI",
                    },
                    "hugepages-1Gi": {
                        i: {value: 0, scale: 0},
                        d: {Dec: nil},
                        s: "0",
                        Format: "DecimalSI",
                    },
                    "hugepages-2Mi": {
                        i: {value: 0, scale: 0},
                        d: {Dec: nil},
                        s: "0",
                        Format: "DecimalSI",
                    },
                    "memory": {
                        i: {value:<PHONE_NUMBER>, scale: 0},
                        d: {Dec: nil},
                        s: "",
                        Format: "BinarySI",
                    },
                    "pods": {
                        i: {value: 250, scale: 0},
                        d: {Dec: nil},
                        s: "250",
                        Format: "DecimalSI",
                    },
                },
                Phase: "",
                Conditions: [
                    {
                        Type: "MemoryPressure",
                        Status: "False",
                        LastHeartbeatTime: {
                            Time: 2020-01-07T18:07:02+02:00,
                        },
                        LastTransitionTime: {
                            Time: 2020-01-06T14:05:40+02:00,
                        },
                        Reason: "KubeletHasSufficientMemory",
                        Message: "kubelet has sufficient memory available",
                    },
                    {
                        Type: "DiskPressure",
                        Status: "False",
                        LastHeartbeatTime: {
                            Time: 2020-01-07T18:07:02+02:00,
                        },
                        LastTransitionTime: {
                            Time: 2020-01-06T14:05:40+02:00,
                        },
                        Reason: "KubeletHasNoDiskPressure",
                        Message: "kubelet has no disk pressure",
                    },
                    {
                        Type: "PIDPressure",
                        Status: "False",
                        LastHeartbeatTime: {
                            Time: 2020-01-07T18:07:02+02:00,
                        },
                        LastTransitionTime: {
                            Time: 2020-01-06T14:05:40+02:00,
                        },
                        Reason: "KubeletHasSufficientPID",
                        Message: "kubelet has sufficient PID available",
                    },
                    {
                        Type: "Ready",
                        Status: "True",
                        LastHeartbeatTime: {
                            Time: 2020-01-07T18:07:02+02:00,
                        },
                        LastTransitionTime: {
                            Time: 2020-01-06T14:06:30+02:00,
                        },
                        Reason: "KubeletReady",
                        Message: "kubelet is posting ready status",
                    },
                ],
                Addresses: [
                    {
                        Type: "InternalIP",
                        Address: "<IP_ADDRESS>",
                    },
                    {
                        Type: "Hostname",
                        Address: "ip-10-0-130-131.ec2.internal",
                    },
                    {
                        Type: "InternalDNS",
                        Address: "ip-10-0-130-131.ec2.internal",
                    },
                ],
                DaemonEndpoints: {
                    KubeletEndpoint: {Port: 10250},
                },
                NodeInfo: {
                    MachineID: "83d7b5d9375e4417903aa5691a6993b2",
                    SystemUUID: "ec2aaa22-fd4a-4ac9-84c6-9918333a41e7",
                    BootID: "95d032ec-a21a-497b-a8ad-efa0963df039",
                    KernelVersion: "4.18.0-147.0.3.el8_1.x86_64",
                    OSImage: "Red Hat Enterprise Linux CoreOS 42.81.20191210.1 (Ootpa)",
                    ContainerRuntimeVersion: "cri-o://1.14.11-0.24.dev.rhaos4.2.gitc41de67.el8",
                    KubeletVersion: "v1.14.6+cebabbf4a",
                    KubeProxyVersion: "v1.14.6+cebabbf4a",
                    OperatingSystem: "linux",
                    Architecture: "amd64",
                },
                Images: [
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d5de6bd0ca757e07c58651234ceac857b24422fba98ed0b2912e51ba5fa2d4ee",
                            "<none>:<none>",
                        ],
                        SizeBytes:<PHONE_NUMBER>,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:ee06b91284df931bc77fa71b425bf9718edf2f886b35846ae98988382871fbf3",
                            "<none>:<none>",
                        ],
                        SizeBytes: 435652314,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:aa6b4ea74e537e53aa7b72f2d479eafbad60c78e9ea49e3bd5b59720cd46c332",
                            "<none>:<none>",
                        ],
                        SizeBytes: 405473489,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:0048e6f8730510893370553c1386e34827abcdb4dffaa2d392f1614c63a1c9c7",
                            "<none>:<none>",
                        ],
                        SizeBytes: 388527143,
                    },
                    {
                        Names: [
                            "quay.io/submariner/submariner@sha256:a0e98d89478c126b7da112eeee61a38d7d1f5d3f5397b2cea0a98eadc948b230",
                            "quay.io/submariner/submariner:0.0.3",
                        ],
                        SizeBytes: 373133796,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:1d7fdf7cacbd78bef24f9eb9d355161529ab2d561896de62572d81e55b61d370",
                            "<none>:<none>",
                        ],
                        SizeBytes: 323890713,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:bf0302eabcdcd5f2b3083483122cf71a5bb66cab9332e255bb009f289e74609b",
                            "<none>:<none>",
                        ],
                        SizeBytes: 320014542,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:b10e3e94d34509b1bc5d826b0ea33c352eefd37c157b386580f2b87f7d35bf40",
                            "<none>:<none>",
                        ],
                        SizeBytes: 318297754,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:e451a219626274f7556b0ad21ff7bb2ca31be2ddd93f4c7533da49b78c82678d",
                            "<none>:<none>",
                        ],
                        SizeBytes: 306490354,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:c919d6f77371e7d4a5f2d30cdc5d5bf3942c001c1ca82640fe5d1c15f7377cbd",
                            "<none>:<none>",
                        ],
                        SizeBytes: 305375776,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:a8129d076e19fea59b3f9e8a04fbc0e0cdf53321ef3ab460bdbd1ffbd2230438",
                            "<none>:<none>",
                        ],
                        SizeBytes: 285110290,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:4debe16999ebb9ca954822a6c75ee4461186be6eeb13313bf4ede367264ba5e3",
                            "<none>:<none>",
                        ],
                        SizeBytes: 282984020,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:5a970d3eb87e42d7ae72b225f9607eb8a671a058d5bd66b61301264e48c698b4",
                            "<none>:<none>",
                        ],
                        SizeBytes: 277826953,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:4b02508d70b16f5a6faecf2d92db88c2ad0ff37df7e1bfe12d100ab4fea9e8fd",
                            "<none>:<none>",
                        ],
                        SizeBytes: 277504608,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:86e282e319f97bab460e8afd3dc3033448942f3418f7d6259d4c2ddae0a65923",
                            "<none>:<none>",
                        ],
                        SizeBytes: 271251340,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:28978e532ef46c9d4edeabfb73a1e8561493d6681b940793cd2a385f9f70f27f",
                            "<none>:<none>",
                        ],
                        SizeBytes: 257359474,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:056c014da88c54ade3bc46e7c7019e716d4c33aaa37cd63eb9641a65387a6433",
                            "<none>:<none>",
                        ],
                        SizeBytes: 256307849,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:9be3b6804fbb09d58c352a2110ad42d79c158dc258d7b02244bf209e453a7148",
                            "<none>:<none>",
                        ],
                        SizeBytes: 255927512,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:a81e1a02bb25f93e6f3d3b9d5ddddb07a0c8025b4e5bd717cc6e4a6f3b8bdea2",
                            "<none>:<none>",
                        ],
                        SizeBytes: 250722882,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:6483a97d7a63c161d843adad077b6947dfa5405474272c6c0a185e47a48ae448",
                            "<none>:<none>",
                        ],
                        SizeBytes: 237660484,
                    },
                    {
                        Names: [
                            "quay.io/submariner/submariner-route-agent@sha256:5d6547308bb7cbbb3a24c984d5ac0ec390d2cef776c803cb9449ddf2044c6603",
                            "quay.io/submariner/submariner-route-agent:0.0.3",
                        ],
                        SizeBytes: 114103050,
                    },
                ],
                VolumesInUse: nil,
                VolumesAttached: nil,
                Config: nil,
            },
        },
        {
            TypeMeta: {Kind: "", APIVersion: ""},
            ObjectMeta: {
                Name: "ip-10-0-21-178.ec2.internal",
                GenerateName: "",
                Namespace: "",
                SelfLink: "/api/v1/nodes/ip-10-0-21-178.ec2.internal",
                UID: "daddd29b-307e-11ea-9dae-0a4e6e2bcb67",
                ResourceVersion: "527200",
                Generation: 0,
                CreationTimestamp: {
                    Time: 2020-01-06T14:19:58+02:00,
                },
                DeletionTimestamp: nil,
                DeletionGracePeriodSeconds: nil,
                Labels: {
                    "beta.kubernetes.io/instance-type": "m4.large",
                    "failure-domain.beta.kubernetes.io/region": "us-east-1",
                    "node.openshift.io/os_id": "rhcos",
                    "beta.kubernetes.io/arch": "amd64",
                    "beta.kubernetes.io/os": "linux",
                    "failure-domain.beta.kubernetes.io/zone": "us-east-1b",
                    "kubernetes.io/arch": "amd64",
                    "kubernetes.io/hostname": "ip-10-0-21-178",
                    "kubernetes.io/os": "linux",
                    "node-role.kubernetes.io/worker": "",
                    "submariner.io/gateway": "true",
                },
                Annotations: {
                    "machine.openshift.io/machine": "openshift-machine-api/nmanos-cluster-a-8chvz-submariner-gw-us-east-1b-h9bx5",
                    "machineconfiguration.openshift.io/currentConfig": "rendered-worker-30c2d51dc025dfbd851e6a0dc06385ad",
                    "machineconfiguration.openshift.io/desiredConfig": "rendered-worker-30c2d51dc025dfbd851e6a0dc06385ad",
                    "machineconfiguration.openshift.io/state": "Done",
                    "volumes.kubernetes.io/controller-managed-attach-detach": "true",
                },
                OwnerReferences: nil,
                Initializers: nil,
                Finalizers: nil,
                ClusterName: "",
            },
            Spec: {
                PodCIDR: "",
                ProviderID: "aws:///us-east-1b/i-05104113975d892e6",
                Unschedulable: false,
                Taints: nil,
                ConfigSource: nil,
                DoNotUse_ExternalID: "",
            },
            Status: {
                Capacity: {
                    "hugepages-2Mi": {
                        i: {value: 0, scale: 0},
                        d: {Dec: nil},
                        s: "0",
                        Format: "DecimalSI",
                    },
                    "memory": {
                        i: {value:<PHONE_NUMBER>, scale: 0},
                        d: {Dec: nil},
                        s: "",
                        Format: "BinarySI",
                    },
                    "pods": {
                        i: {value: 250, scale: 0},
                        d: {Dec: nil},
                        s: "250",
                        Format: "DecimalSI",
                    },
                    "attachable-volumes-aws-ebs": {
                        i: {value: 39, scale: 0},
                        d: {Dec: nil},
                        s: "39",
                        Format: "DecimalSI",
                    },
                    "cpu": {
                        i: {value: 2, scale: 0},
                        d: {Dec: nil},
                        s: "2",
                        Format: "DecimalSI",
                    },
                    "hugepages-1Gi": {
                        i: {value: 0, scale: 0},
                        d: {Dec: nil},
                        s: "0",
                        Format: "DecimalSI",
                    },
                },
                Allocatable: {
                    "memory": {
                        i: {value:<PHONE_NUMBER>, scale: 0},
                        d: {Dec: nil},
                        s: "",
                        Format: "BinarySI",
                    },
                    "pods": {
                        i: {value: 250, scale: 0},
                        d: {Dec: nil},
                        s: "250",
                        Format: "DecimalSI",
                    },
                    "attachable-volumes-aws-ebs": {
                        i: {value: 39, scale: 0},
                        d: {Dec: nil},
                        s: "39",
                        Format: "DecimalSI",
                    },
                    "cpu": {
                        i: {value: 1500, scale: -3},
                        d: {Dec: nil},
                        s: "1500m",
                        Format: "DecimalSI",
                    },
                    "hugepages-1Gi": {
                        i: {value: 0, scale: 0},
                        d: {Dec: nil},
                        s: "0",
                        Format: "DecimalSI",
                    },
                    "hugepages-2Mi": {
                        i: {value: 0, scale: 0},
                        d: {Dec: nil},
                        s: "0",
                        Format: "DecimalSI",
                    },
                },
                Phase: "",
                Conditions: [
                    {
                        Type: "MemoryPressure",
                        Status: "False",
                        LastHeartbeatTime: {
                            Time: 2020-01-07T18:06:38+02:00,
                        },
                        LastTransitionTime: {
                            Time: 2020-01-06T14:19:58+02:00,
                        },
                        Reason: "KubeletHasSufficientMemory",
                        Message: "kubelet has sufficient memory available",
                    },
                    {
                        Type: "DiskPressure",
                        Status: "False",
                        LastHeartbeatTime: {
                            Time: 2020-01-07T18:06:38+02:00,
                        },
                        LastTransitionTime: {
                            Time: 2020-01-06T14:19:58+02:00,
                        },
                        Reason: "KubeletHasNoDiskPressure",
                        Message: "kubelet has no disk pressure",
                    },
                    {
                        Type: "PIDPressure",
                        Status: "False",
                        LastHeartbeatTime: {
                            Time: 2020-01-07T18:06:38+02:00,
                        },
                        LastTransitionTime: {
                            Time: 2020-01-06T14:19:58+02:00,
                        },
                        Reason: "KubeletHasSufficientPID",
                        Message: "kubelet has sufficient PID available",
                    },
                    {
                        Type: "Ready",
                        Status: "True",
                        LastHeartbeatTime: {
                            Time: 2020-01-07T18:06:38+02:00,
                        },
                        LastTransitionTime: {
                            Time: 2020-01-06T14:20:49+02:00,
                        },
                        Reason: "KubeletReady",
                        Message: "kubelet is posting ready status",
                    },
                ],
                Addresses: [
                    {
                        Type: "InternalIP",
                        Address: "<IP_ADDRESS>",
                    },
                    {
                        Type: "ExternalIP",
                        Address: "<IP_ADDRESS>",
                    },
                    {
                        Type: "Hostname",
                        Address: "ip-10-0-21-178.ec2.internal",
                    },
                    {
                        Type: "InternalDNS",
                        Address: "ip-10-0-21-178.ec2.internal",
                    },
                    {
                        Type: "ExternalDNS",
                        Address: "ec2-54-198-26-149.compute-1.amazonaws.com",
                    },
                ],
                DaemonEndpoints: {
                    KubeletEndpoint: {Port: 10250},
                },
                NodeInfo: {
                    MachineID: "e036adfada5b4eaab4506fab639fa0ec",
                    SystemUUID: "ec2be5d9-2315-8b24-0181-9e4a150f6da7",
                    BootID: "11e1ea9b-d9c9-4c2c-b9ad-d1a29ded2a17",
                    KernelVersion: "4.18.0-147.0.3.el8_1.x86_64",
                    OSImage: "Red Hat Enterprise Linux CoreOS 42.81.20191210.1 (Ootpa)",
                    ContainerRuntimeVersion: "cri-o://1.14.11-0.24.dev.rhaos4.2.gitc41de67.el8",
                    KubeletVersion: "v1.14.6+cebabbf4a",
                    KubeProxyVersion: "v1.14.6+cebabbf4a",
                    OperatingSystem: "linux",
                    Architecture: "amd64",
                },
                Images: [
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d5de6bd0ca757e07c58651234ceac857b24422fba98ed0b2912e51ba5fa2d4ee",
                            "<none>:<none>",
                        ],
                        SizeBytes:<PHONE_NUMBER>,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:aa6b4ea74e537e53aa7b72f2d479eafbad60c78e9ea49e3bd5b59720cd46c332",
                            "<none>:<none>",
                        ],
                        SizeBytes: 405473489,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:658698f709ba6cc0c6e47b64430ab588ba2d863750fe827949174d3bb6183243",
                            "<none>:<none>",
                        ],
                        SizeBytes: 391962840,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:0048e6f8730510893370553c1386e34827abcdb4dffaa2d392f1614c63a1c9c7",
                            "<none>:<none>",
                        ],
                        SizeBytes: 388527143,
                    },
                    {
                        Names: [
                            "quay.io/submariner/submariner@sha256:a0e98d89478c126b7da112eeee61a38d7d1f5d3f5397b2cea0a98eadc948b230",
                            "quay.io/submariner/submariner:0.0.3",
                        ],
                        SizeBytes: 373133796,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:1d7fdf7cacbd78bef24f9eb9d355161529ab2d561896de62572d81e55b61d370",
                            "<none>:<none>",
                        ],
                        SizeBytes: 323890713,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:b10e3e94d34509b1bc5d826b0ea33c352eefd37c157b386580f2b87f7d35bf40",
                            "<none>:<none>",
                        ],
                        SizeBytes: 318297754,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:e451a219626274f7556b0ad21ff7bb2ca31be2ddd93f4c7533da49b78c82678d",
                            "<none>:<none>",
                        ],
                        SizeBytes: 306490354,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:c919d6f77371e7d4a5f2d30cdc5d5bf3942c001c1ca82640fe5d1c15f7377cbd",
                            "<none>:<none>",
                        ],
                        SizeBytes: 305375776,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:3679d3faf5ce21feed800e9e44c069e3c1fac029c8dba7ed90c497c02af66968",
                            "<none>:<none>",
                        ],
                        SizeBytes: 296285926,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:a8129d076e19fea59b3f9e8a04fbc0e0cdf53321ef3ab460bdbd1ffbd2230438",
                            "<none>:<none>",
                        ],
                        SizeBytes: 285110290,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:4debe16999ebb9ca954822a6c75ee4461186be6eeb13313bf4ede367264ba5e3",
                            "<none>:<none>",
                        ],
                        SizeBytes: 282984020,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:9be3b6804fbb09d58c352a2110ad42d79c158dc258d7b02244bf209e453a7148",
                            "<none>:<none>",
                        ],
                        SizeBytes: 255927512,
                    },
                    {
                        Names: [
                            "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:a81e1a02bb25f93e6f3d3b9d5ddddb07a0c8025b4e5bd717cc6e4a6f3b8bdea2",
                            "<none>:<none>",
                        ],
                        SizeBytes: 250722882,
                    },
                    {
                        Names: [
                            "docker.io/nicolaka/netshoot@sha256:8b020dc72d8ef07663e44c449f1294fc47c81a10ef5303dc8c2d9635e8ca22b1",
                            "docker.io/nicolaka/netshoot:latest",
                        ],
                        SizeBytes: 211731928,
                    },
                    {
                        Names: [
                            "quay.io/submariner/submariner-operator@sha256:364b9846322f09948076214e10e41e51af2f9de39197d26da104bd7dce5b19b5",
                            "quay.io/submariner/submariner-operator:0.0.1",
                        ],
                        SizeBytes: 127034424,
                    },
                    {
                        Names: [
                            "quay.io/submariner/submariner-route-agent@sha256:5d6547308bb7cbbb3a24c984d5ac0ec390d2cef776c803cb9449ddf2044c6603",
                            "quay.io/submariner/submariner-route-agent:0.0.3",
                        ],
                        SizeBytes: 114103050,
                    },
                    {
                        Names: [
                            "docker.io/library/busybox@sha256:edafc0a0fb057813850d1ba44014914ca02d671ae247107ca70c94db686e7de6",
                            "docker.io/library/busybox:latest",
                        ],
                        SizeBytes: 1439735,
                    },
                ],
                VolumesInUse: nil,
                VolumesAttached: nil,
                Config: nil,
            },
        },
    ]
to have length 1

``

@tpantelis only those 2 tests failed because of having to worker nodes with a gateway label.
However, this seems like false alarm, as Submariner works even when another node has the gateway label.
If it is a real risk, then we should add it to docs, and even verify when running "subctl join" command, that only 1 gateway label exists.
+@skitt

No, a setup with multiple labeled nodes is legitimate, we shouldn’t document that it isn’t or change subctl so that it checks this.
How does the test end up with two labeled nodes?

One label was created directly with oc label command, and the other label - probably with prep_for_subm.sh (I might even run prep_for_subm.sh twice, not sure if that could create another label on other node).
But as you said, and also as I see on other tests, there's no issue of having multiple labels of gateway,
so I guess the test should not fail on "two worker nodes with a gateway label".

If you change the environment the test assumes it’s running in, it’s OK for it to fail IMO ;-). (If the test is supposed to verify something related to the number of labeled nodes at least.)

The gateway tests assume there is only one gateway node on entry. For one test, we start with one gateway node and expand to another. So we could relax the assumption if there's already 2 nodes.
The other test kills the lone engine pod and verifies connectivity when a new pod is started. This is specifically for the simple case where there's no gateway redundancy. If there is more than one gateway, we could first trim it down to one gateway. Or skip the test but I don't think that's ideal.
There is a third test coming, https://github.com/submariner-io/submariner/pull/264/files, that tests leader election fail-over that needs specific control over the gateways.
IMO, I think it's reasonable to assume a certain environment setup on entry rather than trying to handle/workaround other possible setups or, worse, skip tests.

IMO, I think it's reasonable to assume a certain environment setup on entry rather than trying to handle/workaround other possible setups or, worse, skip tests.

Exactly, these aren’t general purpose tests, they’re specific tests which are allowed to make assumptions about their environment.

@manosnoam OK to close?

@tpantelis, @skitt
I think that if the tests rely on a certain environment setup (in our case, assumes only one gateway label exists), it should also take care of creating that environment as part of the test (i.e. adding setup and teardown functions to the test framework).
But since the gateway label is a mandatory step for Submariner, not part of a certain environment or test scenario, and adding another label is not wrong - then the test should not fail if more than 1 one label exists. It should only fail if 0 label exists.

I will close this issue, and open a new one to reflect the requirement for this specific test case.

I think that if the tests rely on a certain environment setup (in our case, assumes only one gateway label exists), it should also take care of creating that environment as part of the test (i.e. adding setup and teardown functions to the test framework).

It does...


Stricter default arguments

This change the way that default arguments are handled.
Now, defaults arguments can only follow the used one.
This improve the readability of calls and the association between calls and declarations thus solve a lot of issues of users.
fun foo(a: nullable Int, b: Int, c: nullable Int) do ...
foo(null,2,null) # OK
foo(null,2) # equivalent
foo(2) # now refused! but previously accepted as equivalent.

Only exception: the last parameter of an assignment method is always the last argument
fun foo=(a: nullable Int, b: Int, c: nullable Int, d: nullable Int) do ...
foo(null,2,null) = 0 # OK
foo(null,2) = 0 # equivalent
foo(2) = 0 # now refused! but previously accepted as equivalent

No specific black magic is added to automatic constructor.
Therefore an optional constructor parameter in a class can becore mandatory in a subclass if a new mandatory attribute is introduced.
class A
   var a: nullable Int
end
class B
  super A
  var b: Int
end
var a1 = new A(null) # OK
var a2 = new A # equivalent
var b1 = new B(null, 2) # OK
var b2 = new B(2) # now refused! but previously accepted as equivalent

This issue only required some small adaptation in existing piece of code: nitdoc, sexp, serialization and dom. The latter is PRized independently in #1616 but included here for jenkins.
Most of these changes (first commits) are in fact bugfixes or make the code cleaner so this is an argument in favor of this new stricter specification.
This PR has also the advantage of simplifying the model as the whole policy of the default argument is moved to the typing analysis: it is now just a pure calling convention.
Close #1453

:shipit:

If I'm correct, varargs also have to be in last position, so you canot use varargs and default arguments? What about default varargs?

+1
I like to see nit in the right way again.

@Morriar varargs did not change: it is either vararg or default arguments.


Implementation for ddnss(.de)

Implementation for ddnss(.de)

Very cool, thanks!
I've created the repo here and added you to it: https://github.com/caddy-dns/ddnss
Feel free to push :+1:

Thanks! I pushed the repo and made a test run with ``xcaddy build --with github.com/caddy-dns/ddnss` and it worked perfectly!

@mholt Will the addon be available under https://caddyserver.com/download and have i to do anything that it appears there?


todo undo example - from click to on submit

Also removes ability to add an empty todo

@tonyspiro Thanks! CI is failing (linter is complaining about something in your code), please check this.

Thanks @omnidan, think I've got the issues fixed

Looks good, thanks a lot @tonyspiro :grin: :+1:

Thank you :metal:


Add step to install dependencies prior to building

Description
This PR adds a step to install the dependencies prior to building. This will fix the workflow of installing the binary when the dependent libraries are not installed yet, leading to false-positive failures of the install via binary workflow.
The reason why this was not caught before is that security dashboards plugin's current dependencies are only used in the server and test folders. In the build process, there is a step to run yarn to install dependencies, but the workflow is erroring out in the @osd/optimizer step when trying to add dependencies that live in the public folder. This is because the front end code needs to be bundled and thus when a dependency is not there it will error out. This should fix the build and install workflow for dependencies used in the frontend public folder.
We should not rely on some implementation detail of how OSD core runs yarn build and instead makes sure all necessary dependencies are available when we run that command.
yarn run v1.22.19
$ yarn plugin-helpers build && node build_tools/rename_zip.js
$ node ../../scripts/plugin_helpers build
 info deleting the build and target directories
 info running @osd/optimizer
 │ info initialized, 0 bundles cached
 │ info starting worker [1 bundle]
 │ succ 1 bundles compiled successfully after 11.6 sec
 info copying assets from `public/assets` to build
 info copying server source into the build and converting with babel
 info running yarn to install dependencies
 info compressing plugin into [securityDashboards-3.0.0.zip]
 info cleaning up compression temporary artifacts

Category
[Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation]
Why these changes are required?
What is the old behavior before changes and new behavior after changes?
Issues Resolved
[List any issues this PR will resolve (Is this a backport? If so, please add backport PR # and/or commits #)]
Testing
[Please provide details of testing done: unit testing, integration testing and manual testing]
Check List

[ ] New functionality includes testing
[ ] New functionality has been documented
[ ] Commits are signed per the DCO using --signoff

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

Confirm that this is how opensearch-build runs the build of plugin zips: https://github.com/opensearch-project/opensearch-build/blob/main/scripts/default/opensearch-dashboards/build.sh#L101


e2e:skip test including the [StateDirectories] label

Signed-off-by: Talor Itzhak<EMAIL_ADDRESS>

/cc @fromanirh


Fix race conditions when running multiple cells in native interactive window from codelens

For https://github.com/microsoft/vscode-jupyter/issues/6494

Codecov Report

Merging #6658 (5f25bb8) into main (95014cd) will decrease coverage by 0%.
The diff coverage is 2%.

@@          Coverage Diff          @@
##            main   #6658   +/-   ##
=====================================
- Coverage     69%     69%   -1%
=====================================
  Files        411     412    +1
  Lines      28336   28415   +79
  Branches    4212    4225   +13
=====================================
+ Hits       19628   19654   +26
- Misses      7046    7096   +50
- Partials    1662    1665    +3

Impacted Files
Coverage Δ

...eractive-window/nativeInteractiveWindowProvider.ts
15% <0%> (-2%)
:arrow_down:

...ence/interactive-window/nativeInteractiveWindow.ts
6% <33%> (+<1%)
:arrow_up:

src/client/datascience/kernel-launcher/types.ts
48% <0%> (-8%)
:arrow_down:

src/client/common/process/pythonDaemonPool.ts
75% <0%> (-5%)
:arrow_down:

src/client/common/errors/index.ts
69% <0%> (-4%)
:arrow_down:

...lient/datascience/kernel-launcher/kernelProcess.ts
72% <0%> (-3%)
:arrow_down:

src/client/datascience/commands/exportCommands.ts
34% <0%> (-1%)
:arrow_down:

src/client/datascience/baseJupyterSession.ts
68% <0%> (-1%)
:arrow_down:

.../datascience/notebook/notebookControllerManager.ts
78% <0%> (-1%)
:arrow_down:

.../client/datascience/notebook/notebookSerializer.ts
71% <0%> (ø)

... and 4 more

There's still a problem which also exists for the webview interactive window that I don't fully understand where, even though addCode is getting invoked with the right sequence of code cells, executeObservable seems to receive them out of order, i.e. if I do print(1) ... print(4), the actual Jupyter session is told to print(2); print(3); print(4); print(1), so the execution counts are all wrong because the execution requests were received in the wrong order. Might need your help with this @rchiodo

There's still a problem which also exists for the webview interactive window that I don't fully understand where, even though addCode is getting invoked with the right sequence of code cells, executeObservable seems to receive them out of order, i.e. if I do print(1) ... print(4), the actual Jupyter session is told to print(2); print(3); print(4); print(1), so the execution counts are all wrong because the execution requests were received in the wrong order. Might need your help with this @rchiodo

My guess is that the async code in addCode is causing one of them to wait but not another.

@rchiodo I'll fix up the promise chaining issue we talked about which impacts webview and explore refactoring the ctor in a separate PR


Getting SCP error when building HELK environment

Issue
Unable to copy public key to velocihelk machine, consistently getting the same error when running this with --helk enabled. Tested on multiple different machines.
Process to reproduce
python3 ad.py --domain_controller --ad_domain MrRobot.local --admin xyz --password xyz! --ad_users 50 --endpoints 3 --location eastus --domain_join --helk --resource_group testing-helk

Output during terraform apply:
Seeing this status pop up a few times during creation . At this point it has yet to stop the process and error out.
null_resource.velociraptor-config_upload1[0] (local-exec): Executing: ["cmd" "/C" "sleep 60"]
null_resource.velociraptor-config_upload1[0] (local-exec): 'sleep' is not recognized as an internal or external command,
null_resource.velociraptor-config_upload1[0] (local-exec): operable program or batch file

After letting it run for ~20 minutes I ended the process manually, here is the output from that:
╷
│ Error: waiting for creation of Linux Virtual Machine: (Name "velocihelk" / Resource Group "testing-helk-91nxi"): Code="RetryableError" Message="A retryable error occurred."
│
│   with azurerm_linux_virtual_machine.vh_vm,
│   on helk.tf line 53, in resource "azurerm_linux_virtual_machine" "vh_vm":
│   53: resource "azurerm_linux_virtual_machine" "vh_vm" {
│
╵
╷
│ Error: local-exec provisioner error
│
│   with null_resource.velociraptor-config_upload1[0],
│   on win10-1.tf line 138, in resource "null_resource" "velociraptor-config_upload1":
│  138:   provisioner "local-exec" {
│
│ Error running command 'sleep 60': exit status 1. Output: 'sleep' is not recognized as an internal or external command,
│ operable program or batch file

Tried running the apply one more time. Just noticing this output in the terminal.

null_resource.helk-scp-velociraptor-config: Provisioning with 'remote-exec'...
null_resource.helk-scp-velociraptor-config (remote-exec): Connecting to remote host via SSH...
null_resource.helk-scp-velociraptor-config (remote-exec):   Host: <IP_ADDRESS>
null_resource.helk-scp-velociraptor-config (remote-exec):   User: helk
null_resource.helk-scp-velociraptor-config (remote-exec):   Password: false
null_resource.helk-scp-velociraptor-config (remote-exec):   Private key: true
null_resource.helk-scp-velociraptor-config (remote-exec):   Certificate: false
null_resource.helk-scp-velociraptor-config (remote-exec):   SSH Agent: false
null_resource.helk-scp-velociraptor-config (remote-exec):   Checking Host Key: false
null_resource.helk-scp-velociraptor-config (remote-exec):   Target Platform: unix
null_resource.helk-scp-velociraptor-config (remote-exec): Connected!
azurerm_windows_virtual_machine.azurerm-vm-win10-1: Still creating... [50s elapsed]
azurerm_windows_virtual_machine.azurerm-vm-win10-3: Still creating... [50s elapsed]
null_resource.helk-scp-velociraptor-config (remote-exec): Hello World
null_resource.helk-scp-velociraptor-config: Provisioning with 'local-exec'...
null_resource.helk-scp-velociraptor-config (local-exec): Executing: ["cmd" "/C" "scp -o StrictHostKeyChecking=no -i ./ssh_key.pem helk@<IP_ADDRESS>:/home/helk/config.yaml ./files/Velociraptor.config.yaml"]
null_resource.helk-scp-velociraptor-config (local-exec): 'scp' is not recognized as an internal or external command,

I would like to put emphasis on this line
null_resource.helk-scp-velociraptor-config (local-exec): 'scp' is not recognized as an internal or external command,
I confirmed the machine I am running the commands from does have SCP (pretty sure this wasn't a requirement just wanted to double check.
I manually ended the procss again, this time I am seeing this error reguarding running the following command. (
│ Error: local-exec provisioner error
│
│   with null_resource.helk-scp-velociraptor-config,
│   on helk.tf line 124, in resource "null_resource" "helk-scp-velociraptor-config":
│  124: provisioner "local-exec" {
│
│ Error running command 'scp -o StrictHostKeyChecking=no -i ./ssh_key.pem helk@<IP_ADDRESS>:/home/helk/config.yaml ./files/Velociraptor.config.yaml': exit
│ status 1. Output: 'scp' is not recognized as an internal or external command,
│ operable program or batch file.

Complete output
logoutput.txt
As always if more details are needed let me know
P.S. shoot me a follow back on twitter, would love to shoot you a couple bucks for a drink

Hey @Johndpete316
Thanks for sharing.  I'm actually out of the country now here in Germany, so my response might be spotty.
So this definitely looks like an issue with scp running on the same system running terraform.  What OS are you running this from?  What happens when you just type scp?  What output do you get?
Yes, I should have mentioned that scp was a requirement.  Assumed that most users would be running from Linux or MacOS.  I believe with a powershell prompt in windows you can run scp by default too.  Just let me know.  The local-exec provisioner error means it is coming from the local machine.  Also odd about sleep as sleep should be included in Linux.  To make it easier if you can just try running all of your builds from stock Ubuntu Linux (i used 20.04) you should be gtg.
Thanks on the offer for a beer.  I followed you back.  I noticed you are in/from Michigan.  Born in Detroit and spent several years in Ann Arbor.

@Johndpete316
Also, I have on my ToDo list to completely refactor the code for Velociraptor and HELK, getting rid of the local-exec provisioner and Ansible playbooks.  Everything will be implemented with user-data and bash, making it much more reliable.  I have an open issue to get this done.  I hope you can get around your current issues as I'm still a couple of weeks away from starting this:
https://github.com/iknowjason/PurpleCloud/issues/12

Confirmed issue is on our side. When switching over to a Ubuntu 20.04 local-exec was able to scp into remote machine with no issue.
Thank you for taking the time to look into it!


Open Source Verilog Simulator with This

Hi Taichi,
I was searching for open-source AXI BFMs and landed onto your repository on github. This and your rggen is awesome piece of work and is very helpful. A big thank you to you for putting your hard work up there.
I am trying to use the verification elements for an all-AXI 2x3 switch where both the sides operate on AXI3/4.(I I've got experience in building backbones (AXI/APB/AHB etc) and worked on Vcs/NCVerilog before.)
I am trying to explore it more and trying to see how we can use it. I've got some questions about it -

Is it likely to work with iVerilog or Verilator or SV-Parser etc open-source Verilog simulators. There are VCS and Xcellium make files but we don't have those tools. Have you ever tried it. We gona try fresh, but in case you already know of issues here.

Will we able to use in an axi-switch verification environment...? In such a testbench, we need 2 AXI master BFMs, 3 AXI slave BFMs, protocol monitors and checkers and transactors plus testcases.
There are plenty of tasks and functions in the code and we are trying to read through and unwind them. But without a arch/document and the components, it's taking us some time. Hence the question.

Regards.

Hi @coder-humbitious ,
Thank you for focusing on my AXI BFM !
Followings are answers for your questions.

Is it likely to work with iVerilog or Verilator or SV-Parser etc open-source Verilog simulators.

I think there are no OSS simulators supporting my AXI BFM because my AXI BFM is built on UVM (Universal Verification Methodology; industry standard platform to build testbenches written in SystemVerilog). To use my AXI BFM and UVM, commercial simulators, such as VCS and Xcelium are needed.
There are two ways to use simulators supporting UVM;

Use EDA Playground. You can use the latest VCS without a fee on this side. But there are some limitations like run time, I think.
Use the latest Vivado simulator. From version 2019.2, Vivado simulator supports UVM and I think you can use this simulator without a fee. However, I have not yet used this simulator so I don't know if my AXI BFM works with this simulator.

Will we able to use in an axi-switch verification environment...?

Maybe yes. I use my AXI BFM to verify my NoC fabric. You can refer the testbench for my NoC fabric to create your AXI switch. Following links are to the testbench and testcases implementations.
https://github.com/taichi-ishitani/tnoc/tree/master/env/axi_adapter
https://github.com/taichi-ishitani/tnoc/tree/master/test/axi_adapter

we are trying to read through and unwind them

You only have to read following source files because these are implementing user interface.

Interface to connect DUT

https://github.com/taichi-ishitani/tvip-axi/blob/master/src/tvip_axi_if.sv

User interface to create stimulus and to get monitored transactions

https://github.com/taichi-ishitani/tvip-axi/blob/master/src/tvip_axi_item.svh
https://github.com/taichi-ishitani/tvip-axi/blob/master/src/tvip_axi_master_access_sequence.svh
https://github.com/taichi-ishitani/tvip-axi/blob/master/src/tvip_axi_master_write_sequence.svh
https://github.com/taichi-ishitani/tvip-axi/blob/master/src/tvip_axi_master_read_sequence.svh
https://github.com/taichi-ishitani/tvip-axi/blob/master/src/tvip_axi_slave_default_sequence.svh

You're welcome to ask any questions !


Char Measurement Bug in v4 on Mobile Safari

Hi,
there seems to be a bug with chars being incorrectly measured when zooming a page containing a CodeMirror v4 instance on Mobile Safari (latest iOS 7.1 version), v3.23 works fine. After zooming the viewport, calls to the method coordsChar() always return 0 for ch-positions (line positions seem to be correct, though). When the page is not zoomed, correct line and ch values are returned. With v3.23, both zoomed and unzoomed pages work.
I've created a simple example to demonstrate the problem:
http://jsbin.com/baqeqeso/1
If you open the page in Safari, zoom on the button and click the button, it reports line:1, ch:0. The expected result is line:1, ch:9, which is correctly displayed when the page is not zoomed.
Any ideas?

I am not able to reproduce this with current CodeMirror and iOS 8's Safari


Update google-api-python-client and httplib2

The nightly-run.sh script as run in production Jenkins is failing
with: httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed (_ssl.c:661)

An issue discussed on the google-api-python-client github suggests
upgrading might solve this:
https://github.com/google/google-api-python-client/issues/453

@schmie

I think there still be might be problems with this combination of dependencies... when I run it I get:
matmoore@gds3946:~/govuk/search-analytics on update-google-python-api $ python scripts/fetch.py page-traffic.dump 14
Traceback (most recent call last):
  File "scripts/fetch.py", line 7, in <module>
    from analytics_fetcher.fetch import fetch
  File "analytics_fetcher/fetch.py", line 3, in <module>
    from .support.ga_client import ClientContext
  File "analytics_fetcher/support/ga_client.py", line 5, in <module>
    from analytics_fetcher.support.auth import open_client, AuthFileManager
  File "analytics_fetcher/support/auth.py", line 31, in <module>
    import gapy.client
  File "/Users/matmoore/govuk/search-analytics/env/lib/python2.7/site-packages/gapy/client.py", line 1, in <module>
    from apiclient.discovery import build
  File "/Users/matmoore/govuk/search-analytics/env/lib/python2.7/site-packages/apiclient/__init__.py", line 18, in <module>
    from googleapiclient import channel
  File "/Users/matmoore/govuk/search-analytics/env/lib/python2.7/site-packages/googleapiclient/channel.py", line 63, in <module>
    from googleapiclient import errors
  File "/Users/matmoore/govuk/search-analytics/env/lib/python2.7/site-packages/googleapiclient/errors.py", line 26, in <module>
    from oauth2client import util
ImportError: cannot import name util

Maybe we need to pin a version of oauth2client as well?
That said, I think this we may as well merge this change as it's a step in the right direction.

Thanks for looking at this. I clearly have to aim to run this to test it properly - thought resolving pip dependency errors was good enough- sorry for the overhead..


feat: https app dev servers

⏳ This pull request is set to merge as part of a Graphite merge job
Stack job ID: x1Hu7jfXHcvvjIF6tX3W.
See details on graphite.dev


KubeFlow or Kubeflow?

I'm confused of the project name. Is it KubeFlow or Kubeflow?
Personally speaking, KubeFlow is better because Kube and Flow are individually selected from two communities, which are Kubernetes and TensorFlow (can be extended to ML community in the future).

Base on reading https://news.ycombinator.com/item?id=15873659
It seems to me that it is KubeFlow for now but Kubeflow in future.

NOTE: The name "flow" does not refer directly to TensorFlow; if anything it's a nod at all the river themes that pop up in the ML community (eg FBLearner Flow)

"Kubeflow" please! (My opinion, I hate midword capitalization)
On Tue, Dec 19, 2017 at 19:43 Subin Modeel<EMAIL_ADDRESS>wrote:

Base on reading https://news.ycombinator.com/item?id=15873659
It seems to me that it is KubeFlow for now but Kubeflow in future.
NOTE: The name "flow" does not refer directly to TensorFlow; if anything
it's a nod at all the river themes that pop up in the ML community (eg
FBLearner Flow)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/kubeflow/issues/44#issuecomment-352956753, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADIdcZ4ywmrJMQJu7il9fqKIUyVr95Aks5tCIJigaJpZM4RHyMT
.


Integration tests for the OAuthBearerValidation filter

Type of change

Enhancement / new feature

Description
Addresses missing integration test coverage for the OAuthBearValidationFilter.
Uses navikt/mock-oauth2-server (running in a container) to provide the OAuth server backend.
Currently just covers happy path and one failure case.
Additional Context
Why are you making this pull request?
Checklist
Please go through this checklist and make sure all applicable tasks have been done

[x] Write tests
[ ] Make sure all tests pass
[ ] Review performance test results. Ensure that any degradations to performance numbers are understood and justified.
[ ] Make sure all Sonarcloud warnings are addressed or are justifiably ignored.
[ ] Update documentation
[ ] Reference relevant issue(s) and close them after merging
[ ] For user facing changes, update CHANGELOG.md (remember to include changes affecting the API of the test artefacts too).

I think sonar is failing because we don't exercise the no arg ctor... Its cheap to fix I guess but a bit annoying


neural_sde example and test_brownian.py throw ValueError: ShapeDtypeStruct: dtype must be specified.

When running the neural_sde jupyternotebook, I receive the following error message after calling main() cell:

No GPU/TPU found, falling back to CPU. (Set TF_CPP_MIN_LOG_LEVEL=0 and rerun for more info.)

E       ValueError: ShapeDtypeStruct: dtype must be specified.

.conda/lib/python3.10/site-packages/jax/_src/api.py:3210: ValueError
------------------------------ Captured log call -------------------------------
WARNING  jax._src.lib.xla_bridge:xla_bridge.py:362 No GPU/TPU found, falling back to CPU.
E       ValueError: ShapeDtypeStruct: dtype must be specified.

.conda/lib/python3.10/site-packages/jax/_src/api.py:3210: ValueError
------------------------------ Captured log call -------------------------------
WARNING  jax._src.lib.xla_bridge:xla_bridge.py:362 No GPU/TPU found, falling back to CPU. (Set TF_CPP_MIN_LOG_LEVEL=0 and rerun for more info.)
-------------- generated xml file: /tmp/tmp-5396myg7L9xsntGm.xml ---------------
=========================== short test summary info ============================
FAILED test/test_brownian.py::test_shape_and_dtype[UnsafeBrownianPath] - Valu...
FAILED test/test_brownian.py::test_shape_and_dtype[VirtualBrownianTree] - Val...
============================== 2 failed in 1.44s ===============================
ERROR conda.cli.main_run:execute(47): `conda run python /home/user/.vscode-server/extensions/ms-python.python-2023.2.0/pythonFiles/get_output_via_markers.py -m pytest --rootdir /home/user/github/diffrax --override-ini junit_family=xunit1 --junit-xml=/tmp/tmp-5396myg7L9xsntGm.xml ./test/test_brownian.py::test_shape_and_dtype` failed. (See above for error)

Is there a version of jax, which I can try to pinpoint the cause of this behavior, or any settings I can change?
 This is due to a change in JAX's behaviour (https://github.com/google/jax/pull/13814). This should be fixed in the next release of Diffrax. (In the next few days.)

I was playing around with the SDE example  as well,  I managed to get it working by changing
jax.ShapeDtypeStruct(shape, jax.dtypes.canonicalize_dtype(None))
to
jax.ShapeDtypeStruct(shape, jax.dtypes.result_type(None))
in /diffrax/brownian/paths.py and /diffrax/brownian/tree.py
However it does break some of the tests and I'm not sure what any other downstream implications are but the example does complete

This should now have been fixed in v0.3.0.


[BEAM-498] Add unwrapped access to new DoFn in ParDo and use it in the DirectRunner

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[x] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[x] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[x] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[x] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

There is one known test failure, where the restriction coder for a single-output splittable DoFn cannot be determined because some type descriptor/token has been wiped out to just Object.
R: @bjchambers @tgroh

Actually, the one test failure I was getting in IntelliJ is because I just run all the SDK tests with the DirectRunner. But the test ParDoTest.testRejectsSplittableDoFnByDefault actually fails with the DirectRunner, and since it isn't a NeedsRunner test it won't run in our official test suite.
Nonetheless, I think it indicates a potential problem. Not necessarily blocking.

Since the changes to the direct runner ended up being ~10 characters, going to move @tgroh to CC and merge once green. Looks like Spark errors might be real failures due to changes in how the contexts do aggregators - we'll see.
R: -@tgroh
CC: @tgroh

Actually my last comment is not accurate for this approach - it should be a noop for other runners.


Upgrade to scalismo-0.17.0 from RC1

This PR updates the dependency from scalismo-v0.17-RC1 to scalismo-v0.17.0 and also updates the tooling (scala and sbt).

Thanks!


Re-add openssh-client to docker image

PR Type

Bugfix Pull Request

Follows https://github.com/ansible/molecule/issues/1813#issuecomment-471035576 where I took a look at https://github.com/ansible/molecule/commit/bce7bfebcaa66c9417f653778f7e4bf03a554af5 to see if we're dropping any packages we shouldn't be. I think this is the only one! Original report for this change was in https://github.com/ansible/molecule/pull/1604.

Thanks for reviewing @webknjaz, good catch. I've fixed that up and will merge based on https://github.com/ansible/molecule/issues/1813#issuecomment-471577888.


1.0.0

Coverage remained the same at 100.0% when pulling eb288aff6bca6e8f6fc8986bdafaf1871a806c8b on dev into 253a0a2309ba1fef874cbe406528784ceda8333e on master.

Coverage remained the same at 100.0% when pulling eb288aff6bca6e8f6fc8986bdafaf1871a806c8b on dev into 253a0a2309ba1fef874cbe406528784ceda8333e on master.

Coverage remained the same at 100.0% when pulling eb288aff6bca6e8f6fc8986bdafaf1871a806c8b on dev into 253a0a2309ba1fef874cbe406528784ceda8333e on master.


Deploy to Heroku

Deployed application to Heroku with JAWSDB add-on
https://rocky-fortress-05253-ca50dfe67020.herokuapp.com/


Timer freezes after computer sleeps/shutoff

A great tool i've really enjoyed using. However, I've noticed that sometimes after my computer sleeps and I re-awaken it, the timer will be frozen. Single press/long press does nothing to begin the next cycle and I basically have to completely delete/reinstall the app for it to work again. All my other apps on the Stream Deck will be working after re-awakening.
this is on an M1 Mac - it doesn't seem to happen with any great consistency, maybe once every few days of use.

That's an interesting bug that you've found. All of my testing thus far has been on a Windows 10 machine and that seems to handle resetting the timer back to the start of the state if the computer goes to sleep when the timer is active. I do have a non-M1 Mac that I can try testing it on, I'll update this issue if I'm able to replicate the problem.

Any news on this? It happened to me too, Macbook Pro M1. Congratulations on the plugin! It's very useful and cool.

I'm getting the exact same issue with my windows 11 computer, only after the computer goes to sleep. I have found two methods to remedy this issue

Reboot the computer; or
Kill the both stream deck and elgato audio server processes from task manager.

Whilst these two remedies work, they're an inconvenience. Please find a permanent solution to this issue.


Update spirv cross

I've recently added some assertions to spirv-cross to prove it is not vulnerable to overreads/overwrites in two of its functions and want to include them here to prove the safety of Godot too.

It looks like you accidentally included some unrelated changes

It looks like you accidentally included some unrelated changes

At first I was only going to include the relevant rows, but I thought it would be better to include everything which had changed since its changes was last updated in godot.

What about files listed in thirdparty/README.md as intentionally not included like *hlsl files?

I mostly updated the pre-existing files and didn't include new ones since I saw not all of the files from that repo being in the thirdparty folder.

What about files listed in thirdparty/README.md as intentionally not included like *hlsl files?

I mostly updated the pre-existing files and didn't include new ones since I saw not all of the files from that repo being in the thirdparty folder.

Looks like you accidentally did something like git commit -a or git add . because your PR definetely includes those new files

And please also update thirdparty/README.md file

It is update to a newer version from upstream? If yes, so please also update thirdparty/README.md to a newer commit


提交两个插件 MybatisPlus和OpenFeignPlugin

提交两个插件
1、MybatisPlus
2、OpenFeignPlugin ，适用于openfeign默认的HttpURLConnection请求方式 （feign.Client$Default）

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


Autocomplete

Passing previously seen command args to the autocomplete script which allows the --help flag to run on the commands you've already typed allowing you to get the help from the subcommands. I also removed extra whitespace from the front of the lines.
I've tested this with bash, sh, and zsh without issues. This is a low-risk commit and changes nothing with the CLI code.
Examples:
Level One Autocomplete:
bash-4.4$ datica
certs         db            domain        git-remote    invites       logout        metrics       releases      sites         support-ids   vars          worker
clear         deploy        environments  images        jobs          logs          rake          rollback      ssl           update        version
console       deploy-keys   files         init          keys          maintenance   redeploy      services      status        users         whoami

Level Two Autocomplete:
bash-4.4$ datica db
backup    download  export    import    list      logs

LGTM


Human Attack

Adds human vs. bot games
Also includes code from @tomtseng to fix parsing in case of resignation, input manually from https://github.com/HumanCompatibleAI/KataGoVisualizer/commit/dbd9c0eb1ef55c4f90c46252aececed5bd20ee6f

We should probably merge #49 first, rebase and re-run this (to pick up 2048->4096 visit change etc), then merge this PR. Either sequence is going to leave some conflicts, but I think #49 seems like the more fundamental one.

We should probably merge #49 first, rebase and re-run this (to pick up 2048->4096 visit change etc), then merge this PR. Either sequence is going to leave some conflicts, but I think #49 seems like the more fundamental one.

I merged #49 just now and fixed the merge conflicts in this PR

I've added the position analysis games (https://deploy-preview-52--goattack.netlify.app/game-analysis#position-analysis) to make those available. Other than that should be good to go, will merge tomorrow morning if no further comments, or someone else feel free to.


SimpleMDE is buggy with mobile browser

I encountered some strange habits by the simpleMDE editor while trying to edit some posts on my mobile. When I erase some words, then type something different, then erase something again, everything that was erased previously comes back into existence.
eg.:

"My xde name is" -> erase and add something
"My name is max" -> then erase something
"My xde name is ma"

can anybody confirm this behaviour?

I use a CyanogenOS/Android phone with Firefox mobile browser - I also tested it with an other browser, which led to the same bahavior. I've first encountered this bug about 6 months ago, so I don't think it has something to do with the current versions of my mobile-software.
--
EDIT: I don't have these problems when using the basic bludit-markdown-editor, that shows up when deactivating SimpleMDE.

Do you have this problem when using SimpleMDE outside of Bludit?
If so, you will have to report this to SimpleMDE instead of here.


Add support for IE garden cloche

Would be very nice that it could be automated with the cloche, or Thermal Expansion Phytogenic insolator.
Perhaps that would ignore the light level, but sure it lets config the growth speed and soil type.

i do like this idea..we'll have to see as the mechanic is somewhat involved (for example, you can use bonemeanl on the Ender Daisy if it is planted on End Stone, but not on normal grass/dirt)..also speeds are increased on End Stone...I have never used IE myself other than basic energy gen years ago, so I would need to learn how the cloches work...basically same for the Insolator..but I would very much like to add these integrations

a vidya
...soon™

Only added support for the garden cloche for now..will look into Phytogenic Insolator later


mac打包报错

109 warnings and 1 error generated.
make[2]: *** [CMakeFiles/main.dir/models.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
1 warning generated.
1 warning generated.
make[1]: *** [CMakeFiles/main.dir/all] Error 2
make: *** [all] Error 2
mac version: ventura 13.6.6

chatllm.cpp/models/llama.cpp:50:152: error: no matching constructor for initialization of 'Config'
Model<BaseConfig, Embedding, RMSNorm, LayerBlock, int, int, int, int, int>>(type, config, MEM_SIZE, SCRATCH_SIZE), config(config)
chatllm.cpp/models/llama.cpp:3:12: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'const BaseConfig' to 'const chatllm::llama::v2::Config' for 1st argument
struct Config : public BaseConfig
chatllm.cpp/models/llama.cpp:3:12: note: candidate constructor (the implicit default constructor) not viable: requires 0 arguments, but 1 was provided

Which compiler are you using? and which version?

You can update and have a try. I think it can be fixed by 23d76fbab2678b99da2cd8eea1508481288f09c1.

Compiled successfully, thanks！


remove TSD from 06-sharing.md

I would suggest to remove TSD from 06-sharing.md as it is not a data deposition repository but a environment for computing of sensitive data

Thanks! @Sabryr can you please review?


For date picker

We  can't able to display datepicker opened by default like calender. We always need input box for that there should have feature that datepicker can show standalone means we can show datepicker view not dialogbox

Closing this issue as it does not follow the issue template. Please file a new issue that follows the template, which gives the team the information needed to investigate.
(this is a canned response)


Remove outdated and broken examples

@jbeezley are we going to replace them with updated / newer examples?

For the most part, these have been superseded by new examples or tests already.  The only exception is the feature demo, which was written using the old feature api, so would have to be totally rewritten anyway.  I could redo this one, but I don't have time in the near future to do it.

Sounds good. I created an issue for that (https://github.com/OpenGeoscience/geojs/issues/409). Other than that :+1: LGTM

I am wondering why garant is not running?

http://my.cdash.org/index.php?project=geojs
looks like it is to me.
On Wed, Jul 1, 2015 at 10:01 AM, Aashish Chaudhary<EMAIL_ADDRESS>
wrote:

I am wondering why garant is not running?
—
Reply to this email directly or view it on GitHub
https://github.com/OpenGeoscience/geojs/pull/408#issuecomment-117685072.

Now i see it, thanks.

:+1:


Incorrect behavior of lang.int:abs function

Description:
$title
Steps to reproduce:
import ballerina/io;
public function main() {
    int a1 = -9223372036854775807 - 1;
    int b1 = a1.abs(); // should panic

    io:println(b1);
}

import ballerina/io;
public function main() {
    int a1 = (-9223372036854775807 - 1).abs(); // should panic
    io:println(a1);
}

These print -9223372036854775808, but should panic at runtime since<PHONE_NUMBER>854775808 would overflow
Affected Versions:
slbeta2

The spec on int type says,

The int type consists of integers between -9,223,372,036,854,775,808 and 9,223,372,036,854,775,807

Which indicates the int range to be (-2^63  to 2^63 - 1).
Note that, here the value -2^63 - 1 would overflow.
The compiler validation for int is also complies to this range.

But the langlib says that value  -9,223,372,036,854,775,808 would overflow
https://github.com/ballerina-platform/ballerina-spec/blob/11277d73b77f5f0c2871c7e7f04cc803ca9f31b2/lang/lib/int.bal#L57
Due to this inconsistency between the langlib spec and the lang spec, we need to confirm the expected behavior.

We have behavior inconsistensies for the int value -9,223,372,036,854,775,808.
Eventhough the lang.int specifies that the value will overflow for  -9,223,372,036,854,775,808,
https://github.com/ballerina-platform/ballerina-spec/blob/11277d73b77f5f0c2871c7e7f04cc803ca9f31b2/lang/lib/int.bal#L57
It is not restricted in compiler.

And the arithmetic operations that results in -9,223,372,036,854,775,808 are also not panicking for overflow.
public function main() {
    int a = -9223372036854775806 - 2; // does not panic
    int b = -9223372036854775807 - 2; // panics
}

So, it would be an inconsistency if we panic only for int:abs().
What should be the expected behavior?
Do we need to panic for all the above cases? @hasithaa

The expression -9,223,372,036,854,775,808 will overflow, But not the value -9,223,372,036,854,775,808.
This is how the evaluation of the expression will overflow. The said Expression is an unary expression of operator - and literal value of 9,223,372,036,854,775,808. But literal 9,223,372,036,854,775,808 is larger than int:MAX_VALUE. So when evaluating it, it will overflow. Theoretically, we can't write the expression -9,223,372,036,854,775,808, that is why it is written in different way here.  https://github.com/ballerina-platform/ballerina-spec/blob/11277d73b77f5f0c2871c7e7f04cc803ca9f31b2/lang/lib/int.bal#L57
But in JBallerina we are doing constant folding, at the compile time. So -9,223,372,036,854,775,808 is parsed as int:MIN_VALUE, That is why it is not overflowing.

Fix merged to beta4. Hence, closing this.


Analytics and Cookie changes

:wrench: Fixes

Remove the old basic cookie consent solution
Implement the new cookie consent solution

Resolves #195

@AdamChrimes you've got conflicts

@mikemonteith I've resolved the conflicts


The "Branch-Protection" check seems to fail to detect the status of "status checks"

I turned off the "Require status checks to pass before merging" setting and ran something like
curl  -u "***" -H "Accept: application/vnd.github.v3+json"   https://api.github.com/repos/evverx/systemd/branches/main/protection/required_status_checks

to make sure they are off:
{
  "message": "Required status checks not enabled",
  "documentation_url": "https://docs.github.com/rest/reference/repos#get-status-checks-protection"
}

scorecard says that "Info: strict status check enabled on branch main" and increments the score:
scorecard  --format json --show-details --verbosity Debug --checks Branch-Protection  --repo=https://github.com/evverx/systemd
...
"Info: strict status check enabled on branch 'main'","Warn: status checks for merging have no specific status to check on branch 'main'"

Thanks for the report. This setting needs an admin token to be retrieved. We've prepared https://github.com/ossf/scorecard/pull/1243 to ignore the settings when it's not available.

I use the same token with both curl and scorecard so I'm not sure why the results would be different. Does scorecard uses some other endpoints to get the protection rules?

we use graphQl APIs. @azeemsgoogle knows more about this part of the code

Fixed in #1252. Closing.


Updated Links page

Added Move Syntax extension link
Added Local Sui Exlorer link
Added Sui dApp Starter

Thanks @mario4tier


Failures on [anaysis_server] Cancel in-progress LSP completion requests if another arrives

There are new test failures on [anaysis_server] Cancel in-progress LSP completion requests if another arrives.
The tests
pkg/dds/test/sse_smoke_test RuntimeError (expected Pass)

are failing on configurations
unittest-asserts-release-mac

Logs: https://dart-ci.appspot.com/log/pkg-mac-release/unittest-asserts-release-mac/22444/pkg/dds/test/sse_smoke_test

I don't think this failure is related to 055774958d7158fccb95dd67805cefc89bfb3598. That change is package:analysis_server but this failure is in DDS.
The error contains this:
SessionNotCreatedException (500): session not created: This version of ChromeDriver only supports Chrome version 101
Current browser version is 103.0.5060.134 with binary path /opt/s/w/ir/cache/builder/sdk/third_party/browsers/chrome/Google Chrome.app/Contents/MacOS/Google Chrome
I don't know how Chrome/ChromeDriver are versioned in the SDK, but perhaps this is the cause? @bkonyi do you know about this?

Looks like this has come up before. there's an open issue at #43743 that may be tracking it?

Yeah, looks like it. Closing this as a dupe.


fix: auto_expand_width gets caught in infinite loop and hangs neovim (#624)

Should fix https://github.com/nvim-neo-tree/neo-tree.nvim/issues/624.
For more info and discussion, please read the above issue.

Actually, this is still not quite right. I just got into a situation where I could not scroll vertically in a neo-tree window because every movement caused a re-render and put me back to the top of the window.
I disabled the feature in my own config for now. I think this can use some more work.

@cseickel Thanks for testting.
Could you give me a minimal way to reproduce your issue?
I really cannot have the same behavior with my setup and I have no issues whatsoever.
And could you test what happens when auto_expand_width = false and toggle it on with keybind after opening neo-tree.
The rendering should only happen on what was already implementing before adding this feature or when the rendering text length exceeds the width of the window.
I could not think of a reason why this feature interferes with scrolling.
Thanks in advance.

@pysan3 I think this is the core issue: https://github.com/nvim-neo-tree/neo-tree.nvim/blob/4c3d9d55591ffad68518a77447f2ed141913685f/lua/neo-tree/ui/renderer.lua#L946
That creates an infinite loop of renders whenever the auto_expand code is actually triggered.
I ended up rewriting the logic to be more direct and ensure there is only one extra render. I'm also making it something that can be reused for position = current and float. I'm not quite done with that but the code is in #629.

@cseickel Thank you so so much!!
Your rewrite works like a charm!


Include onlyargs

https://crates.io/crates/onlyargs
Article about onlyargs mention argparse-rosetta-rs, but does not try to add the new parser to the comparison table for some reason.

See https://www.reddit.com/r/rust/comments/12kaiw8/improving_build_times_for_derive_macros_by_3x_or/jg3ms63/


Rating an originally unrated level with a more difficulties face

this s result.

Bug existed since v1.2.5, fixed in v1.2.6


Difference between cs.SendMessage() and cs.SendMessageStream()

Hello
I noticed that the output results in the two methods are different. In this case, the normal method returns the full result, and the stream method performs 2-3 iterations and fails with an error (when resp.Candidates[0].Content = nil).
Example of initialization:
`gen_ctx = context.Background()
gen_client, _ = genai.NewClient(gen_ctx, option.WithAPIKey(Cfg.GeminiKey))
gen_TextModel = gen_client.GenerativeModel("gemini-1.0-pro")

text := "напиши первые 3000 сиволов из библии"

// 1 type
cs := gen_TextModel.StartChat()
resp, err := cs.SendMessage(gen_ctx, genai.Text(text))

// 2 type
cs := gen_TextModel.StartChat()
iter := cs.SendMessageStream(gen_ctx, genai.Text(text))`

Please tell me, is this normal behavior or can I somehow fix it so that the capabilities of the streaming method are not inferior to the usual one?

Thanks for the report, but we need more information.
Can you please create a minimal reproducible example of the bad path you're observing? Is it something you see consistently for all queries, or just a specific one?

main.txt
I have prepared an example. I used only one request text.
The main thing is that the stream method always receives "resp.Candidates[0].Content = nil" in the last iteration, but if you pause for 1 second inside the loop, the error disappears. At shorter pause intervals it remains. Please check this moment.

The underlying problem is that something in your prompt triggered the model to generate some sort of protected (copyrighted) material, and that caused it to stop. Technically, the model returned a new FinishReason that we hadn't accounted for. The fix will prevent the panic, but your prompt will still result in an error.

I should add that I couldn't reproduce the change in behavior due to sleeping. I always got the same result.


neighbor layer unequal grad problem

example: layer1->layer2
then, out_grad of layer1 should equal to in_grad of layer2, right?
but not here, why?

This question is a bit without context.
This should in general be true, unless layer1 is also connected to other layer, and the gradient will be summed up.  If it was not the case on your side, maybe consider post an minimum example to reproduce the problem

layer1 has pre layer, and only one post layer.
for example:
I set the values of in_grad of layer2 all 1s. and then the out_grad of layer1 only have several 1s, others are 0s.
this is really strange.
BTW, layer2 is the loss layer.

BTW2, layer2 has serveral label parameters, not only one.

Yes, this is strange if it is what you described, it could be  memory overflow problem that faied to assign some of in_grad.
Or you forget to declare dependency to out_grad, in such case the out_grad will simply be invalid in backward

actually, the layer1 is cov layer, and the layer2 is my self-defined loss layer. and the loss layer do not deed to backdepend to the out_grad.

actually, the layer1 is cov layer, and the layer2 is my self-defined loss layer. and the loss layer do not need to backdepend of the out_grad.

maybe it is he memory overflow problem of in_grad of layer2.
but I print the values of in_grad after I set its value. and it is normal.

the following is my loss layer's infershape, should be no problem:
  bool InferShape(std::vector<TShape> *in_shape,
                  std::vector<TShape> *out_shape,
                  std::vector<TShape> *aux_shape) const override {
    using namespace mshadow;
    CHECK_EQ(in_shape->size(), 5);

    TShape &datashape = (*in_shape)[anchor_regcost_enum::kData];
    TShape &labelshape = (*in_shape)[anchor_regcost_enum::kLabel];
    TShape &coordshape = (*in_shape)[anchor_regcost_enum::kCoordLabel];
    TShape &bbshape = (*in_shape)[anchor_regcost_enum::kBBsLabel];
    TShape &infoshape = (*in_shape)[anchor_regcost_enum::kAnchorInfoLabel];

    labelshape = Shape4(datashape[0], param_.anchornum, datashape[2], datashape[3]);
    coordshape = Shape4(datashape[0], 2, datashape[2], datashape[3]);
    bbshape = Shape4(datashape[0], 4, datashape[2], datashape[3]);
    infoshape = Shape4(param_.anchornum, 2, datashape[2], datashape[3]);

    out_shape->clear();
    out_shape->push_back(datashape);

    return true;
  }

my loss layer2:
    tdata_in = 1.0f;
    tlabel = 2.0f;
    tcoordlabel = 3.0f;
    tbbslabel = 4.0f;
    tinfolabel = 5.0f;
    tgrad_in = 6.0f;

the out_grad of layer1 is all 6.0s.
but when do:
//    tdata_in = 1.0f;
//    tlabel = 2.0f;
//    tcoordlabel = 3.0f;
//    tbbslabel = 4.0f;
//    tinfolabel = 5.0f;
    tgrad_in = 6.0f;

the out_grad of layer1 is sparse 6.0s, others are 0s.
really, really strange....................

I found the in_grad value is affected by in_data.

in_data is just like a mask of in_grad.

check the inplace option, if you set that, but the operation you performed cannot be done in inplace manner

I have no inplace functions.

zero values of in_data should has no correspond values of in_grad. maybe its the reason.

I have little evidence on what happened on your side then. Maybe you can do some unit tests on the operators to see if the behavior is correct.

does mshadow or mxnet process the following automatically?
zero values of in_data should has no correspond values of in_grad

I don't understand your question

i am confused a little also....

for example:
tdata_in = 0.0f;
tgrad_in = 6.0f;

will cause pre layer1's values be all 0s.
but
```cpp
tdata_in = 1.0f;
tgrad_in = 6.0f;

will cause pre layer1's values be all 6s. this is what I want.

I see what you mean, you cannot assume mutating the input of in_data will change the state of previous layer. Each operator should act in an independent way, by only mutating the outputs(out_data in forward and in_grad in backward).
Otherwise the behavior is undefined. Because the memory allocation algorithm will take advantage of such restriction and re-uses some of the memory

how do you explain this situation?
the tdata_in really acts like a mask of tgrad_in of this layer and out_grad of pre-layer.

this is unreasonable.

The restriction is you can only change in_grad in backward and out_data in forward, the operator will need to obey this restriction. Because the gradient is all the previous operator need to backprop the gradient to input(maybe together with some context like in_data, out_data)

my second proof:
    tdata_in = 0.0f;
    tdata_in[0][0][0][0] = 1.f;
    tgrad_in = 6.0f;

then in the out_grad of pre-layer, only the first value of it is 6, others are 0s.

I don't think the in_data has any relationship with in_grad also, but the experiment data shows not.

backwarddependency:
  std::vector<int> DeclareBackwardDependency(
    const std::vector<int> &out_grad,
    const std::vector<int> &in_data,
    const std::vector<int> &out_data) const override {
    return {//out_data[anchor_regcost_enum::kOut],
            in_data[anchor_regcost_enum::kData],
            in_data[anchor_regcost_enum::kLabel],
            in_data[anchor_regcost_enum::kCoordLabel],
            in_data[anchor_regcost_enum::kBBsLabel],
            in_data[anchor_regcost_enum::kAnchorInfoLabel],
            };
  };

You cannot change content of in_data in Backward Function.

just experiment, I want know what's wrong between the in_grad and out_grad.

I will do more experiments to find the reason.
Do you have any other better suggestion?

Good luck on finding the cause. But please do not assume you can change content of in_data in backward

OK, I will not do it.

Solved , It's my problem.:smile:


100 results from google search

Hello,
First thank you for this nice software :-).
I think i have found two issues. The first one is that i don't get 100 results from google search.
I have set following config options:
config.set('num_pages_for_keyword', 1)
config.set('num_results_per_page', 100)
But i get 10 results back instead of 100.
Is this a known issue or do i miss something....
I will post the other issue i have found in another post.
kind regards,
Toby.

@tobyhage Try this workaround:
config.set('google_search_url', 'https://www.google.com.br/search?num=100')

Thank you, this is working :-)

@bernardosrulzon thx for sharing. i try to find some time to work on this project again.

starting in 0.10.3 you can also just use the config key 'num_results_per_page'
config.set('num_results_per_page', 100)