Provisioning in SKR dev fails on cluster-essentials and istio-configuration installation

Description
Both cluster-essentials and istio-configuration components fail to install. However, they look fine on further inspection.
Expected result
Cluster provisioning succeeds.
Actual result
Cluster provisioning fails.
Steps to reproduce
Provision a cluster on SKR dev.
Troubleshooting
Istio reconciler log:
{"level":"DEBUG","time":"2021-11-25T17:10:21.339Z","message":"Start processing reconciliation request: %sPOST /v1/run HTTP/1.1\r\nHost: istio-configuration-reconciler:8080\r\nAccept-Encoding: gzip\r\nContent-Length: 3476\r\nContent-Type: application/json\r\nUser-Agent: Go-http-client/1.1\r\nX-B3-Parentspanid: e197480bb29e515e\r\nX-B3-Sampled: 0\r\nX-B3-Spanid: 55ec309440e30526\r\nX-B3-Traceid: 8244e0b5ce0ddd1ae197480bb29e515e\r\nX-Envoy-Attempt-Count: 1\r\nX-Forwarded-Client-Cert: By=spiffe://cluster.local/ns/kcp-system/sa/component-reconcilers-istio-configuration;Hash=50d631c0d4a7d9be134f0b9d72796efce4e0522b4e5893e438089b927829b560;Subject=\"\";URI=spiffe://cluster.local/ns/kcp-system/sa/mothership-reconciler\r\nX-Forwarded-Proto: http\r\nX-Request-Id: f6236b3e-7c94-4d20-9b02-b311a05349c6\r\n\r\n{\"componentsReady\":[\"CRDs\"],\"component\":\"istio-configuration\",\"namespace\":\"istio-system\",\"version\":\"2.0.0-rc7\",\"url\":\"\",\"profile\":\"Production\",\"configuration\":{\"components.pilot.k8s.strategy.rollingUpdate.maxSurge\":\"50%\",\"components.pilot.k8s.strategy.rollingUpdate.maxUnavailable\":\"0\",\"global.domainName\":\"c-4cb2c0d.kyma-dev.shoot.canary.k8s-hana.ondemand.com\",\"global.priorityClassName\":\"kyma-system\",\"global.tracing.enabled\":false,\"helmValues.global.proxy.resources.limits.cpu\":\"1000m\",\"helmValues.global.proxy.resources.limits.memory\":\"1024Mi\",\"helmValues.global.proxy.resources.requests.cpu\":\"100m\",\"helmValues.global.proxy.resources.requests.memory\":\"192Mi\"},\"kubeconfig\":\"apiVersion: v1\\nclusters:\\n- cluster:\\n    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM5akNDQWQ2Z0F3SUJBZ0lRR2Fod0tHRmJ5MllJN1B5VllrbmQ4REFOQmdrcWhraUc5dzBCQVFzRkFEQVYKTVJNd0VRWURWUVFERXdwcmRXSmxjbTVsZEdWek1CNFhEVEl4TVRFeU5URTNNREkwTjFvWERUTXhNVEV5TlRFMwpNREkwTjFvd0ZURVRNQkVHQTFVRUF4TUthM1ZpWlhKdVpYUmxjekNDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFECmdnRVBBRENDQVFvQ2dnRUJBTk5peFZBaitVNzhnK2o5aS96blAyekxrSmJob3E2OW5mUURCcEtVU3M2cDBUeVkKamZUQ2Vhcmk0WWwza3ZXUDlPT0JkYkV2amkyeDh5eFc2bENCVW4wejRFTFMwNzFncmZJbUFXVm51cDdIQ2pJTgpGMmlkMjM1d0JCMkdRZm1KWXluOXdQbnRXTzVuck80dkF0elRjd3R2anBlY3phNVUzTkxaUVNSd09hMkJyZ1NYCmFEbVVNMDIyQVR4YzRQTGkrcUhkU1ZFWEZmU0xxRTNIYnBJMGpXdVcra0w5L2Q1UjJZaHk2ZXFvdldUYUx6bXYKeDl5WVBGMjJnZEVoL0JmNkNscEZ2OEZqU3FLRVU1WEJXZHY2cG1ZbVRrY0tWc2ZqUkRoajFLazlrOW5IZDFxRQpqOWFrRi80Q3FvR3hZaUZmdXkvVFRDZUFzc1ZtZisyb2tKSlJlUzBDQXdFQUFhTkNNRUF3RGdZRFZSMFBBUUgvCkJBUURBZ0dtTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3SFFZRFZSME9CQllFRk8xekc0SUdXUUhrejZvanV6ZW4KL05hQnQ3TUNNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUJqemlvYU5MQkMybUxqeVNnSy9GdGkvSmV0Q3p6TQphL3FIM01OTmFiOEliaE40WklEdlRGUUFPUklWcHYwTVlLS3cxMHoxbmFLV2gxcFN5ODcwY3VPMlRjelRZOFdPCnN0SThiRzdRQks0MXVzTDdpNGZ1Sy9ldTNrNFBjSi9uRzhGV3lvTmdzbGt0Vlp5Q0FNU3MvcWxGQm9ZOHJLbDkKQkhOMFFzRW9KTE5ZbTNDZGtQYThPQUQ5anhRWnV3M0VQUm9HemlXUklETjFWd1d6QWt5dXFQTE0xV1ZSYnJTQgpNM0NZek0wTEpsTnJMcGVKWlFSVVY5WHlDVGdENTVjSXNMci9CdTdjYlluOHpMeGZ2SVUxcXRCVFF5ZWl6cTNQCmFrZWJYMlg2dUw1d0dZbUZTMkROSVc5RE4wNlJvY0ZLV2V3M1kxaTA1Ukh4SkM5Snpsc0UxcENhCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K\\n    server: https://api.c-4cb2c0d.kyma-dev.shoot.canary.k8s-hana.ondemand.com\\n  name: shoot--kyma-dev--c-4cb2c0d\\ncontexts:\\n- context:\\n    cluster: shoot--kyma-dev--c-4cb2c0d\\n    user: shoot--kyma-dev--c-4cb2c0d-token\\n  name: shoot--kyma-dev--c-4cb2c0d\\ncurrent-context: shoot--kyma-dev--c-4cb2c0d\\nkind: Config\\npreferences: {}\\nusers:\\n- name: shoot--kyma-dev--c-4cb2c0d-token\\n  user:\\n    token: wV0NHEVwl3PIz1GfzPcqxmEB6J54tHdzdnorbkx6wNp1SdsoQn6xOYvnFLFNbwCt9U77wgNXu2n6h0ontNH0Oll4F00ZRNrSFg4ZUAhqZkdEknNPe9nOoxaVRzZgzmNI\\n\",\"metadata\":{\"globalAccountID\":\"2358e708-68f0-4af0-94b6-cf4e8407aff8\",\"instanceID\":\"06E17AA7-2E66-4BFF-90FA-250ACA4BBC1D\",\"region\":\"eu-central-1\",\"serviceID\":\"47c9dcbf-ff30-448e-ab36-d3bad66ba281\",\"servicePlanID\":\"5cb3d976-b85c-42ea-a636-79cadda109a9\",\"servicePlanName\":\"preview\",\"shootName\":\"c-4cb2c0d\",\"subAccountID\":\"5d89047f-edd9-4082-91c1-47b08f70f15d\"},\"callbackURL\":\"http://kcp-mothership-reconciler:80/v1/operations/ff4078b3-2413-417e-baa7-287dad4c2af1--b3b9b06b-98cc-4f3a-ac26-300b9742f8c6/callback/ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c\",\"correlationID\":\"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c\",\"repository\":{\"url\":\"\",\"tokenNamespace\":\"\"},\"type\":\"reconcile\"}"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.340Z","message":"Reconciliation model unmarshalled: Reconciliation [Component:istio-configuration,Version:2.0.0-rc7,Namespace:istio-system,Profile:Production,Type:reconcile]"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.340Z","message":"Assigning reconciliation worker to model 'Reconciliation [Component:istio-configuration,Version:2.0.0-rc7,Namespace:istio-system,Profile:Production,Type:reconcile]'"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.340Z","message":"Runner for model 'Reconciliation [Component:istio-configuration,Version:2.0.0-rc7,Namespace:istio-system,Profile:Production,Type:reconcile]' is assigned to worker"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.340Z","message":"Creating new runner closure with execution timeout of 600.0 secs"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.341Z","message":"Workspace '/tmp/reconciler/2.0.0-rc7' already exists"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.371Z","message":"Remote callback handler is dumping HTTP response dump: HTTP/1.1 200 OK\r\nContent-Length: 0\r\nDate: Thu, 25 Nov 2021 17:10:21 GMT\r\nServer: envoy\r\nX-Envoy-Upstream-Service-Time: 9\r\n\r\n","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.606Z","message":"Workspace '/tmp/reconciler/2.0.0-rc7' already exists"}
{"level":"INFO","time":"2021-11-25T17:10:21.608Z","message":"Detected: istioctl version 1.11.4, target Istio version: 1.11.4","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:10:21.608Z","message":"No Istio version was detected on the cluster, performing installation...","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:10:21.624Z","message":"Starting Istio installation...","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:10:22.611Z","message":"","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:10:24.678Z","message":"- Processing resources for Istio core.","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:10:24.708Z","message":"✔ Istio core installed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:15:26.027Z","message":"- Processing resources for Istiod.","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:15:26.027Z","message":"✘ Istiod encountered an error: failed to wait for resource: resources not ready after 5m0s: timed out waiting for the condition","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:15:26.047Z","message":"","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:20:26.260Z","message":"- Processing resources for Ingress gateways.","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:20:26.260Z","message":"✘ Ingress gateways encountered an error: failed to wait for resource: resources not ready after 5m0s: timed out waiting for the condition","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:20:26.261Z","message":"","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:20:27.981Z","message":"- Pruning removed resourcesError: failed to install manifests: errors occurred during operation","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"DEBUG","time":"2021-11-25T17:20:27.987Z","message":"Runner: Reconcile action of 'istio-configuration' with version '2.0.0-rc7' failed: Could not install Istio: Error occurred when calling istioctl: exit status 1","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"WARN","time":"2021-11-25T17:20:27.987Z","message":"Runner: failing reconciliation of 'istio-configuration' in version '2.0.0-rc7' with profile 'Production': Could not install Istio: Error occurred when calling istioctl: exit status 1","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"INFO","time":"2021-11-25T17:20:27.987Z","message":"Runner: reconciliation of component 'istio-configuration' for version '2.0.0-rc7' terminated because context was closed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--f44b958b-1b95-477a-8616-59df9d1b043c","component-name":"istio-configuration"}
{"level":"WARN","time":"2021-11-25T17:20:27.987Z","message":"Runner failed for model 'Reconciliation [Component:istio-configuration,Version:2.0.0-rc7,Namespace:istio-system,Profile:Production,Type:reconcile]': context deadline exceeded"}

Cluster-essentials reconciler log:
{"level":"DEBUG","time":"2021-11-25T17:10:21.344Z","message":"Start processing reconciliation request: %sPOST /v1/run HTTP/1.1\r\nHost: cluster-essentials-reconciler:8080\r\nAccept-Encoding: gzip\r\nContent-Length: 3184\r\nContent-Type: application/json\r\nUser-Agent: Go-http-client/1.1\r\nX-B3-Parentspanid: f65bfb10274f5627\r\nX-B3-Sampled: 1\r\nX-B3-Spanid: 63aa973f1c2cff26\r\nX-B3-Traceid: 8140c59a5306d5d4f65bfb10274f5627\r\nX-Envoy-Attempt-Count: 1\r\nX-Forwarded-Client-Cert: By=spiffe://cluster.local/ns/kcp-system/sa/component-reconcilers-cluster-essentials;Hash=50d631c0d4a7d9be134f0b9d72796efce4e0522b4e5893e438089b927829b560;Subject=\"\";URI=spiffe://cluster.local/ns/kcp-system/sa/mothership-reconciler\r\nX-Forwarded-Proto: http\r\nX-Request-Id: b48a6bdd-491d-9f21-a8b3-5c78d51986cd\r\n\r\n{\"componentsReady\":[\"CRDs\"],\"component\":\"cluster-essentials\",\"namespace\":\"kyma-system\",\"version\":\"2.0.0-rc7\",\"url\":\"\",\"profile\":\"Production\",\"configuration\":{\"global.domainName\":\"c-4cb2c0d.kyma-dev.shoot.canary.k8s-hana.ondemand.com\",\"global.priorityClassName\":\"kyma-system\",\"global.tracing.enabled\":false,\"limitRange.default.memory\":\"256Mi\",\"limitRange.max.memory\":\"8Gi\"},\"kubeconfig\":\"apiVersion: v1\\nclusters:\\n- cluster:\\n    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM5akNDQWQ2Z0F3SUJBZ0lRR2Fod0tHRmJ5MllJN1B5VllrbmQ4REFOQmdrcWhraUc5dzBCQVFzRkFEQVYKTVJNd0VRWURWUVFERXdwcmRXSmxjbTVsZEdWek1CNFhEVEl4TVRFeU5URTNNREkwTjFvWERUTXhNVEV5TlRFMwpNREkwTjFvd0ZURVRNQkVHQTFVRUF4TUthM1ZpWlhKdVpYUmxjekNDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFECmdnRVBBRENDQVFvQ2dnRUJBTk5peFZBaitVNzhnK2o5aS96blAyekxrSmJob3E2OW5mUURCcEtVU3M2cDBUeVkKamZUQ2Vhcmk0WWwza3ZXUDlPT0JkYkV2amkyeDh5eFc2bENCVW4wejRFTFMwNzFncmZJbUFXVm51cDdIQ2pJTgpGMmlkMjM1d0JCMkdRZm1KWXluOXdQbnRXTzVuck80dkF0elRjd3R2anBlY3phNVUzTkxaUVNSd09hMkJyZ1NYCmFEbVVNMDIyQVR4YzRQTGkrcUhkU1ZFWEZmU0xxRTNIYnBJMGpXdVcra0w5L2Q1UjJZaHk2ZXFvdldUYUx6bXYKeDl5WVBGMjJnZEVoL0JmNkNscEZ2OEZqU3FLRVU1WEJXZHY2cG1ZbVRrY0tWc2ZqUkRoajFLazlrOW5IZDFxRQpqOWFrRi80Q3FvR3hZaUZmdXkvVFRDZUFzc1ZtZisyb2tKSlJlUzBDQXdFQUFhTkNNRUF3RGdZRFZSMFBBUUgvCkJBUURBZ0dtTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3SFFZRFZSME9CQllFRk8xekc0SUdXUUhrejZvanV6ZW4KL05hQnQ3TUNNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUJqemlvYU5MQkMybUxqeVNnSy9GdGkvSmV0Q3p6TQphL3FIM01OTmFiOEliaE40WklEdlRGUUFPUklWcHYwTVlLS3cxMHoxbmFLV2gxcFN5ODcwY3VPMlRjelRZOFdPCnN0SThiRzdRQks0MXVzTDdpNGZ1Sy9ldTNrNFBjSi9uRzhGV3lvTmdzbGt0Vlp5Q0FNU3MvcWxGQm9ZOHJLbDkKQkhOMFFzRW9KTE5ZbTNDZGtQYThPQUQ5anhRWnV3M0VQUm9HemlXUklETjFWd1d6QWt5dXFQTE0xV1ZSYnJTQgpNM0NZek0wTEpsTnJMcGVKWlFSVVY5WHlDVGdENTVjSXNMci9CdTdjYlluOHpMeGZ2SVUxcXRCVFF5ZWl6cTNQCmFrZWJYMlg2dUw1d0dZbUZTMkROSVc5RE4wNlJvY0ZLV2V3M1kxaTA1Ukh4SkM5Snpsc0UxcENhCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K\\n    server: https://api.c-4cb2c0d.kyma-dev.shoot.canary.k8s-hana.ondemand.com\\n  name: shoot--kyma-dev--c-4cb2c0d\\ncontexts:\\n- context:\\n    cluster: shoot--kyma-dev--c-4cb2c0d\\n    user: shoot--kyma-dev--c-4cb2c0d-token\\n  name: shoot--kyma-dev--c-4cb2c0d\\ncurrent-context: shoot--kyma-dev--c-4cb2c0d\\nkind: Config\\npreferences: {}\\nusers:\\n- name: shoot--kyma-dev--c-4cb2c0d-token\\n  user:\\n    token: wV0NHEVwl3PIz1GfzPcqxmEB6J54tHdzdnorbkx6wNp1SdsoQn6xOYvnFLFNbwCt9U77wgNXu2n6h0ontNH0Oll4F00ZRNrSFg4ZUAhqZkdEknNPe9nOoxaVRzZgzmNI\\n\",\"metadata\":{\"globalAccountID\":\"2358e708-68f0-4af0-94b6-cf4e8407aff8\",\"instanceID\":\"06E17AA7-2E66-4BFF-90FA-250ACA4BBC1D\",\"region\":\"eu-central-1\",\"serviceID\":\"47c9dcbf-ff30-448e-ab36-d3bad66ba281\",\"servicePlanID\":\"5cb3d976-b85c-42ea-a636-79cadda109a9\",\"servicePlanName\":\"preview\",\"shootName\":\"c-4cb2c0d\",\"subAccountID\":\"5d89047f-edd9-4082-91c1-47b08f70f15d\"},\"callbackURL\":\"http://kcp-mothership-reconciler:80/v1/operations/ff4078b3-2413-417e-baa7-287dad4c2af1--b3b9b06b-98cc-4f3a-ac26-300b9742f8c6/callback/ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4\",\"correlationID\":\"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4\",\"repository\":{\"url\":\"\",\"tokenNamespace\":\"\"},\"type\":\"reconcile\"}"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.344Z","message":"Reconciliation model unmarshalled: Reconciliation [Component:cluster-essentials,Version:2.0.0-rc7,Namespace:kyma-system,Profile:Production,Type:reconcile]"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.344Z","message":"Assigning reconciliation worker to model 'Reconciliation [Component:cluster-essentials,Version:2.0.0-rc7,Namespace:kyma-system,Profile:Production,Type:reconcile]'"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.344Z","message":"Runner for model 'Reconciliation [Component:cluster-essentials,Version:2.0.0-rc7,Namespace:kyma-system,Profile:Production,Type:reconcile]' is assigned to worker"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.344Z","message":"Creating new runner closure with execution timeout of 600.0 secs"}
{"level":"INFO","time":"2021-11-25T17:10:21.345Z","message":"Action 'preserve-pod-preset-certificates' executed (passed version was '2.0.0-rc7')","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"ERROR","time":"2021-11-25T17:10:21.451Z","message":"Error while fetching existing mutatingWebhookConfigurations [mutatingwebhookconfigurations.admissionregistration.k8s.io \"cluster-essentials-pod-preset-webhook\" not found]... Certificates will be re-generated","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"ERROR","time":"2021-11-25T17:10:21.464Z","message":"Error while fetching secret [secrets \"cluster-essentials-pod-preset-webhook-cert\" not found]... Certificate will be re-generated","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.464Z","message":"Workspace '/tmp/reconciler/2.0.0-rc7' already exists"}
{"level":"DEBUG","time":"2021-11-25T17:10:21.985Z","message":"Namespace 'kyma-system' is missing: will add namespace resource to the beginning of the manifest","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.280Z","message":"Kubernetes resource 'KubernetesResource [Kind:Namespace,Namespace:,Name:kyma-system]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.364Z","message":"Kubernetes resource 'KubernetesResource [Kind:LimitRange,Namespace:kyma-system,Name:kyma-default]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.390Z","message":"Kubernetes resource 'KubernetesResource [Kind:PodSecurityPolicy,Namespace:,Name:002-kyma-privileged]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.416Z","message":"Kubernetes resource 'KubernetesResource [Kind:PodSecurityPolicy,Namespace:,Name:001-kyma-unprivileged]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.454Z","message":"Kubernetes resource 'KubernetesResource [Kind:ServiceAccount,Namespace:kyma-system,Name:cluster-essentials-pod-preset-webhook]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.493Z","message":"Kubernetes resource 'KubernetesResource [Kind:Secret,Namespace:kyma-system,Name:cluster-essentials-pod-preset-webhook-cert]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.534Z","message":"Kubernetes resource 'KubernetesResource [Kind:Secret,Namespace:kyma-system,Name:ingress-tls-cert]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.560Z","message":"Kubernetes resource 'KubernetesResource [Kind:ClusterRole,Namespace:,Name:cluster-essentials-pod-preset-webhook]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.586Z","message":"Kubernetes resource 'KubernetesResource [Kind:ClusterRole,Namespace:,Name:kyma:psp:privileged]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.613Z","message":"Kubernetes resource 'KubernetesResource [Kind:ClusterRole,Namespace:,Name:kyma:psp:unprivileged]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.651Z","message":"Kubernetes resource 'KubernetesResource [Kind:ClusterRoleBinding,Namespace:,Name:cluster-essentials-pod-preset-webhook]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.677Z","message":"Kubernetes resource 'KubernetesResource [Kind:ClusterRoleBinding,Namespace:,Name:kyma:all:psp:unprivileged]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:22.760Z","message":"Kubernetes resource 'KubernetesResource [Kind:Service,Namespace:kyma-system,Name:cluster-essentials-pod-preset-webhook]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:23.154Z","message":"Kubernetes resource 'KubernetesResource [Kind:Deployment,Namespace:kyma-system,Name:cluster-essentials-pod-preset-webhook]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"WARN","time":"2021-11-25T17:10:23.251Z","message":"admissionregistration.k8s.io/v1beta1 MutatingWebhookConfiguration is deprecated in v1.16+, unavailable in v1.22+; use admissionregistration.k8s.io/v1 MutatingWebhookConfiguration","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"WARN","time":"2021-11-25T17:10:23.350Z","message":"admissionregistration.k8s.io/v1beta1 MutatingWebhookConfiguration is deprecated in v1.16+, unavailable in v1.22+; use admissionregistration.k8s.io/v1 MutatingWebhookConfiguration","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:23.350Z","message":"Kubernetes resource 'KubernetesResource [Kind:MutatingWebhookConfiguration,Namespace:kyma-system,Name:cluster-essentials-pod-preset-webhook]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:23.378Z","message":"Kubernetes resource 'KubernetesResource [Kind:PriorityClass,Namespace:,Name:kyma-system]' successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:23.378Z","message":"Manifest processed: 16 Kubernetes resources were successfully deployed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:23.465Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:38.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:10:53.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:11:08.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:11:23.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:11:38.494Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:11:53.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:12:08.493Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:12:23.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:12:38.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:12:53.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:13:08.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:13:23.493Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:13:38.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:13:53.493Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:14:08.493Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:14:23.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:14:38.495Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:14:53.493Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:15:08.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:15:23.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:15:38.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:15:53.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:16:08.493Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:16:23.493Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:16:38.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:16:53.493Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:17:08.493Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:17:23.491Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:17:38.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:17:53.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:18:08.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:18:23.494Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:18:38.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:18:53.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:19:08.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:19:23.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:19:38.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:19:53.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:20:08.492Z","message":"Transition of cluster-essentials-pod-preset-webhook to ready state is still ongoing","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:20:21.345Z","message":"Stop checking progress of resource transition to state 'ready' because parent context got closed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"WARN","time":"2021-11-25T17:20:21.345Z","message":"Failed to deploy manifests on target cluster: Running resource transition to state 'ready' was not completed: transition is treated as failed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"DEBUG","time":"2021-11-25T17:20:21.345Z","message":"Runner: Reconcile action of 'cluster-essentials' with version '2.0.0-rc7' failed: Running resource transition to state 'ready' was not completed: transition is treated as failed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"WARN","time":"2021-11-25T17:20:21.345Z","message":"Runner: failing reconciliation of 'cluster-essentials' in version '2.0.0-rc7' with profile 'Production': Running resource transition to state 'ready' was not completed: transition is treated as failed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"INFO","time":"2021-11-25T17:20:21.345Z","message":"Runner: reconciliation of component 'cluster-essentials' for version '2.0.0-rc7' terminated because context was closed","correlation-id":"ff4078b3-2413-417e-baa7-287dad4c2af1--7a830e62-7a77-4e01-92da-999188a9e7b4","component-name":"cluster-essentials"}
{"level":"WARN","time":"2021-11-25T17:20:21.345Z","message":"Runner failed for model 'Reconciliation [Component:cluster-essentials,Version:2.0.0-rc7,Namespace:kyma-system,Profile:Production,Type:reconcile]': context deadline exceeded"}

And the kubernetes events list:
FirstSeen              LastSeen               Count    From                        Type      Reason                         Message
2021-11-25T17:24:16Z   2021-11-25T17:24:16Z   1        node-controller             Normal    RegisteredNode                 Node ip-10-250-21-104.eu-central-1.compute.internal event: Registered Node ip-10-250-21-104.eu-central-1.compute.internal in Controller
2021-11-25T17:24:16Z   2021-11-25T17:24:16Z   1        node-controller             Normal    RegisteredNode                 Node ip-10-250-4-39.eu-central-1.compute.internal event: Registered Node ip-10-250-4-39.eu-central-1.compute.internal in Controller
<nil>                  <nil>                  <none>   <none>                      Normal    Scheduled                      Successfully assigned istio-system/istio-ingressgateway-694c5f88bf-ssxjl to ip-10-250-4-39.eu-central-1.compute.internal
2021-11-25T17:24:17Z   2021-11-25T17:24:21Z   4        kubelet                     Warning   FailedMount                    MountVolume.SetUp failed for volume "istiod-ca-cert" : configmap "istio-ca-root-cert" not found
2021-11-25T17:24:25Z   2021-11-25T17:24:25Z   1        kubelet                     Normal    Pulling                        Pulling image "eu.gcr.io/kyma-project/external/istio/proxyv2:1.11.4-distroless"
2021-11-25T17:24:29Z   2021-11-25T17:24:29Z   1        kubelet                     Normal    Pulled                         Successfully pulled image "eu.gcr.io/kyma-project/external/istio/proxyv2:1.11.4-distroless" in 3.733086951s
2021-11-25T17:24:29Z   2021-11-25T17:24:29Z   1        kubelet                     Normal    Created                        Created container istio-proxy
2021-11-25T17:24:29Z   2021-11-25T17:24:29Z   1        kubelet                     Normal    Started                        Started container istio-proxy
2021-11-25T17:24:17Z   2021-11-25T17:24:17Z   1        replicaset-controller       Normal    SuccessfulCreate               Created pod: istio-ingressgateway-694c5f88bf-ssxjl
2021-11-25T17:24:17Z   2021-11-25T17:24:17Z   2        controllermanager           Normal    NoPods                         No matching pods found
2021-11-25T17:24:17Z   2021-11-25T17:24:17Z   1        deployment-controller       Normal    ScalingReplicaSet              Scaled up replica set istio-ingressgateway-694c5f88bf to 1
2021-11-25T17:24:48Z   2021-11-25T17:24:48Z   1        horizontal-pod-autoscaler   Warning   FailedGetResourceMetric        failed to get memory utilization: unable to get metrics for resource memory: no metrics returned from resource metrics API
2021-11-25T17:24:48Z   2021-11-25T17:24:48Z   1        horizontal-pod-autoscaler   Warning   FailedGetResourceMetric        failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API
2021-11-25T17:24:48Z   2021-11-25T17:24:48Z   1        horizontal-pod-autoscaler   Warning   FailedComputeMetricsReplicas   invalid metrics (2 invalid out of 2), first error is: failed to get memory utilization: unable to get metrics for resource memory: no metrics returned from resource metrics API
2021-11-25T17:25:18Z   2021-11-25T17:25:48Z   2        horizontal-pod-autoscaler   Warning   FailedGetResourceMetric        failed to get cpu utilization: did not receive metrics for any ready pods
<nil>                  <nil>                  <none>   <none>                      Normal    Scheduled                      Successfully assigned istio-system/istiod-9cf9cbf8-v4tg2 to ip-10-250-21-104.eu-central-1.compute.internal
2021-11-25T17:24:18Z   2021-11-25T17:24:18Z   1        kubelet                     Normal    Pulling                        Pulling image "eu.gcr.io/kyma-project/external/istio/pilot:1.11.4-distroless"
2021-11-25T17:24:20Z   2021-11-25T17:24:20Z   1        kubelet                     Normal    Pulled                         Successfully pulled image "eu.gcr.io/kyma-project/external/istio/pilot:1.11.4-distroless" in 2.280392425s
2021-11-25T17:24:20Z   2021-11-25T17:24:20Z   1        kubelet                     Normal    Created                        Created container discovery
2021-11-25T17:24:20Z   2021-11-25T17:24:20Z   1        kubelet                     Normal    Started                        Started container discovery
2021-11-25T17:24:17Z   2021-11-25T17:24:17Z   1        replicaset-controller       Normal    SuccessfulCreate               Created pod: istiod-9cf9cbf8-v4tg2
2021-11-25T17:24:16Z   2021-11-25T17:24:17Z   2        controllermanager           Normal    NoPods                         No matching pods found
2021-11-25T17:24:17Z   2021-11-25T17:24:17Z   1        deployment-controller       Normal    ScalingReplicaSet              Scaled up replica set istiod-9cf9cbf8 to 1
2021-11-25T17:24:48Z   2021-11-25T17:24:48Z   1        horizontal-pod-autoscaler   Warning   FailedGetResourceMetric        failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API
2021-11-25T17:24:48Z   2021-11-25T17:24:48Z   1        horizontal-pod-autoscaler   Warning   FailedComputeMetricsReplicas   invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API
2021-11-25T17:25:18Z   2021-11-25T17:25:48Z   2        horizontal-pod-autoscaler   Warning   FailedGetResourceMetric        failed to get cpu utilization: did not receive metrics for any ready pods
2021-11-25T17:25:18Z   2021-11-25T17:25:48Z   2        horizontal-pod-autoscaler   Warning   FailedComputeMetricsReplicas   invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: did not receive metrics for any ready pods
2021-11-25T17:24:02Z   2021-11-25T17:24:02Z   1        kube-controller-manager     Normal    LeaderElection                 kube-controller-manager-5b99d7cb47-2kzzd_df23ea20-0ebe-4ddf-8a69-3939a259545f became leader
<nil>                  <nil>                  <none>   <none>                      Normal    Scheduled                      Successfully assigned kube-system/node-problem-detector-8shlv to ip-10-250-21-104.eu-central-1.compute.internal
2021-11-25T17:24:28Z   2021-11-25T17:24:28Z   1        kubelet                     Normal    Pulled                         Container image "eu.gcr.io/sap-se-gcr-k8s-public/k8s_gcr_io/node-problem-detector/node-problem-detector@sha256:cb0b40d206abff75f906a5d87e8a6a019be0aedc64df5baa6aed6cf1b564073c" already present on machine
2021-11-25T17:24:28Z   2021-11-25T17:24:28Z   1        kubelet                     Normal    Created                        Created container node-problem-detector
2021-11-25T17:24:28Z   2021-11-25T17:24:28Z   1        kubelet                     Normal    Started                        Started container node-problem-detector
<nil>                  <nil>                  <none>   <none>                      Normal    Scheduled                      Successfully assigned kube-system/node-problem-detector-bwb7z to ip-10-250-4-39.eu-central-1.compute.internal
2021-11-25T17:24:28Z   2021-11-25T17:24:28Z   1        kubelet                     Normal    Pulled                         Container image "eu.gcr.io/sap-se-gcr-k8s-public/k8s_gcr_io/node-problem-detector/node-problem-detector@sha256:cb0b40d206abff75f906a5d87e8a6a019be0aedc64df5baa6aed6cf1b564073c" already present on machine
2021-11-25T17:24:28Z   2021-11-25T17:24:28Z   1        kubelet                     Normal    Created                        Created container node-problem-detector
2021-11-25T17:24:29Z   2021-11-25T17:24:29Z   1        kubelet                     Normal    Started                        Started container node-problem-detector
2021-11-25T17:24:17Z   2021-11-25T17:24:22Z   11       daemonset-controller        Warning   FailedCreate                   Error creating: Internal error occurred: failed calling webhook "auto.sidecar-injector.istio.io": Post "https://istiod.istio-system.svc:443/inject?timeout=10s": no endpoints available for service "istiod"
2021-11-25T17:24:27Z   2021-11-25T17:24:27Z   1        daemonset-controller        Normal    SuccessfulCreate               Created pod: node-problem-detector-bwb7z
2021-11-25T17:24:27Z   2021-11-25T17:24:27Z   1        daemonset-controller        Normal    SuccessfulCreate               Created pod: node-problem-detector-8shlv
<nil>                  <nil>                  <none>   <none>                      Normal    Scheduled                      Successfully assigned kyma-system/cluster-essentials-pod-preset-webhook-6fffbb9dbd-ck6p5 to ip-10-250-4-39.eu-central-1.compute.internal
2021-11-25T17:24:28Z   2021-11-25T17:24:28Z   1        kubelet                     Normal    Pulling                        Pulling image "eu.gcr.io/kyma-project/incubator/podpreset-webhook:021a99c6"
2021-11-25T17:24:30Z   2021-11-25T17:24:30Z   1        kubelet                     Normal    Pulled                         Successfully pulled image "eu.gcr.io/kyma-project/incubator/podpreset-webhook:021a99c6" in 2.0356194s
2021-11-25T17:24:30Z   2021-11-25T17:24:30Z   1        kubelet                     Normal    Created                        Created container pod-preset-webhook
2021-11-25T17:24:31Z   2021-11-25T17:24:31Z   1        kubelet                     Normal    Started                        Started container pod-preset-webhook
2021-11-25T17:24:17Z   2021-11-25T17:24:22Z   11       replicaset-controller       Warning   FailedCreate                   Error creating: Internal error occurred: failed calling webhook "auto.sidecar-injector.istio.io": Post "https://istiod.istio-system.svc:443/inject?timeout=10s": no endpoints available for service "istiod"
2021-11-25T17:24:27Z   2021-11-25T17:24:27Z   1        replicaset-controller       Normal    SuccessfulCreate               Created pod: cluster-essentials-pod-preset-webhook-6fffbb9dbd-ck6p5
2021-11-25T17:24:17Z   2021-11-25T17:24:17Z   1        deployment-controller       Normal    ScalingReplicaSet              Scaled up replica set cluster-essentials-pod-preset-webhook-6fffbb9dbd to 1

Cannot reproduce.


[SPARK-39294][SQL] Support non-vectorized Orc scans with DEFAULT values

What changes were proposed in this pull request?
Support non-vectorized Orc scans when the table schema has associated DEFAULT column values.
(Note: this depends on https://github.com/apache/spark/pull/36672.)
Example:
create table t(i int) using orc;
insert into t values(42);
alter table t add column s string default concat('abc', def');
select * from t;
> 42, 'abcdef'

Why are the changes needed?
This change makes it easier to build, query, and maintain tables backed by Orc data.
Does this PR introduce any user-facing change?
Yes.
How was this patch tested?
This PR includes new test coverage.

@gengliangwang and/or @HyukjinKwon this is DEFAULT column support for the non-vectorized Orc reader, it depends on https://github.com/apache/spark/pull/36672 which adds the Parquet support.

I think I can rewrite this PR so it doesn't have any dependencies. Let me close this and open a new one


Use Start-Process for Get-BcContainerEventLog

The previous call "[Diagnostics.Process]::Start($eventLogName)"  could not open evtx files correctly inside PowerShell 7.
Fixes #3248

Thanks


bottomless: add zstd compression option

Transplanted from https://github.com/libsql/sqld/pull/780

xz compression emprically showed ~20-25x better compression ratio than gzip. In my tests xz proved to actually be faster too, because instead of having to write ~200MiB to disk as gzip would, it wrote ~10MiB, at the cost of more cpu used. We should test first, but then strongly consider making xz default.
To set it up, it's enough to set
LIBSQL_BOTTOMLESS_COMPRESSION=xz

as an env var

@MarinPostma downgraded to draft, because I see some spontaneous errors when testing xz compression on large random data (one that does not compress well). I'll evalutate other compression implementations as well, because xz support looks a little abandoned in the async_compression crate

Rebranded to zstd. It's a modern one that also powers ScyllaDB, and it first and foremost passed all correctness tests on which xz and bzip2 failed. It's also way faster than any of the other ones, while still providing compression ratios of 12-15 where gzip gives mere 2.


Create an Agenda Item entity

Fields need to be:
id (int)
event (Event)
speakers ([Speaker] - see #22)
title (string)
description (text)
start (date)
end (date)
hidden (boolean)
break (boolean)

End is a reserved word - used 'finish'

Resolved in #25


feat: added config support

:tada: This PR is included in version 1.2.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[WIP] Some warnings fix

Following the amazing @akien-mga input in compiling with warnings enabled, I tried to give a small contribution to making this happen.
I'll write comments on each part. Some things I'm pretty confident about, some less.
Should be squashed when agreed upon.

@akien-mga I think this is good now. Any thoughts?


Disambiguate source_len / target_len

Current TPU attention implementation use ambiguous naming source_len and target_len for query and kv lengths, but we typically follow the convention in which query length is target_len and vice versa. We rename them to q_seq_len and kv_seq_len to disambiguate.

Thanks, I think I've addressed this in https://github.pie.apple.com/foundation-models/axlearn/pull/847/files#diff-22479d8930dc7b23057c6517b633f9c03c00e805e1099f9c6f30fd9da2109f05
(Swapping source_len and target_len so they match the convention used elsewhere in the project.)
If we want to rename everything to q_seq_len and kv_seq_len, it might make sense to do that project-wide as a followup pr.

(Personally I do think the names q_seq_len and kv_seq_len make more sense longer term if we can do it project-wide.)


Import map in workspace folder needs to be renamed importMap.json

Running the dev task results in a the following error indicating that the workspace importmap.json file needs to be renamed to importMap.json:
craig@craig-G750JX:~/git/deno/ultra_fork/workspace$ deno task dev
Warning deno task is unstable and may drastically change in the future
error: Unable to load 'file:///home/craig/git/deno/ultra_fork/workspace/importMap.json' import map

Caused by:
    No such file or directory (os error 2)

The .vscode/settings.json file has a deno.importMap setting pointing to the same workspace/importMap.json file.

I will put together a PR fixing this issue,


cache TRSS JSON data (Smart Parallelization approach 3)

Smart Parallelization approach 3 - cache TRSS JSON data on Jenkins

Create Jenkins job to query TRSS using getTestAvgDuration API  and store the response into a file.

In order to avoid version, impl, platform, level and group combination explosion, we will skip level  in the query.
For example, the following query will be saved into a file named Test_openjdk11_hs_system_s390x_linux. We will use the same naming conversion as test jobs and skip level.
https://trss.adoptopenjdk.net/api/getTestAvgDuration?platform=s390x_linux&group=system&jdkVersion=11&impl=hs&limit=10
This job should be similar to test.getDependency and it can be scheduled to run daily if needed

JenkinsfileBase needs to be updated to copyArtifacts under TKG/resources/TRSS

If files under TKG/resources/TRSS exist, TKG reads these files. Otherwise, TKG queries TRSS server directly.

Related https://github.com/AdoptOpenJDK/openjdk-tests/issues/1563

FYI @ShelleyLambert @renfeiw

https://ci.adoptopenjdk.net/view/all/job/getTRSSOutput/

The archived data in getTRSSOutput job on OpenJ9  is from internal TRSS so that we have more info on functional tests.

All PRs are delivered and Jenkins jobs are configured. Close this issue.


Lsp can only find definitions for the current file

First of all, this plugin is great. I can switch projects and change the environment without exiting nvim, something that I wanted to do for a long time.
Something I noticed while using the plugin is that the "Go to definition" of the LSP only works on the references existing in the file I've activated the virtual environment in. Let's see an example project with the following structure:
venv-test
├── .env
├── main.py
├── my_utilities.py
└── my_module
──── ├── __init__.py
──── └── a.py
The .env folder contains a virtual environment created with python3 -m venv .env just for the purpose of this demonstration. It does not have additional python packages installed.
The contents of the files are the following:
# main.py
from my_utilities import my_func

def main():
   my_func()

# my_utilities.py
from my_module.a import hello

def my_func():
   hello()

# a.py
def hello():
   print("hello")

If I activate the virtual environment in the terminal before opening vim:
source $HOME/venv-test/.env/bin/activate
nvim main.py

I can "Go to definition" to my_func and once there to the definition of hello().
However if I just open vim without the virtual environment:
nvim main.py

And then do a VenvSelect and select the entry with $HOME/venv-test/.env/bin/activate I can go to the definition of my_func but once there, if I "Go to definition" of hello(), the LSP just jumps to the line where hello() is imported, not the a.py file where hello is defined.
If I do the same procedure but open my_utilities.py instead of main.py and  do a "Go to definiton" on hello() it takes me to the function definition correctly so it seems it only breaks the "Go to definition" of the files other than the one I activated venv in.
The LSP (pyright) in both cases shows the same "root" in :LspInfo so I don't know what the VenvSelect is doing that it breaks the "Go to definition". This also happens to me with poetry virtual environments.
My plugin configuration is the following (commit 3e6eac9a883654157fdc11dcb65db48db4194127 (from Aug 23th, 2023):
require('venv-selector').setup({
  name = { "venv", ".env" },
  fd_binary_name = "fdfind"
})

Please, do not hesitate to ask if something is missing or not clear. Thank you!

Ive been trying to replicate what you wrote and things just work for me.
I created exactly the same tree structure as you:
├── main.py
├── my_module
│   ├── a.py
│   └── __init__.py
└── my_utilities.py

And added exactly the same content in the files.
I made sure no virtual environment was activated, and then i did exactly what you did:

Run VenvSelect
Select virtual environment
Go to definition of my_func
Go to definition of hello()  <- This takes me to the right place in a.py.

I recorded a asciinema vid where i slowly do this (it cant render some of my tabs so things look ugly, but you will see what steps i do anyway).
https://asciinema.org/a/VH49Wr83pRLiQcem6PllPavjU
For me, the LspInfo says "root directory: Running in single file mode" and doesnt give a path. This is because I dont have a git repository in this directory so Pyright doesnt recognize it as a root directory. Despite this, it works fine to jump between definitions in multiple opened files.
I also tried to create a empty git repository in the root folder. Then the LspInfo says the venv-test folder is the root directory. And doing steps 1-4 works exactly like before - no difference in behavior and it works as expected.
Im using LazyVim for these tests by the way, default configuration.
If you try this with LazyVim, does it work then? To avoid messing with your current neovim config, you can just create a new neovim profile with APP_NAME=experiment neovim to get a fresh neovim config from scratch. Then install Lazyvim into that one. As long as you prefix things with the APP_NAME environment variable, it wont touch your existing neovim config.
To go back to your existing neovim environment, just unset the APP_NAME variable and launch vim.

@linux-cultist : yeah you are right, lspconfig has a list of root files it uses to find and configure the lsp root server:
https://github.com/neovim/nvim-lspconfig/blob/499314f76fa6e8f82f7cfd116578906d61ba2560/lua/lspconfig/server_configurations/pyright.lua#L3
it is then used in the lsp setup function here:
https://github.com/neovim/nvim-lspconfig/blob/499314f76fa6e8f82f7cfd116578906d61ba2560/lua/lspconfig/server_configurations/pyright.lua#L36C5-L36C13
this results in the following behavior:
for every file you are opening in a buffer it first tries to determine the correct root folder and if  can not find one runes this file in single file mode. so for example if you have two buffers open one with a route folder and one with single or a different root folder. lspinfo would give you different results, depending which is your current active file :)
so this is my quite standard lazyvim configuration behavior, following the lspconfig documentation it should spawn a new server, but mine is reconfigured every time, maybe the documentation is outdated there.
https://github.com/neovim/nvim-lspconfig/blob/499314f76fa6e8f82f7cfd116578906d61ba2560/doc/lspconfig.txt#L71
sorry for my bad English I'm currently in hurry and wanted to note that down quickly.

Ah ok, so this bug doesnt occur on Lazyvim but it occurs on more default configurations of pyright?
You have good english. Im also not a native english speaker. :)

In my case, I setup the lsp through lsp-zero (https://github.com/VonHeikemen/lsp-zero.nvim) with a pretty basic configuration. That might be the reason. I will investigate a bit to see if I can find anything that helps us clarify why this happens and what can we do about it.

Did you find some reason for this? Curious...

Hi, @linux-cultist,  sorry for taking so long to respond. I have not figured out what the root issue was. I just uninstalled lsp-zero and setup the lsp myself and now everything works flawlessly. Sorry for the inconvenience.

Ok very good :)


Update Not used scheduling parameters for planning optimization

Adding scheduling parameters form details for not supported parameters in planning optimization

@kamaybac can you please review this change?

This belongs in the private repo. Closing and deleting this one. New PR is here:
https://github.com/MicrosoftDocs/Dynamics-365-Operations/pull/16758


Move the UI Styleguide to the Help menu

Is your proposal related to a problem?
When the Styleguide is activated, it appears in the Settings menu, which is not ideal as this is not a setting.
Describe the solution you'd like
As the title says, move this entry to the Help menu, which is more logical for it.
Additional context
I'm not sure if this is much of a feature but it seemed the best place to suggest this change.

Not sure about this, the help feature is meant to be user facing for most users. Settings menu is normally going to be restricted somewhat.
The styleguide is meant for developers mainly, it's even been called I to question about whether it should exist at all. However, it's useful for validation and package maintainers.
I would recommend we keep it as is.

I agree with keeping this as is - the use cases for enabling the styleguide on any Wagtail installation are very narrow, and giving it a location that communicates "this is for administrative users only" is more important than making it discoverable.


Error Message Appearing After Treesitter Update

Version confirmation

[X] Confirm

Following prerequisites

[X] Confirm

Not a user config issue

[X] Confirm

Neovim version
NVIM v0.10.0-dev-951+g5d8ab32f3-Homebrew
Operating system/version
macos 14
Terminal name/version
iterm 2
$TERM environment variable
No response
Branch info
main (Default/Latest)
Fetch Preferences
SSH (use_ssh = true)
How to reproduce the issue
such as

Expected behavior
How to Clear These Error Messages
Actual behavior
No response
Additional information
No response

it's fixed, update your config


Itemis University Offering.

https://www.itemis.com/en/yakindu/state-machine/yakindu-universities/
Add to posts as benefits


GalaxyBudsClient: init at 4.5.2

Description of changes
Bringing GalaxyBudsClient to Nixpkgs.
This PR was based on the works of @Madouura in #168082 and "finalized" by myself.
The reason for creating a new PR was because of how long the package had been in a WIP state (~5 months) and therefore I thought it would be better to create a new PR instead of reviving the old one.
To: Madouura
If you still desire to remain the maintainer of this package or added to the maintainer list, please do inform me on this matter and I'll make sure to resolve the issue! (Psst.. thank you for creating the base .nix of this package :upside_down_face: )

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Should we normalize the program name to galaxybudsclient? I guess this is the more common

Should we normalize the program name to galaxybudsclient? I guess this is the more common

From what seems to be the general convention in all-packages.nix, either galaxyBudsClient or galaxy-buds-client.

galaxyBudsClient

This seems more appropriate in my opinion.
Just pushed a change to all-packages with that name.

@ofborg build galaxyBudsClient

I don't remember if this is a nitpick or required, but pname should match the all-packages entry.
Commit message probably should too.

I don't remember if this is a nitpick or required, but pname should match the all-packages entry.
Just re-read the naming guideline and apparently we ought to switch to a lowercase name or a dashed one, which makes the recent camel-case switch redundant..

Lowercase looks way too cramped when compared to dashed naming and therefore I'll use that instead.

The PR should now contain the new dashed name in directory, default.nix and in commit.

Result of nixpkgs-review pr 195991 run on x86_64-linux 1

1 package built:

galaxy-buds-client


ACM-3262 Unable to make SSH connection to a bitbucket repo on a non-standard ssh port

This PR updates the order of the port flag for the ssh-keyscan command. Before this PR ssh-keyscan was defaulting to port 22 even if another port was specified.
Addresses:

https://issues.redhat.com/browse/ACM-3262

/lgtm


Offset and rotation for middle arrow?

I'm using a middle arrow (image type) to show an indicator on an edge. It works great, but it appears slightly off center since the arrows are drawn to center off the top of the arrow, instead of the midpoint of the arrow. You can see this happen in the provided visjs example for a default arrow type, not just images. For my specific usage, here's a screenshot (sorry for the partial screenshot, I can't disclose sensitive information)
My edge config looks something like:
arrows: {
   middle: {
      enabled: true,
      type: 'IMAGE',
      imageHeight: 15,
      imageWidth: 15,
      src: /* image url */
   }
}

endPointOffset exists for from / to arrows, but why not middle? It'd be nice if I could adjust the offset for my use case, and for just some added flexibility with using arrows. I understand I could customize the arrow rendering, but I think having this offset could make sense as an OOTB option!
As a separate suggestion, what would it be like to have a rotation parameter at least for middle arrows, or maybe fix the rotation so that it's always vertically aligned no matter the edge placement? I can easily just rotate my source images, but maybe there could be a case where someone wants their image to be aligned differently than towards the target node.

Any follow-up on the middle arrow alignment? We have the option to simply patch our instance of VisJS to align the middle arrows differently as well, but could use a bit of guidance on where to start there.

Any follow-up on the middle arrow alignment? We have the option to simply patch our instance of VisJS to align the middle arrows differently as well, but could use a bit of guidance on where to start there.

+1 please consider this, I really need this

1 would be great to disable rotation of arrow heads, it's strange to rotate when you use an image :(


[improve][misc] Pin Netty version in pulsar-io/alluxio

Motivation
Upgrade to Netty 4.1.103.Final fails with errors in pulsar-io/alluxio (see comments in #21723). Prepare for the upgrade by pinning the Netty version in pulsar-io/alluxio.
Modifications

Use dependencyManagement to pin versions
Use 4.1.100.Final since it should be compatible

Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

Codecov Report

Merging #21728 (a625f6a) into master (58ae086) will increase coverage by 36.69%.
Report is 2 commits behind head on master.
The diff coverage is 100.00%.

Additional details and impacted files

@@              Coverage Diff              @@
##             master   #21728       +/-   ##
=============================================
+ Coverage     36.67%   73.37%   +36.69%
- Complexity    12255    32753    +20498
=============================================
  Files          1717     1893      +176
  Lines        131212   140761     +9549
  Branches      14342    15509     +1167
=============================================
+ Hits          48123   103284    +55161
+ Misses        76691    29366    -47325
- Partials       6398     8111     +1713

Flag
Coverage Δ

inttests
24.13% <40.00%> (-0.03%)
:arrow_down:

systests
24.69% <40.00%> (+0.02%)
:arrow_up:

unittests
72.64% <100.00%> (+40.84%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files
Coverage Δ

...sar/broker/service/persistent/PersistentTopic.java
78.63% <100.00%> (+26.59%)
:arrow_up:

... and 1462 files with indirect coverage changes


mpd_status_get_state segfaults on null state_.get()

From my last comment at #273:

Update on the mpd_status_get_state segfault: it occurs due to state_.get() occasionally being nullptr. I don't know of a nice way to handle this because my rudimentary modifications (just checking if (state_.get() != nullptr) before get state) would update the module to say "Disconnected", but wouldn't ever refresh state. Just mpd: Connection to MPD closed in the logs.
First thing we probably want to look at is why tryConnect() doesn't connect after this occurs, and the connection_.reset() and alternate_connection_.reset() lines don't help in checkErrors(). I have 0 experience with threaded programs in this regard.
STR (on my system, at least)

Start up the bar
Play music for a second or two
Pause it
Do something for a minute or so (for me, always happens after 1 minute, exactly: mpc pause;sleep 60;mpc play)
Play music again
Observe segfault

N.B. Everywhere else that uses state_.get() has a chance to segfault -- I saw a few in the elapsedTime and totalTime variables, as well as the icons just below that while messing around.
cc: @minijackson @Alexays

So I've had a bit of time to look at it, and it appears that when the connection "times out", the operation to block on events never stops to block :-/
Because it's that thread that tries to reconnect when the connection drops, the module will stay disconnected…
I think three solutions are possible:

Find a way to "unblock" the event listener
Add a timeout to the event listener (will make the module update more frequently but I don't think this is a big deal)
Change everything


TCS stock price prediction using lstm

I would like to Add the ML Models which i am gonna build like using LSTM, SVM and K-Nearest Neighbors (KNN) using historical stock price data and relevant financial indicators, preprocess the data, performing EDA, and check the prices, and compare the model's accuracy.

@invigorzz313 pls assign it to me I'm Gssoc'24 contributor

@Niketkumardheeryan please assign me this issue and the other 2 issues


Kernel CI/CD tests should be merge requirement

Currently the kernel CI/CD tests are optional and don't block merge if they fail.

Thanks to @dthaler for adding this.


Add Azure.Core.TestFramework tests to nightly integration

Azure.Core test framework has some excellent filename encoding tests that gotcha-ed a proxy roll-out a couple weeks ago. Adding those to our nightly integration tests so we can catch it earlier next time!

/azp run tools - test-proxy - tests


Custom Test Metadata/Tags for use in Reporters

Are you requesting a feature or reporting a bug?
Feature Request
What is the current behavior?
TestCafe does not support pipelining custom metadata/tags to a reporter. However, I do see in the previous incarnation there was a form of this: https://testcafe.devexpress.com/Documentation/API_Reference/Test_Fixture_API/Common_Concepts/#Test_Run_Metadata
What is the expected behavior?
Ideally we would like to be able to define metadata/taga in our tests and have it available to the reporters.
Use Cases:

Severity
Test Management Tool ID / URL

Example:
test('My first test', {severity: critical, testID: TC-0013}, async t => {
    // Test code
});

or
test('My first test', async t => {
    t.meta('severity', 'critical')
    t.meta('testID', 'TC-0013')
});

such that the testRunInfo object in reportTestDone would have access
reportTestDone (name, testRunInfo) {
    if (testRunInfo.severity)
        title += ' (testRunInfo.severity)';

    if (testRunInfo.testID)
        title += ` (testRunInfo.testID)`;
}

If you are familiar with RSpec, you will know this concept well. Here is what it looks like: https://relishapp.com/rspec/rspec-core/docs/metadata/user-defined-metadata
However, in RSpec it is much more powerful as tags/metadata can be used to drive whether tests should be run/skipped - and also drive logic within the tests themselves.

@AlexanderMoskovkin - can you confirm my suspicion that TestCafe does not currently support this?
What is the underlying test framework, is it mocha? Wondering if I can put together a PR to add support.

Yep, TestCafe doesn't support it right now. TestCafe uses its own compiler under the hood.
TestCafe doesn't provide an ability to add some custom info from the test to its report. But we have test context and fixture context objects. We can implement sharing info between tests and reports by using them. It may look in the following way:
// test.js
test('Test1', async t => {
     t.fixtureCtx.severity = 'critical';
     t.ctx.testID = 'TC-0013';
});

// custom-report.js
reportTestDone (name, testRunInfo) {
    const severity = testRunInfo.fixtureCtx.severity;
    const testID   = testRunInfo.ctx.testID;

    ...
}

How do you like this way? /CC @tk8817 @DevExpress/testcafe-docs @VasilyStrelyaev

Wondering if I can put together a PR to add support

When we will up with the final API the PR is welcome. We will provide any assistance.

@AlexanderMoskovkin - thanks for pointing out the ctx functionality, I think they are solid  entry-points that your users would already be familiar with. Forwarding those objects to the reporters would solve our use case perfectly.

Hi @AlexanderMoskovkin, I am currently looking on how to inject test/fixture context in the reporter. Would you accept a PR for this kind of job or are you already working/planning on it?

Hi @hdorgeval, Your PR is welcome. Let me know if you need any assistance.

@AlexanderMoskovkin - we missed @hdorgeval's post and took it on ourselves. I have had one of my team members raise PR #2258 which we hope is to your satisfaction.

It doesn't feel right to use ctx for test metadata. It's purpose is just to share variables between tests/fixtures in runtime. We have test/fixture tags proposal somewhere here as far as I remember, seems like it's a good fit for this kind of things.

@inikulin, I’m not sure I understand. What is the purpose for ctx outside of this usecase?
The ‘context’ of a fixture or test is exactly what we are lookinng to expose to the reporter. Interestingly, if you look at our PR - it’s a 2 line code change, as you guys were already capturing this and passing it forward, but simply leaving it out of the final object the reporter receives.

@tk8817 ctx has nothing to do with reporting. The only purpose of this property is to share variables between tests and test hooks: https://devexpress.github.io/testcafe/documentation/test-api/test-code-structure.html#sharing-variables-between-test-hooks-and-test-code. I believe there should be dedicated property for such reporting purposes, otherwise it will be quite confusing.

@inikulin - if you look at the code, this object is where the reporter gets all of its data from, it was literally a one line update to further expose the same object...

if you look at the code, this object is where the reporter gets all of its data from

It's not.

it was literally a one line update to further expose the same object...

It's a doubtful excuse for improper API design choices.

Here is one more use case: https://testcafe-discuss.devexpress.com/t/is-it-possible-to-pass-custom-values-to-custom-report-functions/706?u=amoskovkin It doesn't look like just a tag. Some kind of additional/meta info.
Your proposals?

I don't understand why data from the tests and fixtures are cherry picked and left out from the final testRunInfo. The data is literally dropped at the last step. What even is the rational for leaving out the test and fixture from the reporter? It only limits the capabilities of what a truly custom reporter can do. As for the ctx, that is exactly what we are trying to report on. For massive projects the context of a test run is as important as the outcome in terms of a reporting standpoint.

@AlexanderMoskovkin
t.meta.foo = 'bar';

@MatthewNielsen27 testRunInfo contains ctx property because it contains whole test and lots of other stuff that matters only for testcafe runtime. Please, re-read carefully the link that I've provided above about ctx and it's purpose. It's just wrong from semantical perspective to use this property for reporting meta information. We need a dedicated property for that.

@inikulin I understand that a separate meta field would be the best implementation for that use. But nevertheless I see value in the reporter having access to the shared context data between tests. Besides metadata, this context data would also be valuable to report on. So this PR still has merit as a useful addition from my perspective.

@inikulin , @AlexanderMoskovkin,
I looked at the PR #2258, and I would have done the same job on my side: it is a quick solution but I admit this is a questionable solution.
Questionable because:

pushing the contexts into the reporter may enable the reporter to modify these contexts and therefore this could create side effects. Only immutable or POJO objects should be pushed to the reporter;
on parallel execution, I absolutely do not know how contexts are managed;
there is no guaranty on the ctx life cycle: the ctx object may not exist any more when calling the reporter.

PR #2258 would have been a time saver and would give a true value. I would have use it in order to be able to create a cucumber-like json reporter and then be able to create nice html reports with cucumber-html-reporter (see my repo cucumber-ts-starter).
What is actually missing in TestCafe is the fact that there are only two levels for describing tests: the fixture level and the test level. In a way having only two levels prevent deep and unnecessary nesting.
What is lacking is the possibility to tag a test and the possibility to divide a test into steps.
Why?

Different tests, in different files may cover the same business acceptance scenario.
Not having steps inside a test may lead to have many code duplication and tests with many lines of code.

Using a Page Model may solve this problem on a technical point of view but not on a business point of view.
When the TestCafe code base start to grow, more time is needed to write new test and to maintain existing ones. Some dashboard has to be produced for the business in order to show what is going on and how TestCafe is a great product.
But dashboard is a sort of reporter and current reporter API cannot produce high level report targeted to the business.
I would love to be able to write the following code:
fixture("My Fixture")
    .page("http://myurl")
    .before(async (ctx) => {
        // code omitted for brevity
    })
    .beforeEach(async (t) => {
        await t.report({keyword: "BeforeEach"},/*  pass a POJO object of type IMyReportInfo */);
        // code omitted for brevity
    })

test("My Test", async (t) => {
    await t.report({keyword: "StepStart"},/*  pass a POJO object of type IMyReportInfo */);
    // some test code
    await t.report({keyword: "StepEnd"},/*  pass another POJO object of type IMyReportInfo */)
    // other code
});

//internally the test function should be wrapped by:
// t.report({keyword: "TestStart", name:"My Test"}, /* POJO object like testRunInfo */),
// t.report({keyword: "TestEnd", name:"My Test"})

//internally the fixture should be wrapped by:
// t.report({keyword: "FixtureStart", name:"My Fixture"}, /* POJO object like testRunInfo */),
// t.report({keyword: "FixtureEnd", name:"My Fixture"})

// custom POJO object that will be pushed to the reporter
export interface IMyReportInfo {
    tags: string[];
    keyword: string;
    description: string;
    // any custom information needed by the reporter
}

@inikulin @AlexanderMoskovkin We need a feature like this quickly to support our business and are willing to code it. PR #2258 would cover all of our needs immediately, but we would go your route with the additional meta property if you are willing to support it. We just need guidance on the best way to implement the feature if we go that route.

What is lacking is the possibility to tag a test and the possibility to divide a test into steps.

@hdorgeval, It seems that you are talking about the Implement test sections #1381 feature?

@AlexanderMoskovkin I submitted a PR to support this issue #2298

Done in https://github.com/DevExpress/testcafe/commit/d4be3b190755b613e73ae3c69894ef523b55ff0d


Notification is not popping up when app is in foreground

Platform: ios, Android
Notification is not popping up when app is in foreground.
What can be the reason?

it's hidden by default

What is the parameter or configuration for them to be displayed?

I am facing similar issue. Any workaround?

@nguyendinhdoan Do you know how it will be possible to enable for Android?

I'll be working on it today or tomorrow and I'll let you know @zahs
for iOS I have added this to my AppDelegate.h
Update AppDelegate.h
At the top of the file:
#import <UserNotifications/UNUserNotificationCenter.h>
Then, add the 'UNUserNotificationCenterDelegate' to protocols:
@interface AppDelegate : UIResponder <UIApplicationDelegate, RCTBridgeDelegate, UNUserNotificationCenterDelegate>
and for AppDelegate.mm
just follow these docs:
https://wix.github.io/react-native-notifications/docs/getting-started#ios
and put this part from my top comment:
https://github.com/wix/react-native-notifications/issues/891#issuecomment-1260741637
I have implemented all listeners as they should be, with background and foreground notifications

Perfect thank you :)
for iOS it is working already for me.

android does not work

This was happening for us but then we realised it was necessary to explicitly handle the notification received foreground event in the react native code:
  Notifications.events().registerNotificationReceivedForeground((notification, completion) => {
    completion({ alert: true, sound: false, badge: false })
  })

Without handling that event like that, no notifications were shown when in the foreground.

This was happening for us but then we realised it was necessary to explicitly handle the notification received foreground event in the react native code:
  Notifications.events().registerNotificationReceivedForeground((notification, completion) => {
    completion({ alert: true, sound: false, badge: false })
  })

Without handling that event like that, no notifications were shown when in the foreground.

I have followed the documentation and everything works correctly.

I also follow the doc but I did not get notifications when the android app is in the foreground.Please help us to implement.

In IOS Notification, image are not shown.


Separate nodes

As raised by @orioltinto, on Pull Request #5, new nodes created by using simple UI pile up as shown in the following image.

To Do: Creating new nodes should displace each node to facilitate the user to modify properties.

The sections to modify are from lines 73 -91 and [ lines 211 - 221 ] (https://github.com/blendernc/blendernc/blob/1dcfe6a37f13b990ecbfab3d545ce646ee638b9e/blendernc/operators.py#L211)

#13 Addresses the separation of nodes at the default BlenderNC node_group.

Fully solved with #13.


[SQOOP-3010] Fix for Sqoop should not allow --as-parquetfile when job…

… type is hcatalog

Hi @git-rbanerjee ,
Sqoop project currently does not accept pull requests. To contribute, you will need to generate patch and upload it to the JIRA.
See the instructions here: https://cwiki.apache.org/confluence/display/SQOOP/How+to+Contribute
If you need more directions, I'd be happy to help!

Closing this PR since the corresponding JIRA seems to be closed already.


bump-awscnf-version-to-12-7-0

let's use the new fancy version

You can change the sha from master after merging with k -n rfjh2 edit app test-infra.


Remove automatic escaping of preferences values

With this change, preference values are now not escaped on POST.
They are already escaped properly when saving the config and this PR adds output escaping to preferences controlled in the core.
Fixes #2763
Closes #2769

@michael-e So we then have no-way of fixing this problem in the LTS release ?

do what you do in this pull request — breaking change

I do not agree that it is a breaking change. Values that were saved with the old behaviour will still be saved with the new code. I understand that it may brings a new XSS vector in extension, which should be fixed.
Maybe @jensscherbl could help us classify this better. I feel ok merging this into the LTS release.

@michael-e Do you still oppose to this getting merged in 2.7.x ?

Unfortunately @jensscherbl has not joined the discussion. I personally still feel that this is a breaking change. But: It might be wise to accept that semantic versioning is a great idea that sometimes can not be followed without side effects and headache. :-)
I agree that this would improve the LTS version. At the same time we would have to open issues for all extensions that use the Symphony prefs, correct?
BTW: How severe is the attack vector at all? It's just an "internal backend attack", right?

How severe is the attack vector at all? It's just an "internal backend attack", right?

Yes. You can only XSS yourself as long as the frontend is not allowed to set values in the config.php file, which it should never do.
I would do a thorough audit of extension I use to make sure they are patched.

It might be wise to accept that semantic versioning is a great idea that sometimes can not be followed without side effects and headache. :-)

Indeed.


Fixed typo in method name

specifiyHeaders was corrected to specifyHeaders.
This change will obviously break code that uses the library and has classes that extend TupleToMessage by overriding the method, but I think that it's not much of an issue due the following facts:

The change is trivial so any codebase extending TupleToMessage can make the necessary code update in seconds
The version of the library is pre 1.x so breaking changes are to be expected

Great, thanks for the PR.

On 8 Nov 2015 01:46, "Peter Pathirana"<EMAIL_ADDRESS>wrote:

Merged #35 https://github.com/ppat/storm-rabbitmq/pull/35.
—
Reply to this email directly or view it on GitHub
https://github.com/ppat/storm-rabbitmq/pull/35#event-458023830.


Update namespace test to expect new error message

The response to this command used to be "no", now
it's "no - no RBAC policy matched" I think this
changed when the cluster was upgraded to
kubernetes 1.12.10
Updated: This may only be happening to David S. so it might relate to
specific kubectl versions. A better option might be to check for /^no/
rather than an exact string.

I'm going to check this on a different machine, before merging. I want to ensure that the error message is consistent, because I'm pretty sure Jason doesn't get the same error message text for the relevant tests.


Move away from grunt, and to ES modules

The build system for this lib is very dated. It currently uses gruntjs and file concatenation. It would be good to:

[x] Switch to ES modules
[ ] Improve modularisation of library
[x] Use something like rollup for bundling (this is preferable to webpack as it gives better bundle size for libraries)
[x] Update the scripts in package.json to be updated to then call rollup
[x] Consider something like cypress for testing.
[ ] Get CI setup properly
[x] Run prettier over repo

I've started on this. Got a basic build working. Just need to get uglify/terser integrated now.
After that I will look at modernising the codebase to use ES6+ features (arrows, class etc), and integrating babel.

We should probably also migrate from jshint to eslint. We can use this to migrate the current config if you don't want to adopt of of the standards: https://github.com/brenolf/polyjuice

WIP PR here: #324

Decided to skip modularisation for now, as I'd rather this contain as few changes to src as possible. This can be done as a follow-up.


net: http: client: Return error if waiting timeout

Return error to the caller if no data was received or there was some other error. Earlier we did not check the error condition properly.

Hey, sorry I am commenting after this was merged, but wasn't the lack of error output in this scenario intentional?
NULL HTTP output was instead indicated with the special status 0:
https://github.com/zephyrproject-rtos/zephyr/pull/43453/commits/d31d3bf445c85363db76bf7d8a011cb2a91e9241
@rlubos @fabiobaltieri
Are we making the decision to reverse that decision? In which case documentation from my PR needs to be updated as well, and we will need to refactor libraries relying on the old behavior.
See the issue I raised about this topic for discussion of whether NULL HTTP output should be considered a connection error:
https://github.com/zephyrproject-rtos/zephyr/issues/42988

@jukkar Were there any other edge cases, other than connection close, covered by this change? If not, perhaps we should indeed revert this change, and just document it better, that in case of no response, it'd be notified in the registered callback with the special status code (0)?

I noticed the issue while working on #63531, I can check what it means to revert this.

 Host: 19
                                   32 2e 31 36 38 2e 38 38  2e 31 35 3a 34 32 34 32 |2.168.88 .15:4242
                                   0d 0a 0d 0a                                      |....
[00:00:21.292,000] <dbg> net_http: http_client_req: (conn_mgr_monitor): Sent 68 bytes
[00:00:23.301,000] <dbg> net_http: http_wait_data: Timeout
[00:00:23.309,000] <dbg> net_http: http_data_final_null_resp: (conn_mgr_monitor): Calling callback for Final Data(NULL HTTP response)
[00:00:23.323,000] <dbg> online_checker: response_cb: (conn_mgr_monitor): All the data received (0 bytes)
[00:00:23.335,000] <inf> online_checker: Response status
[00:00:23.343,000] <dbg> net_http: http_client_req: (conn_mgr_monitor): Received 0 bytes
[00:00:23.354,000] <dbg> online_checker: exec_http_query: (conn_mgr_monitor): Received HTTP status 0, not considering online.
[00:00:23.368,000] <dbg> net_sock: z_impl_zsock_close: (conn_mgr_monitor): close: ctx=0x20022d98, fd=0

and then with the fix
[00:00:03.318,000] <dbg> online_checker: do_online_http_check: (conn_mgr_monitor): Sending HTTP GET request to <IP_ADDRESS>:4242 (ifindex 1)
[00:00:03.334,000] <dbg> net_http: http_flush_data: Data to send
                                   47 45 54 20 68 74 74 70  3a 2f 2f 31 39 32 2e 31 |GET http ://192.1
                                   36 38 2e 38 38 2e 31 35  3a 34 32 34 32 20 48 54 |68.88.15 :4242 HT
                                   54 50 2f 31 2e 31 0d 0a  48 6f 73 74 3a 20 31 39 |TP/1.1.. Host: 19
                                   32 2e 31 36 38 2e 38 38  2e 31 35 3a 34 32 34 32 |2.168.88 .15:4242
                                   0d 0a 0d 0a                                      |....
[00:00:03.388,000] <dbg> net_http: http_client_req: (conn_mgr_monitor): Sent 68 bytes
[00:00:05.398,000] <dbg> net_http: http_wait_data: Timeout
[00:00:05.406,000] <dbg> net_http: http_data_final_null_resp: (conn_mgr_monitor): Calling callback for Final Data(NULL HTTP response)
[00:00:05.421,000] <dbg> online_checker: response_cb: (conn_mgr_monitor): All the data received (0 bytes)
[00:00:05.433,000] <inf> online_checker: Response status
[00:00:05.441,000] <dbg> net_http: http_client_req: (conn_mgr_monitor): Timeout while waiting data
[00:00:05.452,000] <dbg> online_checker: exec_http_query: (conn_mgr_monitor): HTTP request failed (-116)
[00:00:05.464,000] <dbg> net_sock: z_impl_zsock_close: (conn_mgr_monitor): close: ctx=0x20022d98, fd=0

So the difference is that with original code and when a HTTP reply is not received, we get HTTP status 0 which just looks plain wrong as there was no HTTP server at the other end.
With the fix, we get ETIMEDOUT error which IMHO makes sense in this case.
WDYT?

The code checks if there was any data received from server total_recv == 0, which means there was a timeout regardless of what happened in the server side. So what you are describing are same thing from client point of view.
How do you propose to detect this NULL response in client side?

Wouldn't unresponsive server result in total_recv < 0?

No, an error like ECONNREFUSED would only be returned if there is no port listener. If there is but it refuses to talk, then everything is ok from client point of view. Only if there is no data returned, we get a timeout error.

@glarsennordic I think I found a way to detect what you asked. See #70816 for details.


Explore the possibility to integrate other testing frameworks

Is your feature request related to a problem? Please describe.
A team contacted me to replace karma with ui5-test-runner. However, they are using Jasmine  for unit tests. This is currently not supported.
Describe the solution you'd like
Exploring Jasmine documentation, I see that the framework exposes a JsAPIReporter that enables tracking of the tests.
One idea would be to enable the injection of additional hooks which produce the same output for ui5-test-runner.
Ideally, the progress report should be preserved to let the user know where the tests are (also to format the test results).
Describe alternatives you've considered
In the worst situation, a hook could be designed to only report the test results.

We would be really interested by this feature in order to support the describe/it syntax.

@Shingaz To be clear : the goal is not to support any describe/ it syntax but rather enables the integration of other frameworks than QUnit. Still, it would require some integration to process test results.