registry.k8s.io/liveness image in liveness example only works on AMD64 CPUs

This is a Bug Report
Problem:
The liveness example as per https://github.com/kubernetes/website/blob/main/content/en/examples/pods/probe/http-liveness.yaml -
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

Makes use of image registry.k8s.io/liveness. This fails when running on arm based architectures like apple silicon.
Logs as follows when attempting to use this example -
# kubectl logs pod/liveness-http
runtime: failed to create new OS thread (have 2 already; errno=22)
fatal error: runtime.newosproc

goroutine 16 [running]:
runtime.throw(0x7de6c6)
        /usr/lib/google-golang/src/pkg/runtime/panic.c:520 +0x69 fp=0x2aaaab45fec0 sp=0x2aaaab45fea8
runtime.newosproc(0x4c208016000, 0x2aaaab47dfa8)
        /usr/lib/google-golang/src/pkg/runtime/os_linux.c:150 +0xfa fp=0x2aaaab45ff10 sp=0x2aaaab45fec0
newm(0x4158e0, 0x0)
        /usr/lib/google-golang/src/pkg/runtime/proc.c:933 +0xc9 fp=0x2aaaab45ff50 sp=0x2aaaab45ff10
runtime.main()
        /usr/lib/google-golang/src/pkg/runtime/proc.c:219 +0x3c fp=0x2aaaab45ffa8 sp=0x2aaaab45ff50
runtime.goexit()
        /usr/lib/google-golang/src/pkg/runtime/proc.c:1445 fp=0x2aaaab45ffb0 sp=0x2aaaab45ffa8
created by _rt0_go
        /usr/lib/google-golang/src/pkg/runtime/asm_amd64.s:97 +0x12

Proposed Solution:
Ideally, this image should be updated to support multiple architectures. Sadly I've not been able to find either the source code for this image or the owner. It has been in use as a standard for many years.
Alternatively, the creation of a new multi-architecture image that can be used as a drop in replacement may be beneficial.
Page to Update:
https://github.com/kubernetes/website/blob/main/content/en/examples/pods/probe/http-liveness.yaml

The image in question appears to have been made in 2014, almost 10 years old. Details here:
https://explore.ggcr.dev/?image=registry.k8s.io%2Fliveness%40sha256%3A1aef943db82cf1370d0504a51061fb082b4d351171b304ad194f6297c0bb726a&jq=.history[0].v1Compatibility

Just noting - we have a lot of recurring issues pop up for ARM (e.g. #45420) due to tutorial images not being multi-arch.
Not sure of the best way to address this holistically, but it does seem there needs to be some larger effort to either replace these tutorial instructions to only use multi-arch images, or have some process in place that maintains and keep these tutorial images up to date so they are more likely to be usable for most people.

Thank you @stmcginnis
Agreed, it would be great to have multi-architecture images as standard.
I think this example also highlights another issue and that is the lack of supply chain transparency with some of the images that we readily rely on in the documentation, especially in light of recent events like xz.
Prior to raising this issue, I spent considerable time unsuccessfully looking for the source code for the image in question.
This example is one which I believe would be used by many, given that it's a common example for learning/using liveness/readiness probes, not to mention it being a popular topic for those with the likes of the CKAD examination.
It may be worthwhile us expanding these discussions to include security provisions for efforts/improvements in this space.

Would someone like to request that the tutorials aim to use multi-arch container images? If that's you, you can file a feature request.

The fix for this report is to say that the example only works on AMD64 CPUs.

Thanks for your feedback @sftim
I'll update the issue as per your feedback and I would also like to pick up the feature request for this.

@sftim - For this issue where registry.k8s.io/liveness is not available as a multi-arch image, I was able to find the source code for the container image in question but I was not able to build an image from it.
It looks as if historically the file referenced for this was part of a bigger code base/toolset and even though it's referenced in documentation, it doesn't build as is without modifications.
This is the referenced source code for the liveness image

https://raw.githubusercontent.com/kubernetes/kubernetes/master/test/images/agnhost/liveness/server.go

I simplified this and created an equivalent version which satisfies the test and at the same time, have built this as a multi-arch container image. Details as follows -
Source Code: https://github.com/spurin/liveness
Docker Hub: https://hub.docker.com/r/spurin/liveness
Would it be acceptable for me raise a PR changing the current documentation image from registry.k8s.io/liveness to spurin/liveness or is there a specific requirement to have referenced images like this on registry.k8s.io
Thanks

Would it be acceptable for me raise a PR changing the current documentation image from registry.k8s.io/liveness to spurin/liveness or is there a specific requirement to have referenced images like this on registry.k8s.io

I don't think we'd merge that. We prefer to reference images from a supply chain with obvious grounds that we can trust it, and in general one contributor's personal set of images doesn't pass the quality bar.
How about opening a PR against https://github.com/kubernetes/kubernetes/ instead?
Also see https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/README.md

Thanks for your candour @sftim, I thought this was the case but was also interested in this from a self learning viewpoint for some exam study so not all lost, my own personal testing image for arm in the interim :-)
I found the source code for the liveness image in that subset that you've referenced but I wasn't able to find anything relating to the build of the registry.k8s.io/liveness image. In it's current form it also seems to be a module (package liveness) rather than a direct executable and I'm guessing there was some kind of additional wrapper code to get it to where it is today.
It may be best, starting with the ownership/management of that registry.k8s.io/liveness image and working backwards. If you have any recommendations on who to reach out to on this I'll follow up accordingly.

Agree with @sftim we need to switch that to the agnhost image - https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go
You can see that we use this agnhost image in our conformance tests as well:
https://github.com/kubernetes/kubernetes/blob/9791f0d1f39f3f1e0796add7833c1059325d5098/test/e2e/common/node/container_probe.go#L169-L177
Here's where we create the pod by passing liveness as an argument to the container:
https://github.com/kubernetes/kubernetes/blob/9791f0d1f39f3f1e0796add7833c1059325d5098/test/e2e/common/node/container_probe.go#L1625-L1631

Thanks for your feedback @dims
I'm unsure historically, how we got from https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go
to the container image of registry.k8s.io/liveness ?
The agnhost container image appears to be independent of this. It accepts parameters. An example is shown for liveness under the main root of that source tree -
kubectl exec test-agnhost -- /agnhost liveness

The current readiness/liveness example in the documentation doesn't appear to be using the agnhost image in this way, it looks as if it is an independent image -
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

I was able to get the agnhost container image working with the liveness/readiness example with relative ease and this image is already multi-arch 👍  Here's the yaml tested successfully on arm64 -
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

If this is a positive direction, I can raise a PR to change the existing liveness example to use the agnhost image. Please share your thoughts.

If this is a positive direction, I can raise a PR to change the existing liveness example to use the agnhost image. Please share your thoughts.

Yep, please go ahead with that.

@spurin we went the other way registry.k8s.io/liveness was the really one old one and we consolidated a bunch of images into agnhost. we just forgot to update the documention.
yes, please go ahead as @sftim already mentioned.

Thanks @dims - appreciate the context and background on this, makes complete sense now :-)

Closing this, moved to agnhost image, multi-arch images as standard being discussed here - https://github.com/kubernetes/website/issues/45822


Cannot connect to VM Service via IPv6 loopback in cloud environment

Original issue: dart-lang/sdk#45365.
flutter_tools is trying to connect to DWDS/DDS in a cloud environment via [::1] which results in a Cannot assign requested address error. Updating this URI in Flutter tools to have a localhost host seems to allow for the connection to succeed.
cc @DanTup @jonahwilliams

I'd previously tried to repro this with some simple scripts (just hosting and connecting to a websocket) but failed (it seemed to work). I did have some issues connecting from Dart-Code which I've worked around for now by replacing [::] with localhost when connecting there, but I don't fully understand why it failed.
I have a weird recollection of something in the past (I can't remember if it was in Dart/Flutter or a previous system I worked on), where localhost would resolve to both <IP_ADDRESS> and ::, and some processes would get one and others another. I wonder if something similar may be happening here. It'd be interesting to know if using <IP_ADDRESS> works, and if so, where the IPv6 loopback IP is coming from. I'll try to do some more testing.

Replacing the hostname with <IP_ADDRESS> also works. The /etc/hosts file in this environment does include both IPs for localhost:
<IP_ADDRESS>       localhost
::1     localhost ip6-localhost ip6-loopback

This definitely sounds something like the issue described above... The service is binding to localhost that was resolved as <IP_ADDRESS> but in flutter_tool it's ended up resolving to its IPv6 address. I found the original place this came up - it was at https://github.com/dart-lang/webdev/issues/233. My nodeJS debugger was resolving as IPv4 but the service was only bound to IPv6. This seems like the opposite problem now.
I see in flutter_tools there's an --ipv6 flag to enable IPv6 support, but that's not being passed here, so I wonder where the ipv6 loopback address is coming from that's being used here.

Ok, I think I've tracked this down. I'm passing --web-hostname any to Flutter (IIRC this is because we need Flutter to bind to all network IPs and not just the loopback, so we can connect from the proxy). This is then passed to DWDS, which is passed to HttpMultiServer:
https://github.com/dart-lang/webdev/blob/658f69284cab7b025a4742f1039ced6e16cd6143/dwds/lib/src/services/debug_service.dart#L259-L263
However, reading server.address.host then returns the IPv6 loopback IP which is not actually bound, so the connection fails.
I can repro this without Flutter, DDS or DWDS with the following code:
Works with localhost
import 'dart:convert';
import 'dart:io';

import 'package:http_multi_server/http_multi_server.dart';

main() async {
  var server = await HttpMultiServer.bind('any', 0);
  print('Listening at ${server.address.host}:${server.port}!');
  server.listen((req) {
    req.response.write('Hello, world!');
    req.response.close();
  });

  var client = new HttpClient();
  var req = await client.get(server.address.host, server.port, '/');
  var resp = await req.close();
  var output = await resp.toList();
  for (var out in output) {
    print(utf8.decode(out));
  }

  server.close();
}

It seems if I pass any then it only binds to IPv4, but returns the IPv6 loopback address. However, if I try to bind specifically to IPv6, then I receive the same error as above. So I think next may be failing to bind to IPv6 silently, but still returning its address - but the actual problem is that it thinks IPv6 is supported but it actually doesn't work.
So this may be a HttpMultiServer issue, or it may be that this environment is weird (looking like IPv6 is supported but not). I'll do some testing to see if I can avoid using --web-hostname any as well as track down what's happening in HttpMultiServer (and whether it's the environment that's broken).

Ok, it turns out we don't need --web-hostname any or --disable-dds here now. I'm not sure why we don't need the former, and I think using it is what had led us to need the latter.
So I think this is resolved - though @kevmoo @jakemac53  if my last comment above seems like a bug in HttpMultiServer that should be raised in its repo, let me know. Thanks!

(After discussing with @grouma, this definitely seems like a HttpMultiServer bug so I've filed https://github.com/dart-lang/http_multi_server/issues/35)


Fix loading of OpenCL library on MacOS

There opencl-stub loader's previous implementation, checks if the default_so_path exist.
However, for MacOS, the frameworks path does not exist, but dlopen will correctly find the expected stuffs.

LGTM


updated docs folder to 0.7

updated dockerhub and ngc docs in docs folder

looks goo, read to be merged


Fusion360 3rd-party add-ins still possible?

I can't figure out how I would go about loading a third-party add-in now. I've done it once before, but it seems Autodesk has eliminated this functionality now.

Download the ExportIt.zip file from https://github.com/WilkoV/Fusion360_ExportIt/releases/tag/0.9.0, unpack it to a folder you like and follow the installation steps I've outlined here. https://github.com/WilkoV/Fusion360_ExportIt/tree/0.9.0#installation
Let me know if it worked for you.

Closed because no feedback. I guess the problem is solved.


PDF Tool and UTc-8

Trying to read a PDF and keep running into an "invalid continuation byte" from some searching it seems that this is due to the encoding of the PDF but I haven't found a viable way to get around this. Any help would be greatly appreciated. I'm new to Github so also please let me know if this is the improper way to go about asking this. Thanks!

In my case, if your Pdf only contain text and tables better convert it to markdown file, its more readable by LLM.
you can use Llamaparse, they give a good job for me and give 1k free pages free daily.


Feature request

can i login and change profie photo, email address, post image, add bio, add website link with cookie. because i have a lot of account about 1k

You can do it

but with private api? @sunmasters

yes


Unable to connect to the server: x509: certificate signed by unknown authority - inconsistent behavior

Environmental Info:
K3s Version:

# k3s -v
k3s version v1.19.7+k3s1 (5a00e38d)

Node(s) CPU architecture, OS, and Version:

Linux k3s-ya-1 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Linux k3s-ya-2 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Linux k3s-ya-3 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Cluster Configuration:

3 masters
Describe the bug:

# kubectl get nodes
Unable to connect to the server: x509: certificate signed by unknown authority
[root@k3s-ya-1 ~]# k3s kubectl get nodes
Unable to connect to the server: x509: certificate signed by unknown authority
[root@k3s-ya-1 ~]#

However, the result is inconsistent.  Sometimes the first master node will work but 2nd and 3rd node Unable to connect to the server: x509: certificate signed by unknown authority
Steps To Reproduce:

Installed K3s:

etcd certs are copied into /root
First node - k3s-ya-1
k3s-uninstall.sh
export INSTALL_K3S_VERSION=v1.19.7+k3s1
export K3S_DATASTORE_CAFILE=/root/ca.crt
export K3S_DATASTORE_CERTFILE=/root/apiserver-etcd-client.crt
export K3S_DATASTORE_KEYFILE=/root/apiserver-etcd-client.key
export K3S_KUBECONFIG_OUTPUT=/root/kube.confg
export K3S_DATASTORE_ENDPOINT=https://etcd1.k8s:2379,https://etcd2.k8s,https://etcd3.k8s:2379
k3s.install server

# kubectl get nodes
Unable to connect to the server: x509: certificate signed by unknown authority

^^^ this result is inconsistent - sometimes works, sometimes not
cat /var/lib/rancher/k3s/server/node-token to get token for use with additional nodes.
2nd node - k3s-ya-2
k3s-uninstall.sh
export INSTALL_K3S_VERSION=v1.19.7+k3s1
export K3S_DATASTORE_ENDPOINT=https://etcd1.k8s:2379,https://etcd2.k8s,https://etcd3.k8s:2379
export K3S_DATASTORE_CAFILE=/root/ca.crt
export K3S_DATASTORE_CERTFILE=/root/apiserver-etcd-client.crt
export K3S_DATASTORE_KEYFILE=/root/apiserver-etcd-client.key
export K3S_TOKEN=--from first node--
export K3S_URL=https://k3s:6443
export K3S_KUBECONFIG_OUTPUT=/root/kube.confg
k3s.install server

# kubectl get nodes
NAME                  STATUS   ROLES                  AGE    VERSION
k3s-ya-1   Ready    control-plane,master   2d5h   v1.19.7+k3s1
k3s-ya-2   Ready    control-plane,master   36h    v1.19.7+k3s1

^^^ this time it worked - last 3 attempts 2nd node didn't work but the 1st node did - go figure.
3rd node
k3s-uninstall.sh
export INSTALL_K3S_VERSION=v1.19.7+k3s1
export K3S_DATASTORE_ENDPOINT=https://etcd1.k8s:2379,https://etcd2.k8s,https://etcd3.k8.:2379
export K3S_DATASTORE_CAFILE=/root/ca.crt
export K3S_DATASTORE_CERTFILE=/root/apiserver-etcd-client.crt
export K3S_DATASTORE_KEYFILE=/root/apiserver-etcd-client.key
export K3S_TOKEN=--from first node--
export K3S_URL=https://k3s:6443
export K3S_KUBECONFIG_OUTPUT=/root/kube.confg
k3s.install server
# kubectl get nodes
NAME                  STATUS   ROLES                  AGE    VERSION
k3s-ya-1   Ready    control-plane,master   2d5h   v1.19.7+k3s1
k3s-ya-2   Ready    control-plane,master   36h    v1.19.7+k3s1
k3s-ya-3   Ready    master                 19s    v1.19.7+k3s1

^^^ more expected - 1/2 the time yields Unable to connect to the server: x509: certificate signed by unknown authority
Expected behavior:

Consistent behavior after k3s sever is installed. kubectl should work without certificate errors across all nodes.
Actual behavior:

Inconsistent.  Some nodes Unable to connect to the server: x509: certificate signed by unknown authority others can.  Uninstall and repeat - different results.
Yesterday entire cluster was working as expected no errors across all nodes with Rancher installed and running another cluster as expected.
Today, Unable to connect to the server: x509: certificate signed by unknown authority on every k3s node.
It's almost like the certificates are playing musical chairs.
Additional context / logs:

Samples from /var/log/messages
Feb  8 20:55:42 k3s-ya-1 k3s: time="2021-02-08T20:55:42.901658387-05:00" level=info msg="Cluster-Http-Server 2021/02/08 20:55:42 http: TLS handshake error from <IP_ADDRESS>:43082: remote error: tls: bad certificate"
Feb  8 20:55:43 k3s-ya-1 k3s: time="2021-02-08T20:55:43.012864767-05:00" level=info msg="Cluster-Http-Server 2021/02/08 20:55:43 http: TLS handshake error from <IP_ADDRESS>:46490: remote error: tls: bad certificate"

Feb  8 20:56:37 k3s-ya-2 k3s: time="2021-02-08T20:56:37.629125982-05:00" level=info msg="Cluster-Http-Server 2021/02/08 20:56:37 http: TLS handshake error from <IP_ADDRESS>:35180: remote error: tls: bad certificate"
Feb  8 20:56:37 k3s-ya-2 k3s: time="2021-02-08T20:56:37.840388714-05:00" level=info msg="Cluster-Http-Server 2021/02/08 20:56:37 http: TLS handshake error from <IP_ADDRESS>:42518: remote error: tls: bad certificate"

Feb  8 20:57:49 k3s-ya-3 k3s: E0208 20:57:49.215716     829 event.go:273] Unable to write event: 'Patch "https://<IP_ADDRESS>:6443/api/v1/namespaces/kube-system/events/helm-install-traefik-4lncd.1661f1476f8d4e12": x509: certificate signed by unknown authority' (may retry after sleeping)
Feb  8 20:57:49 k3s-ya-3 k3s: time="2021-02-08T20:57:49.361122818-05:00" level=info msg="Connecting to proxy" url="wss://<IP_ADDRESS>:6443/v1-k3s/connect"
Feb  8 20:57:49 k3s-ya-3 k3s: time="2021-02-08T20:57:49.362442817-05:00" level=error msg="Failed to connect to proxy" error="x509: certificate signed by unknown authority"
Feb  8 20:57:49 k3s-ya-3 k3s: time="2021-02-08T20:57:49.362463456-05:00" level=error msg="Remotedialer proxy error" error="x509: certificate signed by unknown authority"
Feb  8 20:57:49 k3s-ya-3 k3s: time="2021-02-08T20:57:49.367212594-05:00" level=info msg="Connecting to proxy" url="wss://<IP_ADDRESS>:6443/v1-k3s/connect"

You don't need to set K3S_URL (--server) when using an external datastore; this is only for use when joining agents or using embedded etcd.
I am curious how you came to have two nodes with the control-plane role label. This wasn't added until 1.20, yet your nodes are all still on 1.19. Did you upgrade temporarily, and then downgrade again>
I have usually seen behavior like this in the past when servers were all brought up at the same time and raced to bootstrap the cluster CA certs, or when nodes were started up with existing certs that they then try to use instead of the ones recognized by the rest of the cluster.
It sounds like these nodes have been through some odd things. I run my personal cluster with an external etcd and haven't had any problems with it; I suspect something in the way you started up, upgrade, or grew this cluster has left it very confused about what certificates to use.

You don't need to set K3S_URL

Added the KS3_URL to see if that would make any difference. Started second guessing and wondering if the 2nd/3rd nodes were fighting with the first then added K3S_URL wondering if that was the missing piece but didn't seem to make a difference or change any behavior.  Nice to get some clarification that it's only agent nodes that need it.

curious how you came to have two nodes with the control-plane role label

Was wondering about that as well.  The control-plane label comes and goes. At one point I saw nodes reporting 1.20 in the get nodes output even though INSTALL_K3S_VERSION=v1.19.7+k3s1 env var was set which felt weird.  There was an initial upgrade run without that env var set a couple of days ago and the nodes all ended up on v1.20+ but then Rancher refused to install so I uninstalled each node and, added the env var to downgrade so that rancher would install.
That got everything running again - but then the next day Unable to connect to the server: x509: certificate signed by unknown authority

seen behavior like this when servers were all brought up at the same time

Makes sense.  Am starting/upgrading/uninstalling nodes one by one through this process so doubt that was happening on these re-installs.  Although, the initial failure was due to the physical server (it's a KVM linux box with each node being a VM) being shut down gracefully and restarted so the nodes would have been re-starting pretty much at the same time when the box was powered back up.

sounds like these nodes have been through some odd things.

Feels the same.  Initial installation last March, testing for a week (k3s+rancher) - then they just lay there idling until powering down the box and powering back up and the cluster was broken.
FYI, the original nodes running this cluster have all been deleted and replaced with branch new fresh 'n clean VMs hoping to purge any weirdness.
It's disconcerting that there doesn't seem to be a path to recover this sick cluster.  There's no way I would feel confident going into production if a reboot (graceful or otherwise) could throw things into an unrecoverable state.
Where exactly is the configuration for the certificate(s) on each node located?

The control-plane label comes and goes. At one point I saw nodes reporting 1.20 in the get nodes output even though INSTALL_K3S_VERSION=v1.19.7+k3s1 env var was set which felt weird.

That variable is only used by the install script. Do you somehow have something running that is reinstalling and restarting K3s? It doesn't self-update, although the system-upgrade-controller (available through Rancher) will create jobs to do rolling updates to the cluster. Is that something you were playing with at some point? Do you perhaps have multiple nodes (old VMs or something) with duplicate hostnames pointed at the etcd datastore?

It's disconcerting that there doesn't seem to be a path to recover this sick cluster.

At the very least you should be able to stabilize the cluster by going down to a single server node so that they're not all arguing about certificates. Just uninstall all but one, delete the nodes, make sure the local disk is clean, then reinstall one at a time. This assumes you figure out what it is that's changing your versions...

Where exactly is the configuration for the certificate(s) on each node located?

/var/lib/rancher/k3s/server/tls/

Do you somehow have something running that is reinstalling and restarting K3s?

Hmm, the VMs are deployed with chef... manually walked through the chef deployment and not seeing anywhere it's running or restart k3s best I can tell - to be certain I did comment out the k3s install section where it downloads the k3s.install script to make sure it's not the culprit.

system-upgrade-controller

Haven't played with that at all.  Overall it's very plain jane and not much experimentation beyond installing Rancher on top of k3s.

you should be able to stabilize the cluster by going down to a single server node

Great idea, have done exactly that.  Now running a freshly re-installed single node and keeping an eye on the timestamps in /var/lib/rancher/k3s/server/tls/ hoping that will at least tell me if those certs are getting changed by anything.
The kube-system pods aren't happy and the now single node cluster is limping along in poor shape.
NAME                         READY   STATUS             RESTARTS   AGE
coredns-66c464876b-cm94q     0/1     Running            0          68m
helm-install-traefik-cxbm2   0/1     CrashLoopBackOff   18         70m
svclb-traefik-4t79s          2/2     Running            0          83m
traefik-6f9cbd9bd4-f9r92     1/1     Running            0          81m

helm-install-traefik is crashlooping and coredns is stuck with this in the logs:
[INFO] plugin/ready: Still waiting on: "kubernetes"
E0209 20:54:55.692578       1 reflector.go:153] pkg/mod/k8s.io/client-go@v0.17.4/tools/cache/reflector.go:105: Failed to list *v1.Endpoints: Get "https://<IP_ADDRESS>:443/api/v1/endpoints?limit=500&resourceVersion=0": x509: certificate signed by unknown authority
E0209 20:54:55.694071       1 reflector.go:153] pkg/mod/k8s.io/client-go@v0.17.4/tools/cache/reflector.go:105: Failed to list *v1.Namespace: Get "https://<IP_ADDRESS>:443/api/v1/namespaces?limit=500&resourceVersion=0": x509: certificate signed by unknown authority
E0209 20:54:55.694896       1 reflector.go:153] pkg/mod/k8s.io/client-go@v0.17.4/tools/cache/reflector.go:105: Failed to list *v1.Service: Get "https://<IP_ADDRESS>:443/api/v1/services?limit=500&resourceVersion=0": x509: certificate signed by unknown authority
E0209 20:54:56.694804       1 reflector.go:153] pkg/mod/k8s.io/client-go@v0.17.4/tools/cache/reflector.go:105: Failed to list *v1.Endpoints: Get "https://<IP_ADDRESS>:443/api/v1/endpoints?limit=500&resourceVersion=0": x509: certificate signed by unknown authority
E0209 20:54:56.695503       1 reflector.go:153] pkg/mod/k8s.io/client-go@v0.17.4/tools/cache/reflector.go:105: Failed to list *v1.Namespace: Get "https://<IP_ADDRESS>:443/api/v1/namespaces?limit=500&resourceVersion=0": x509: certificate signed by unknown authority
E0209 20:54:56.696994       1 reflector.go:153] pkg/mod/k8s.io/client-go@v0.17.4/tools/cache/reflector.go:105: Failed to list *v1.Service: Get "https://<IP_ADDRESS>:443/api/v1/services?limit=500&resourceVersion=0": x509: certificate signed by unknown authority

Have kubectl delete -f /var/lib/rancher/k83/server/manifests/coredns.yaml and re-applied hoping it would clean itself up but no luck there so far.
Not sure why it's continuing to internally whinge about the certs now that it's a single node.

You might try deleting the crashlooping pod so that it can be recreated with the correct cluster CA certs.

:) I have deleted those mis-behaving pods dozens of times now.  As well as deleted the manifests entirely then re-apply them once confirmed the pods were indeed destroyed.
# kg -n kube-system
NAME                         READY   STATUS             RESTARTS   AGE
coredns-66c464876b-cm94q     0/1     Running            0          130m
helm-install-traefik-cxbm2   0/1     CrashLoopBackOff   30         133m
svclb-traefik-4t79s          2/2     Running            0          145m
traefik-6f9cbd9bd4-f9r92     1/1     Running            0          144m
[root@k3s-ya-1 server]# k -n kube-system delete pod helm-install-traefik-cxbm2
pod "helm-install-traefik-cxbm2" deleted
[root@k3s-ya-1 server]# kg -n kube-system
NAME                         READY   STATUS             RESTARTS   AGE
coredns-66c464876b-cm94q     0/1     Running            0          131m
helm-install-traefik-6c9jx   0/1     CrashLoopBackOff   2          39s
svclb-traefik-4t79s          2/2     Running            0          146m
traefik-6f9cbd9bd4-f9r92     1/1     Running            0          145m

Did you delete the Helm Job that the pod is coming from?

Poking at that crashlooping pod some more:
# k -n kube-system logs helm-install-traefik-6c9jx
CHART=$(sed -e "s/%{KUBERNETES_API}%/${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}/g" <<< "${CHART}")
set +v -x
+ cp /var/run/secrets/kubernetes.io/serviceaccount/ca.crt /usr/local/share/ca-certificates/
+ update-ca-certificates
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
--snip--
[storage] 2021/02/09 21:57:16 listing all releases with filter
[storage/driver] 2021/02/09 21:57:16 list: failed to list: Get "https://<IP_ADDRESS>:443/api/v1/namespaces/kube-system/secrets?labelSelector=OWNER%3DTILLER": x509: certificate signed by unknown authority
Error: Get "https://<IP_ADDRESS>:443/api/v1/namespaces/kube-system/secrets?labelSelector=OWNER%!D(MISSING)TILLER": x509: certificate signed by unknown authority
--snip--
chart path is a url, skipping repo update
Error: no repositories configured
--snip--
Error: Kubernetes cluster unreachable: Get "https://<IP_ADDRESS>:443/version?timeout=32s": x509: certificate signed by unknown authority
--snip--
+ helm_v3 install traefik https://<IP_ADDRESS>:443/static/charts/traefik-1.81.0.tgz --values /config/values-01_HelmChart.yaml
Error: failed to download "https://<IP_ADDRESS>:443/static/charts/traefik-1.81.0.tgz" (hint: running `helm repo update` may help)

Did you delete the Helm Job that the pod is coming from?

Pretty sure it's been deleted.  Am assuming that kdf traefik.yaml would delete the helm job.  That does seem to complete kill off that pod.
# kdf traefik.yaml
helmchart.helm.cattle.io "traefik" deleted

[root@k3s-ya-1 manifests]# kg -n kube-system
NAME                       READY   STATUS    RESTARTS   AGE
coredns-66c464876b-cm94q   0/1     Running   0          139m
svclb-traefik-4t79s        2/2     Running   0          154m
traefik-6f9cbd9bd4-f9r92   1/1     Running   0          153m

[root@k3s-ya-1 manifests]# kaf traefik.yaml
helmchart.helm.cattle.io/traefik created

[root@k3s-ya-1 manifests]# kg -n kube-system
NAME                         READY   STATUS             RESTARTS   AGE
coredns-66c464876b-cm94q     0/1     Running            0          139m
helm-install-traefik-4x847   0/1     CrashLoopBackOff   1          11s
svclb-traefik-4t79s          2/2     Running            0          154m
traefik-6f9cbd9bd4-f9r92     1/1     Running            0          153m

OK this bit is interesting:

cp /var/run/secrets/kubernetes.io/serviceaccount/ca.crt /usr/local/share/ca-certificates/
update-ca-certificates
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping

Somehow the cluster CA has multiple certs in it? Can you cat /var/lib/rancher/k3s/server/tls/server-ca.crt on the server?

Yup - have been eyeing that same log message - multiple certs!? What the...
# cat /var/lib/rancher/k3s/server/tls/server-ca.crt
-----BEGIN CERTIFICATE-----
MIIBdzCCAR2gAwIBAgIBADAKBggqhkjOPQQDAjAjMSEwHwYDVQQDDBhrM3Mtc2Vy
dmVyLWNhQDE2MTI2NDE0OTcwHhcNMjEwMjA2MTk1ODE3WhcNMzEwMjA0MTk1ODE3
WjAjMSEwHwYDVQQDDBhrM3Mtc2VydmVyLWNhQDE2MTI2NDE0OTcwWTATBgcqhkjO
PQIBBggqhkjOPQMBBwNCAATgE2WSc1B+7yNB3IOxahlI80B+uDNqtQ2OG+shRQtd
uuN3ehchBXgZ/7EzmT5QzKD/OWxgDs6D7GGrHfCRzH+so0IwQDAOBgNVHQ8BAf8E
BAMCAqQwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUNguwKhD0HcYEZGwVvs3K
d1XfuGkwCgYIKoZIzj0EAwIDSAAwRQIgW3K54s1DChzOJllhZMBhrBv+zFsmGjg+
/TthN/1Z6U0CIQDu0BZo11CYar1F5h9gyfRLspMLxglCKtXrCwMgHYq2yQ==
-----END CERTIFICATE-----

Looks like a single cert to me. This is so weird - but it certainly is a crash course in troubleshooting k3s!

How about this: kubectl get secret -n kube-system $(kubectl get secret -n kube-system -o custom-columns=NAME:.metadata.name | grep helm-traefik-token) --template='{{index .data "ca.crt" | base64decode}}'

# kubectl delete serviceaccount -n kube-system helm-traefik
serviceaccount "helm-traefik" deleted
# kubectl delete job -n helm-system helm-install-traefik
Error from server (NotFound): jobs.batch "helm-install-traefik" not found
# kubectl delete -f traefik.yaml
helmchart.helm.cattle.io "traefik" deleted

Still seeing some traefik pods running though which makes me wonder why they're still there.
# kg -n kube-system
NAME                       READY   STATUS    RESTARTS   AGE
coredns-66c464876b-cm94q   0/1     Running   0          3h53m
svclb-traefik-4t79s        2/2     Running   0          4h8m
traefik-6f9cbd9bd4-f9r92   1/1     Running   0          4h7m

And same crashloop when re-applying traefik.yaml...
So I also deleted the traefik deployment and the svclib-traefik (sp?) daemonset, redeleted the traefik serviceccount.  the traefik service and traefik-prometheus and coredns just for good measure.
Ended up here:
# k -n kube-system get pods,svc,ds,rs,deploy,jobs,ingress
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
No resources found in kube-system namespace.

Alrighty, looks like kube-system is fully nuked.
# kaf traefik.yaml
helmchart.helm.cattle.io/traefik created
# kg -n kube-system
NAME                         READY   STATUS             RESTARTS   AGE
helm-install-traefik-njn8m   0/1     CrashLoopBackOff   2          35s

Darn.
Here's output of describe on that pod.
# k -n kube-system describe pod helm-install-traefik-njn8m
Name:         helm-install-traefik-njn8m
Namespace:    kube-system
Priority:     0
Node:         k3s-ya-1/<IP_ADDRESS>
Start Time:   Tue, 09 Feb 2021 18:52:17 -0500
Labels:       controller-uid=9d44a166-f197-4800-8d9d-f6f81113ccdd
              helmcharts.helm.cattle.io/chart=traefik
              job-name=helm-install-traefik
Annotations:  helmcharts.helm.cattle.io/configHash: SHA256=54DADC5C41A9E92996BEB90979244F7E4F0D86B23C3F54AAF5BBC497C412496E
Status:       Running
IP:           <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  Job/helm-install-traefik
Containers:
  helm:
    Container ID:  containerd://cca390ef69eb6a7b2bc3a7caca0d6b159ffd558e8d840d0814421d3fac6e720c
    Image:         rancher/klipper-helm:v0.4.3
    Image ID:      docker.io/rancher/klipper-helm@sha256:b319bce4802b8e42d46e251c7f9911011a16b4395a84fa58f1cf4c788df17139
    Port:          <none>
    Host Port:     <none>
    Args:
      install
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 09 Feb 2021 18:53:46 -0500
      Finished:     Tue, 09 Feb 2021 18:53:46 -0500
    Ready:          False
    Restart Count:  4
    Environment:
      NAME:              traefik
      VERSION:
      REPO:
      HELM_DRIVER:       secret
      CHART_NAMESPACE:   kube-system
      CHART:             https://%{KUBERNETES_API}%/static/charts/traefik-1.81.0.tgz
      HELM_VERSION:
      TARGET_NAMESPACE:  kube-system
      NO_PROXY:          .svc,.cluster.local,<IP_ADDRESS>/16,<IP_ADDRESS>/16
    Mounts:
      /chart from content (rw)
      /config from values (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from helm-traefik-token-jwpr6 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  values:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      chart-values-traefik
    Optional:  false
  content:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      chart-content-traefik
    Optional:  false
  helm-traefik-token-jwpr6:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  helm-traefik-token-jwpr6
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  108s                default-scheduler  Successfully assigned kube-system/helm-install-traefik-njn8m to k3s-ya-1
  Normal   Pulled     19s (x5 over 108s)  kubelet            Container image "rancher/klipper-helm:v0.4.3" already present on machine
  Normal   Created    19s (x5 over 108s)  kubelet            Created container helm
  Normal   Started    19s (x5 over 107s)  kubelet            Started container helm
  Warning  BackOff    6s (x10 over 105s)  kubelet            Back-off restarting failed container

And here's the logs from that pod.
# kl -n kube-system helm-install-traefik-njn8m
CHART=$(sed -e "s/%{KUBERNETES_API}%/${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}/g" <<< "${CHART}")
set +v -x
+ cp /var/run/secrets/kubernetes.io/serviceaccount/ca.crt /usr/local/share/ca-certificates/
+ update-ca-certificates
WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
+ '[' '' '!=' true ']'
+ export HELM_HOST=<IP_ADDRESS>:44134
+ HELM_HOST=<IP_ADDRESS>:44134
+ tiller --listen=<IP_ADDRESS>:44134 + --storage=secret
helm_v2 init --skip-refresh --client-only --stable-repo-url https://charts.helm.sh/stable/
[main] 2021/02/09 23:55:07 Starting Tiller v2.16.10 (tls=false)
[main] 2021/02/09 23:55:07 GRPC listening on <IP_ADDRESS>:44134
[main] 2021/02/09 23:55:07 Probes listening on :44135
[main] 2021/02/09 23:55:07 Storage driver is Secret
[main] 2021/02/09 23:55:07 Max history per release is 0
Creating /root/.helm
Creating /root/.helm/repository
Creating /root/.helm/repository/cache
Creating /root/.helm/repository/local
Creating /root/.helm/plugins
Creating /root/.helm/starters
Creating /root/.helm/cache/archive
Creating /root/.helm/repository/repositories.yaml
Adding stable repo with URL: https://charts.helm.sh/stable/
Adding local repo with URL: http://<IP_ADDRESS>:8879/charts
$HELM_HOME has been configured at /root/.helm.
Not installing Tiller due to 'client-only' flag having been set
++ helm_v2 ls --all '^traefik$' ++ jq -r '.Releases | length'
--output json
[storage] 2021/02/09 23:55:07 listing all releases with filter
[storage/driver] 2021/02/09 23:55:07 list: failed to list: Get "https://<IP_ADDRESS>:443/api/v1/namespaces/kube-system/secrets?labelSelector=OWNER%3DTILLER": x509: certificate signed by unknown authority
Error: Get "https://<IP_ADDRESS>:443/api/v1/namespaces/kube-system/secrets?labelSelector=OWNER%!D(MISSING)TILLER": x509: certificate signed by unknown authority
+ EXIST=
+ '[' '' == 1 ']'
+ '[' '' == v2 ']'
+ shopt -s nullglob
+ helm_content_decode
+ set -e
+ ENC_CHART_PATH=/chart/traefik.tgz.base64
+ CHART_PATH=/traefik.tgz
+ '[' '!' -f /chart/traefik.tgz.base64 ']'
+ return
+ '[' install '!=' delete ']'
+ helm_repo_init
+ grep -q -e 'https\?://'
chart path is a url, skipping repo update
+ echo 'chart path is a url, skipping repo update'
+ helm_v3 repo remove stable
Error: no repositories configured
+ true
+ return
+ helm_update install
+ '[' helm_v3 == helm_v3 ']'
++ ++ helm_v3 ls -f '^traefik$' --namespace jq kube-system -r --output '"\(.[0].app_version),\(.[0].status)"'json

++ tr '[:upper:]' '[:lower:]'
Error: Kubernetes cluster unreachable: Get "https://<IP_ADDRESS>:443/version?timeout=32s": x509: certificate signed by unknown authority
+ LINE=
++ echo
++ cut -f1 -d,
+ INSTALLED_VERSION=
++ echo
++ cut -f2 -d,
+ STATUS=
+ VALUES=
+ for VALUES_FILE in /config/*.yaml
+ VALUES=' --values /config/values-01_HelmChart.yaml'
+ '[' install = delete ']'
+ '[' -z '' ']'
+ '[' -z '' ']'
+ helm_v3 install traefik https://<IP_ADDRESS>:443/static/charts/traefik-1.81.0.tgz --values /config/values-01_HelmChart.yaml
Error: failed to download "https://<IP_ADDRESS>:443/static/charts/traefik-1.81.0.tgz" (hint: running `helm repo update` may help)

OK, last thing to try before I declare your certs well and proper hosed:
rm /var/lib/rancher/k3s/server/tls/dynamic-cert.json
kubectl delete secret -n kube-system k3s-serving
systemctl restart k3s
journalctl -u k3s | grep 'k3s-serving\|CN=k3s,O=k3s'

Firehose on...
# rm /var/lib/rancher/k3s/server/tls/dynamic-cert.json
rm: remove regular file ‘/var/lib/rancher/k3s/server/tls/dynamic-cert.json’? y
# kubectl delete secret -n kube-system k3s-serving
secret "k3s-serving" deleted
# systemctl restart k3s

# journalctl -u k3s | grep 'k3s-serving\|CN=k3s,O=k3s'
Feb 09 14:28:07 k3s-ya-1. k3s[12408]: time="2021-02-09T14:28:07.600794282-05:00" level=info msg="certificate CN=k3s,O=k3s signed by CN=k3s-server-ca@1612641497: notBefore=2021-02-06 19:58:17 +0000 UTC notAfter=2022-02-09 19:28:07 +0000 UTC"
Feb 09 14:28:13 k3s-ya-1. k3s[12408]: time="2021-02-09T14:28:13.714099802-05:00" level=info msg="certificate CN=k3s,O=k3s signed by CN=k3s-server-ca@1612641497: notBefore=2021-02-06 19:58:17 +0000 UTC notAfter=2022-02-09 19:28:13 +0000 UTC"
Feb 09 14:28:13 k3s-ya-1. k3s[12408]: time="2021-02-09T14:28:13.717815726-05:00" level=info msg="Updating TLS secret for k3s-serving (count: 16): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-k3s-ya-2.:k3s-ya-2. listener.cattle.io/cn-k3s.:k3s. listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=0E94D246BD6203C7A0353117828477705A5F51B0]"
Feb 09 14:28:13 k3s-ya-1. k3s[12408]: time="2021-02-09T14:28:13.721833744-05:00" level=info msg="Active TLS secret k3s-serving (ver=108089263) (count 16): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-k3s-ya-2.:k3s-ya-2. listener.cattle.io/cn-k3s.:k3s. listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=0E94D246BD6203C7A0353117828477705A5F51B0]"
Feb 09 19:55:42 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:42.034412984-05:00" level=info msg="certificate CN=k3s,O=k3s signed by CN=k3s-server-ca@1612641497: notBefore=2021-02-06 19:58:17 +0000 UTC notAfter=2022-02-10 00:55:42 +0000 UTC"
Feb 09 19:55:48 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:48.147574740-05:00" level=info msg="Active TLS secret k3s-serving (ver=108148589) (count 7): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=CCE5CF00DA34DD811579869EC9196549F627F4A6]"
Feb 09 19:55:49 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:49.072638937-05:00" level=info msg="certificate CN=k3s,O=k3s signed by CN=k3s-server-ca@1612641497: notBefore=2021-02-06 19:58:17 +0000 UTC notAfter=2022-02-10 00:55:49 +0000 UTC"
Feb 09 19:55:49 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:49.075930185-05:00" level=info msg="Updating TLS secret for k3s-serving (count: 8): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=71E6018A05F0851D7B893FB1F8B8B83DFAAF848F]"
Feb 09 19:55:49 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:49.080154345-05:00" level=info msg="Active TLS secret k3s-serving (ver=108148601) (count 8): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=71E6018A05F0851D7B893FB1F8B8B83DFAAF848F]"
Feb 09 19:55:49 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:49.119200588-05:00" level=info msg="Active TLS secret k3s-serving (ver=108148602) (count 8): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=CBD53CE8401D1E09D2D8C50BFED40810D03E35C7]"
Feb 09 19:55:49 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:49.124302788-05:00" level=info msg="Active TLS secret k3s-serving (ver=108148603) (count 8): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=71E6018A05F0851D7B893FB1F8B8B83DFAAF848F]"
Feb 09 19:55:49 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:49.129007974-05:00" level=info msg="Active TLS secret k3s-serving (ver=108148604) (count 8): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=CBD53CE8401D1E09D2D8C50BFED40810D03E35C7]"
Feb 09 19:55:49 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:49.135130514-05:00" level=info msg="certificate CN=k3s,O=k3s signed by CN=k3s-server-ca@1612641497: notBefore=2021-02-06 19:58:17 +0000 UTC notAfter=2022-02-10 00:55:49 +0000 UTC"
Feb 09 19:55:49 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:49.137025026-05:00" level=info msg="Updating TLS secret for k3s-serving (count: 9): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=CD609826BFA62B9F651AC51AFE546E95C3D50562]"
Feb 09 19:55:49 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:49.140836592-05:00" level=info msg="Active TLS secret k3s-serving (ver=108148606) (count 9): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=CD609826BFA62B9F651AC51AFE546E95C3D50562]"
Feb 09 19:55:49 k3s-ya-1. k3s[4559]: time="2021-02-09T19:55:49.635968629-05:00" level=info msg="Active TLS secret k3s-serving (ver=108148621) (count 9): map[listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-kubernetes:kubernetes listener.cattle.io/cn-kubernetes.default:kubernetes.default listener.cattle.io/cn-kubernetes.default.svc.cluster.local:kubernetes.default.svc.cluster.local listener.cattle.io/cn-localhost:localhost listener.cattle.io/fingerprint:SHA1=A6D448BF0AD30679603D049B08676028C4CEB141]"

(BTW, I searched/replace to remove the domain from the hostnames+)
# k get nodes
NAME       STATUS   ROLES    AGE     VERSION
k3s-ya-1   Ready    master   5h34m   v1.19.7+k3s1

# kg -n kube-system
NAME                                     READY   STATUS             RESTARTS   AGE
coredns-66c464876b-24dh7                 0/1     Running            0          4m53s
helm-install-traefik-njn8m               0/1     CrashLoopBackOff   22         68m
local-path-provisioner-7ff9579c6-745hm   0/1     CrashLoopBackOff   5          4m53s
metrics-server-7b4f8b595-w6wsp           0/1     CrashLoopBackOff   5          4m52s

Damn.
Ok, so I then deleted all of the above matching manifests to end up here:
# kubectl get pods -n kube-system
No resources found in kube-system namespace.

And.
# kaf traefik.yaml
helmchart.helm.cattle.io/traefik created
# kubectl get pods -n kube-system
NAME                         READY   STATUS             RESTARTS   AGE
helm-install-traefik-279jm   0/1     CrashLoopBackOff   2          28s

Normally that's a completely harmless thing to do. The fact that it's worse after that suggests that there is some severe disagreement within the cluster about what CA certificates are trusted. I suspect that you had multiple nodes with different cluster CAs signing different certificates within the cluster. At this point I'm not sure it's worth the work to clean up.

Yup I'm going to call it. The only reason that I spun up k3s in the first place was to take a look at Rancher.  Now that Rancher can run on any k8s will spin up a bare-metal k8s cluster instead.   However, I'm also reconsidering that approach as well now.  Am more interested in stability from and SRE POV than a pretty face at this point.   Although the longhorn project is very appealing...
The bare-metal k8s cluster I setup a few years ago is still stable without any significant interventions/upgrades needed so far and it survives reboots hard or soft which is what seems to be the root cause of the issues in k3s.
@brandond your support and awesome responsiveness and to jump right in and help are hugely appreciated!

I had the same error message now after uninstalling and re-installing K3S. Turns out the problem was my ~/.kube/config was still referring to the old cluster. Delete that and then cp /etc/rancher/k3s/k3s.yaml ~/.kube/config to get the new context.

I had the same error message because I was port forwarding 443 to 6443 through firewalld. When Traefik was down it worked, once it started up it didn't.

I had the same error message now after uninstalling and re-installing K3S. Turns out the problem was my ~/.kube/config was still referring to the old cluster. Delete that and then cp /etc/rancher/k3s/k3s.yaml ~/.kube/config to get the new context.

And also consider this command:
cp /etc/rancher/rke2/rke2.yaml .kube/config
:)


fixed event routes on get controller , post controllers , tests

Before creating a pull request make sure that:

[ ] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[ ] tests have been updated / new tests has been added (if needed)
[ ] the keep-helm label has been added, if the helm release should be persisted after a successful build

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

Closing this PR. As the changes are done on seperate PR and merged to Base branch.


Release 5.0.0

Version 5.0.0
New features

Supports FlowConfig feature to set images to process / provide results
Provide version of module via 'OnNewStatusModuleVersion'
Function 'getParameters' to provide PersistentData parameters
Check if features of module can be used on device and provide this via 'OnNewStatusModuleIsActive' event / 'getStatusModuleActive' function
Function to 'resetModule' to default setup

Improvements

New UI design available (e.g. selectable via CSK_Module_PersistentData v4.1.0 or higher), see 'OnNewStatusCSKStyle'
check if instance exists if selected
check if models exist in selected folder
'loadParameters' returns its success
'sendParameters' can control if sent data should be saved directly by CSK_Module_PersistentData
Changed log level of some messages from 'info' to 'fine'
Sample images converted to JPG
Added UI icon and browser tab information

Bugfix

Never deregistered from events

Following tasks were checked

[x] Module is coded and structured according to the "Developing guideline for modules" described within the CSK documentation
[x] All functions/events/parameters are documented within the manifest documentation
[x] The manifest description of the main CROWN includes main information about the purpose of the module and how to use it in general
[x] API docu based on the manifest was created and stored within the "docu"-folder of the repository
[x] Internal LUA code documentation exists for variables and non served functions
[x] All relevant infos are logged via the SharedLogger 'ModuleLogger'
[x] Module supports persistent data feature based on 'CSK_Module_PersistentData'
[x] Module supports user management based on 'CSK_Module_UserManagement'
[x] No open "ToDos" within the code or at least clearly explained comments why they exist...
[x] "Version" key in app manifest was updated following semantic versioning (and use '0.x.y' for test / experimental modules which are not yet ready to be officially released)
[x] Meaningful IDs used for UI elements
[x] Module was tested on an AppSpace device (at least on SICK AppEngine) with no error message
[x] README.md is up to date (incl. info of device + firmware the module was tested with)
[x] CHANGELOG.md is up to date

Thx for the review!


xwayland: send focus change event unconditionally

This fixes issues with (at least) dialogs in Jetbrains IDEs becoming
unclickable if they ever lost focus (ref. swaywm/sway#5373). Prior to
this change, since xwm->focus_surface would be set prior to
xwm_surface_activate being called, the latter would short-circuit
immediately and not notify the application of the focus change.

This basically means we let X11 apps override each other's focus.
Why does the condition fail in this case? Is the PID different?

Hmm, I don't think that's what this does unless I misunderstood this completely...
The original code was:
	struct wlr_xwayland_surface *requested_focus = lookup_surface(xwm, ev->event);
	if (!xwm->focus_surface || !requested_focus ||
			requested_focus->pid != xwm->focus_surface->pid) {
		xwm_send_focus_window(xwm, xwm->focus_surface);
	} else {
		xwm->focus_surface = requested_focus;
	}

The if condition fails if the focus change shouldn't be allowed, in which case as per the comment, "Reset the focus to the old one if it changed."
The simplified fix for this issue is:
	struct wlr_xwayland_surface *requested_focus = lookup_surface(xwm, ev->event);
	if (!xwm->focus_surface || !requested_focus ||
			requested_focus->pid != xwm->focus_surface->pid) {
		xwm_send_focus_window(xwm, xwm->focus_surface);
	} else {
		xwm->focus_surface = requested_focus;
		xwm_send_focus_window(xwm, xwm->focus_surface);
	}

That is, adding a call to xwm_send_focus_window in the case we do allow the focus change. Then I just cleaned up the code by inverting the if condition and calling xwm_send_focus_window unconditionally.

Maybe xwm_surface_activate should be called for a successful request instead, so that also xwm_set_net_active_window is run?

Hmm, I don't think that's what this does unless I misunderstood this completely...

Eh, indeed, I completely missed the inverted condition.

Re: xwm_surface_activate, I also noticed the xwm_set_net_active_window difference (and calling it instead works fine, of course), but I don't know enough about X11 to know dialogs interact with NET_ACTIVE_WINDOW (if at all specially)... so I just left the existing logic as-is.
Is the expected behavior under "real" X11 that NET_ACTIVE_WINDOW changes?

Tried reading the i3 source code, but they re-send the whole state to the server in one go: https://github.com/i3/i3/blob/10646eb0021403c1f1448339603b24c50da0e604/src/handlers.c#L1054

In any case, if the handler needs to send more messages to the X11 server, it should be done in a separate patch.

Thanks!


Fix before/after_schedule hooks not called when enqueued with config

@iloveitaly hi there (I came across this after finding https://github.com/resque/resque-scheduler/issues/679)
I've got a scheduled job that needs to behave differently (not enqueue as configured, but kick off a separate variant of the job instead) depending on some runtime variables (eg. feature flag). The before_schedule hook seems to fit the bill, but doesn't work. These changes appear to fix it - I know it's been some time, but any chance this could move forward? Or should I address your requested changes on a separate PR?

@PatrickTulskie (seeing as this PR is quite out of date, wanted to get it back on the radar for consideration) 🙏

@codealchemy Happy to get this one merged in since it does seem like it fixes an actual bug. It would be nice to get this branch rebased with master so that CI runs for it. I can handle the changelog updates when I do a release. Also possible that given how old this is, the PR might have to be adjusted. If you want to open a fresh PR and take over work on it, then go for it.

Thanks @PatrickTulskie - I've rebased these changes and opened https://github.com/resque/resque-scheduler/pull/792, failing builds there appear unrelated to the changes (and the same as seen on master), but let me know if there's something I missed or you'd like to see addressed beforehand.

@codealchemy Yeah I've seen those failures too. Something about the test matrix here needs to get fixed I guess. I'll look at that and your PR and see what I can do to get a release done.

@PatrickTulskie please let me know if there's anything else I can do to help this along 🙇

@PatrickTulskie please let me know if there's anything else I can do to help this along 🙇

Will do. I'm currently neck deep in 2 different things that are taking up all of my time. I just went through and teed up this and a bunch of other things that need my review though and I'm hoping to get through them all in the next week or two when I have a little down time.

@jweir hey I'm prepping a new release for next week. Would you mind giving this a rebase? It's got some merge conflicts at the moment.

Closing. This will get handled here: https://github.com/resque/resque-scheduler/pull/792


storcon: handle ongoing deletions gracefully

Problem
Pageserver returns 409 (Conflict) if any of the shards are already deleting the timeline. This resulted in an error being propagated out of the HTTP handler and to the client. It's an expected scenario so we should handle it nicely.
This caused failures in test_storage_controller_smoke here.
Summary of Changes
Instead of returning an error on 409s, we now bubble the status code up and let the HTTP handler code retry until it gets a 404 or times out.
Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.
[ ] Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
[ ] If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

[ ] Do not forget to reformat commit message to not include the above checklist

5202 tests run: 4994 passed, 1 failed, 207 skipped (full report)
Failures on Postgres 15
* `test_timeline_delete_works_for_remote_smoke`: [release-arm64](https://neon-github-public-dev.s3.amazonaws.com/reports/pr-9449/11401638376/index.html#suites/f588e0a787c49e67b29490359c589fae/b458cd0a3f603d80)

# Run all failed tests locally:
scripts/pytest -vv -n $(nproc) -k "test_timeline_delete_works_for_remote_smoke[release-pg15]"

Flaky tests (2)
Test coverage report is not available
The comment gets automatically updated with the latest test results
a89e054 at 2024-10-18T10:46:32.432Z :recycle:

I looked into this. It's unrelated to the changes made here. That test doesn't delete through the storage controller.
The deletion genuinely took longer than 5 seconds due to what looks like an S3 transient error.


TrackerCSRT

Is there a plan for including TrackerCSRT?
https://docs.opencv.org/3.4/d2/da2/classcv_1_1TrackerCSRT.html
cc @shimat

Many thanks @shimat !


IOS - Assign task - Multiline description is displayed as one line

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Issue found when executing PR https://github.com/Expensify/App/pull/21371
Action Performed:

Login to NewDot iOS app
Assign a task with multi-line description
Task chat is displayed

Expected Result:
There should be indication, that description has additional lines except first one, which are not displayed until you expand it
Actual Result:
Multiline description is displayed as one line (there is no any indication that there are any more line except for the first one)
Only iOS. Android has "..." and web shows all description
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[x] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.34.
1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/78819774/189bd1c4-d486-44d5-ad94-dffa311aa61c
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

Proposal
Please re-state the problem that we are trying to solve in this issue.
Assign task - Multiline description is displayed as one line
What is the root cause of that problem?
Here we are using  MenuItemWithTopDescription component which is generally used for one-line or two-line headings that is why multiline descriptions are displayed as one line
What changes do you think we should make in order to solve the problem?
We should redesign our description text in src/components/TaskHeader.js and not change in MenuItemWithTopDescription as this component use many places
https://github.com/Expensify/App/blob/de9cec890a758938f309d281ad53a2ff76b1c4de/src/components/TaskHeader.js#L128-L135
change this with the below initial design
<PressableWithFeedback
                onPress={() => Navigation.navigate(ROUTES.getTaskReportDescriptionRoute(props.report.reportID))}
                disabled={!isOpen}
                accessibilityRole="button"
            >
                    <View style={[styles.ph5, styles.pb5]}>
                        <Text
                            style={[styles.pre, styles.textLabelSupporting]}
                        >
                           {props.translate('newTaskPage.description')}
                        </Text>
                        <Text
                            style={[styles.headerText, styles.pre]}
                        >
                           {lodashGet(props.report, 'description', '')}
                        </Text>
                    </View>
            </PressableWithFeedback>

 Result

Reproducible, triaging to external

@fedirjh we have a proposal above, could you take a look to see if we can move forward with it?

Agreed with @fedirjh

Sounds good, adding hold to title

Hi @fedirjh @sonialiap would you be able to confirm if this issue is a dupe of this one? (I think so?)
https://github.com/Expensify/App/issues/22453

Sounds good, closing


Instance Names when adding add multiple B2C instance

Please add to this document:
In section 5. On the Custom deployment page, enter the following information:
Msp Offer Name | A name describing this definition. For example, Azure AD B2C Monitoring. This is the name that will be displayed in Azure Lighthouse.
The MSP Offer Name needs to have a different/new name for each B2C instance added.
NOTE: If you are adding 2 or More B2C tenants to be monitored by the same AzureAD Tenant each MSP Offer name must be unique.
B2C Instance 1 : Azure AD B2C Monitoring 001(b2c domain or something to differentiate from others)
ex1: Azure AD B2C Monitoring 001
ex2: Azure AD B2C Monitoring myfirstb2cdomain.com
B2C Instance 2 : Azure AD B2C Monitoring 002(b2c domain or something to differentiate from others)
ex1: Azure AD B2C Monitoring 002
ex2: Azure AD B2C Monitoring mysecondb2cdomain.com
B2C Instance N: Azure AD B2C Monitoring N (b2c domain or something to differentiate from others)
ex1: Azure AD B2C Monitoring N
ex2: Azure AD B2C Monitoring myNthb2cdomain.com
Using/Reusing the same MSP Name will result in a failured deployment of the ARM template :
(ex: failure)
Error result:
{
'status': 'Failed',
'error': {
'code': 'RegistrationDefinitionInvalidUpdate',
'message': 'The registration definition 'GUID' property ManagedByTenantId not allowed to update.'
}
}
Additionally, the first paragraph it is stating that Owner permissions are needed.
I was able to help a customer which had GA AAD Permissions but only Contributor over the subscription where the lighthouse resource group was located and no permissions in the B2C tenant (we added them afterwards)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 24e34c89-9a70-b5b2-3b38-bc81660f83c1
Version Independent ID: 77fa8d3c-56dd-294f-13ae-ac6ba44018a7
Content: Monitor Azure AD B2C with Azure Monitor - Azure AD B2C
Content Source: articles/active-directory-b2c/azure-monitor.md
Service: active-directory
Sub-service: b2c
GitHub Login: @kengaderdus
Microsoft Alias: kengaderdus

@debaxtermsft
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.


location of downstream hab cons sites should be downstream end of survey

digital fieldform gives us the start of the survey.  Future methods should include moving site point to end of survey if travelling in downstream direction.
could use basecamp, make points with same IDs at the bottom end of the tracks (so work can be saved), copy paste UTMs from basecamp into the spreadsheet.

Closed via this PR.


perf(v2): reduce memory usage consumption

Motivation
Hopefully this is the last perf optimization this month that i did before working on versioning plugin.
With this PR, docusaurus should be able to handle at least > 1,000 markdown files without memory allocation error (tested)
Anyway, this PR is very simple, upgrading static site generator webpack plugin to use my forked version https://github.com/endiliey/static-site-generator-webpack-plugin with improved test coverage (100% compared to original 90%+) and more up to date dependencies + performance. I can optimize more using jest-worker but thats kinda overkill now.
Have you read the Contributing Guidelines on pull requests?
yes
Test Plan
Chrome dev tool + Nodejs debugger
Before

After

Comparison
upload images

maybe not now. cos my change dropped webpack 1-3 support and nodejs <= 8 🤣. Anyway nodejs 8 is approaching EOL on Dev 19, we shall prepare for updating all node version requirement > 10 soon


Feature Request : Firebase 'Functions' Compatibility and/or Observing changes to geofirestore docs

Hey Michael,
This is a bit of a two-headed question with the same goal : Do you plan on geofirestore updating its query results as document content is updated?
e.g.  case:
on the backend, firebase 'functions' does some data manipulation to be updated on one to many geofirestore docs.  In my client app, I want geofirestore to be able to see those updates as they occur and bring them in to the existing query results.
Obviously, this can be done with a redundant Observable of the geofirestore collection...
Another thought I had was doing a .setWithDocument() anytime firebase 'functions' needs to update the content.  (Would geofirestore see this as a change?)  This would seem a little more in-line with your project.
If this latter were the case, the challenge I have is in implementing geofirestore inside of 'functions'.
Unfortunately, while the constructor for geofirestore requires type "firebase.firestore.CollectionReference", firebase-admin's collection type "FirebaseFirestore.CollectionReference"  isn't compatible with the constructor, nor does it seem it can be cast to the desired type...
This is getting a bit outside my knowledge-base : could an alternative constructor with the other type be easily integrated?  Or do you have a thought that I could try in a fork?
Anyway, this is very much spit-balling.  If I can clarify, or if this is getting way outside geofirestore's scope, shout!
Thanks.

So I may not have a clear grasp on your question, but let me answer where I plan on taking geofirestore and you can tell me if that answered your question (I think it will).
As it stands right now geofirestore sort of serves as an index to make geoqueries on, and provides the key of the document you want (which would be stored in a separate collection). While you do now have the option to store the document in geofirestore, it is not replicated by updates to the original document (if there is one). So while geofirestore does use the onSnapshot to listen for changes to documents, it listens to changes in IT'S collection, not the one it is indexing.
In version 2.x.x however, geofirestore will not be an index to a separate collection, it will be the entry point TO the collection. Effectively 2.x.x will wrap every document in a hash as well as the coordinates, and while you could do straight queries on the collection (all your data will be in a field called d, for document). That way going forward geofirestore is not just indexing the data, but managing it. I think it's the best way to go moving forward, and will complete the goal of making geoqueries feel more natural with Firestore. (I just need to implement code for adding new documents, update the docs, and possibly look at supporting more complex queries than just on location...)

Got it.  Yeah, I wasn't clear : I'm using your 1.2.0 which does have the .d object in which I'm placing all my data, so, yes, I'm already going down the route you're describing.
So then, making sure I'm understanding the 2.x vision : you're then looking at extending how geofirestore handles ".d", so that it serves as an entry point to all the data under the 'geofirestore' collection, which would include facilities to query and observe updates to the .d contents.
If I'm repeating you correctly : then, yeah, that's what I'm asking : )
... and whether you could add supporting firebase's cloud functions to 2.x

Soooo yes, I think we're on the same page.... However! Theoretically you should be able to use this already in cloud functions. Now there can be issues (see #5 ) however that is the nature of the package, because we use onSnapshot the queries stay active.... I am yet to see a better solution ATM...

:D Yeah, I think we're talking the same thing re : 2.x.  (Do you have a wild-guess on a timeline?)
re : Firebase Cloud Functions - - I was actually having trouble instantiating geofirestore (type mismatch passing a firebase-admin collection to the geofirestore constructor which expects firebase.firestore.collection).  Anyway, I'll double check my code.  I must be doing something funky.
Thanks for the quick replies.

So, I'm cool in Cloud Functions.  My mistake.
I was thinking if I updated the geofirestore record via .setWithDocument, maybe it would trigger a new key_entered the query, not so... : )   Again, I know I'm stretching the scope a bit... if I wanted to nudge geofirestore to bring in the updated .document (e.g. the key is created, it has entered the query results, and then some process updates a value inside the .d object), what options would I have (nudge the location the smallest fraction of a degree? :)
Thanks.

Hey, @invention7 , I'm having the exact same problem running GeoFirestore in Cloud Functions. Can you expose what the solution was for you?

@invention7 i've been digging through code, I'll have better answers in the coming weeks, but i have a bigger focus atm to expand the ability to query firestore. I'll hopefully be able to get back to this soon.

Hey @invention7 so I was a little too busy to hit on this right away, but I've been thinking as to how/should I implement a feature like this... What will likely happen is I'll create a new on event, probably called key_changed so you can listen to changes to documents that are in your query. I mean I'm receiving that information, so I may as well do something with it. However IF I do do that, I will only emit values that are in the current query... If by the changing of the document the key_exited and key_moved events would be triggered, then we would not trigger key_changed (or maybe I'll call it key_modified...)

Hey @MichaelSolati,  Yeah!  That sounds perfect : clean and simple.

Hey invention7, did you finally manage to get this working with Functions? I have the same casting problem, and I'm kind of lost here.

Hey @stubborncoder, yeah, I was new to cloud functions and thought I had to use the firebase-functions library; you can create a function with the defacto 'firebase' library and your collectionRef just as if it were a client app.
e.g.
import * as firebase from 'firebase';
// define your firebaseConfig object
firebase.initializeApp(firebaseConfig);
const collectionRef = firebase.firestore().collection('geofirestore');
const geoFirestore = new GeoFirestore(collectionRef);
If you want to kick this around some more, let's create a separate issue from this 'enhancement' thread.

@invention7 if you want to throw it into a separate error, I would appreciate that. (I'll be closing this hopefully early next week...)

Suite, Michael!  I'm excited to see.
I think @stubborncoder and I are done with our sidebar.
David, if you need to continue, we'll start a new issue.
Seth

Yes thanx tío nota!
El vie., 15 jun. 2018 23:35, Seth Hunter Perkins<EMAIL_ADDRESS>escribió:

Suite, Michael! I'm excited to see.
I think @stubborncoder https://github.com/stubborncoder and I are done
with our sidebar.
David, if you need to continue, we'll start a new issue.
Seth
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MichaelSolati/geofirestore/issues/7#issuecomment-397748371,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALL0ekyu61Yjcxm8VaVAAOjTkRyBHVhyks5t9CipgaJpZM4UTzP2
.

@invention7 I think (after exhausting my query limits on the spark tier running and writing tests), that i have the key_modified feature implemented. The docs have been (somewhat) updated (in the dev branch) to reflect that => https://github.com/MichaelSolati/geofirestore/tree/dev#geofirestorequeryoneventtype-callback (I say it exists, I didn't give an example... I'm open to PRs!!)
Anyway, version 2.0.0 will have a lot of changes under the hood, where I'd recommend reading the docs in the README. I also plan on writing a sample application so people can see how to use it.
If you want to try 2.0.0 right now, go for it! you can use it by npm install geofirestore@next
I'll close this after I build the demo app, confirm everything works as expected, and release 2.0.0 properly.

WOOOOOOOOOOOO!!!!!     I'll check it out today and get back.  Thanks for the update!

@MichaelSolati, I'll get back as I work with 2.0 some more, but on first blush : this is EXCELLENT!  I've got the cloud functions I mentioned earlier making changes to the 'document', and those updates are flowing nicely to my client app under 'key_modified'.  This is great!  I also like the cleanup and consolidation of the methods (e.g. just 'set' vs 'set'/'setWithDocument'), standardizing on GeoPoint, etc   Simplified and versatile!  This is excellent!

Launched v2 properly, so I'm closing this issue! (Enjoy)


adding av1 encoding to bitmovin provider

WIP

Alright, this seems to all work.

That's a good idea.  Will do.

https://github.com/cbsinteractive/video-transcoding-api/pull/142


Release notes generator crashes if no production tags exist

Our CumulusCI builds have been failing recently during the release notes generation. The script crashes while getting the last tag because no last (production) tag exists.
The _get_last_tag() method in provider.py should be updated to handle the possibility that no production tags exist.

In that case, we should include any PR's that were merged before the current tag.


[BUG] Upgrade vendor/k8s.io/client-go/tools/leaderelection makes longhorn-manager can't start

Describe the bug
Upgrade vendor/k8s.io/client-go/tools/leaderelection makes longhorn-manager can't start.
To Reproduce

Bump Upgrade vendor/k8s.io/client-go/tools/leaderelection makes longhorn-manager
Deploy the new longhorn-manager container image

Expected behavior
Longhorn manager starts succesfully.
Log
2021/07/30 06:53:11 proto: duplicate proto type registered: VersionResponse
time="2021-07-30T06:53:11Z" level=info msg="Start overwriting built-in settings with customized values"
W0730 06:53:11.876401       1 client_config.go:541] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
time="2021-07-30T06:53:11Z" level=info msg="cannot list the content of the src directory /var/lib/rancher/longhorn/engine-binaries for the copy, will do nothing: Failed to execute: nsenter [--mount=/host/proc/1/ns/mnt --net=/host/proc/1/ns/net bash -c ls /var/lib/rancher/longhorn/engine-binaries/*], output , stderr, ls: cannot access '/var/lib/rancher/longhorn/engine-binaries/*': No such file or directory\n, error exit status 2"
I0730 06:53:11.890183       1 leaderelection.go:241] attempting to acquire leader lease  longhorn-system/longhorn-manager-upgrade-lock...


Mac_x64 queue time jumps above SLO 10mins for the past two weeks

The queue time for Mac_x64 over the past month:

Date
05/08-05/21
05/22-06/04

75th% queue time (mins)
0.95
2.1

90th% queue time (mins)
8.22
21.85 (SLO: 10)

99th% queue time (mins)
43.52
37.13

Though over the past two weeks, there was an improvement to mitigate the queue time on this platform: https://github.com/flutter/flutter/pull/127230, which removes x64 restriction for 8 Mac targets. We expect the number drops with this mitigation...
Something is going wrong.

And the bot usage is similar too...

Excluding 05/22 brings the queue time back to 8 mins! Considering the queue time of 05/22 itself, it was 35min.
Seems https://github.com/flutter/flutter/issues/127336 is the culprit.

As the queue time is consistent with earlier period excluding the bias on 05/22, I am closing this bug.


[virt-controller]Fix bug by checking if PVC is nil

Fix bug by checking if PVC is nil instead of checking for an empty name
The real risk is the PVC being nil, which can lead to a panic in virt-controller.

What this PR does
Before this PR:
After this PR:

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

NONE

Good Catch, Thank you!
/lgtm

I am not sure how this is physically possible, the control loop should error out much sooner
https://github.com/kubevirt/kubevirt/blob/7329ba1f3898593e34a7465e222cf11f383dfee8/pkg/virt-controller/watch/vmi/vmi.go#L1004-L1007

Well, I know it is a low-probability scenario, but what if the PVC was removed by the time we get to RenderLaunchManifestNoVM? We should handle this edge case.
Anyway, I think we should align this check with the RenderLaunchManifest function.

I am not sure how this is physically possible, the control loop should error out much sooner
https://github.com/kubevirt/kubevirt/blob/7329ba1f3898593e34a7465e222cf11f383dfee8/pkg/virt-controller/watch/vmi/vmi.go#L1004-L1007

Well, I know it is a low-probability scenario, but what if the PVC was removed by the time we get to RenderLaunchManifestNoVM? We should handle this edge case. Anyway, I think we should align this check with the RenderLaunchManifest function.

I don't think this is possible with a cached client? @jean-edouard maybe related to that cache corruption commit?

/lgtm
@mhenriks should we consider dropping the entire wffc dummy pod code path or do we want to keep supporting non CSI?

@mhenriks should we consider dropping the entire wffc dummy pod code path or do we want to keep supporting non CSI?

Still need it, some storage vendors cannot work with populators yet


Adding In-Memory cache support for CosmosDB

Why make this change?
Adding In-Memory cache support for CosmosDB. Closes #1884
What is this change?
Introduced a new generic method GetOrSetAsync  for getting and setting cached item.
Using GetOrSetAsync for caching Cosmosdb query result.
How was this tested?

[x] Integration Tests
Added integration tests using Mock Func execution by DabCacheService.GetOrSetAsync.
Performed manual testing of caching behavior. Had to manually override enablecaching and TTL since config changes were not throwing an error. Will perform another round of tests by enabling caching from configuration before merging the PR.

There are some changes i need to cherry pick from 0.10 release branch to fix this behavior:

Had to manually override enablecaching and TTL since config changes were not throwing an error.

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run

/azp run


Validate Rancher Garbage Collection Manager

Test Plan containing P1 workflow for Rancher Garbage Collection Manager -
ImageGCTests.xlsx

LGTM

Image clean up for images used by containers that are flapping  when IMAGE_GC_HIGH_THRESHOLD  is reached won't work. Current solution only guarantees that the image will be deleted at last. Because it is flapping, there is still possible that the image is not used by container and it is also detected by GC at the same time.

Added 2 more cases relating to docker being installed in mounted volumes ( Test case # 13 and 14)
ImageGCTests.xlsx

7. Delete service S1 . Wait for 2 mts. Delete Service S2.  Wait for 2 mts. Delete service S3 . Wait for 2 mts. Delete Service S4.
you may need to wait longer between deleting images. The default routine interval is 5 minutes. So the images are scanned every 5 minutes by default.

Initial validation was done. 2 issues:

https://github.com/rancher/rancher/issues/8802
https://github.com/rancher/rancher/issues/8828


[WIP] Basic interfaces as vanilla React components

This PR sets up the sorting task plugin using a single Slate.js void block that renders a vanilla React component. Void blocks aren’t editable by users. While we do want to our users to be able to edit the terms etc. of the sorting task, the freeform interface that Slate.js provides isn’t the best way to do so. Instead, a classic user interface composed of several separate elemnts like inputs, buttons etc. is enough as the data we need to collect is highly structured.
Details

Clicking the respective button in the plus menu adds a Slate.js block of type sortingTask
sortingTask blocks are rendered by the SortingTaskNode React component. This component itself doesn’t render any user interface.
SortingTaskNode manages the block’s local state, in particular the list of terms. Also, it makes sure to save the state in the Slate.js document tree. While the component state isn’t persisted, the document tree is.
SortingTaskNode renders either the EditView or the ReadView component, depending on the isReadOnly property. These two components render the actual user interface.
EditableTerms renders a table with inputs for each term. In order to allow users to add new terms, an empty row is appended at the end.

Problems

Clicking on a void block (or any element inside of it) focuses the block itself. By default, this makes it impossible to focus input elements inside of a void block. I’ve fixed this by catching any click events inside the SortingTaskNode component and stopping the from propagating. This way, Slate won’t »notice« the click event. However, there seem to be cases where this doesn’t work.
Technically, when any of the inputs inside of SortingTaskNode is focused, Slate considers the editor blurred, as it does not recognize the input elements as a part of the editor. Currently, this has no major effects. There’s a similar example from the Slate.js documentation, that has the same problem, so I’m not sure if there’s a simple solution to this problem.
I’ve added a fix that hides the plus menu if the editor is blurred or if a void block is focused. However, I think this should be PR’ed directly to the main repo instead.

Naming
I think we should try to find better names for these entities:
Term, a tuple of a term and a description.

Someone suggested Question, however that’s not a perfect fit, I think.
Card is dependent on the presentation, making it a bad name.
General names like Item work in most situations, however, I think it’d be better to have a more concrete name.

TermsList, EditableTerms, EditableTermsItem should be renamed to match the new name of Term.

A suggestion for an improved designation of Term: In my view, LearningItem would describe it better as it is more concrete than Item, it is not dependent on the presentation and it is understandable what is meant.
The only disadvantage could be that it would be too long if we had EditableLearningItem, for example.

What do you think about a structure like this?


Debug Console log stops working after a few lines and formatting is messed up

Issue Type: Bug
My Vscode Debug Console output is completely messed up. When I run my app it does show several console outputs (which used to be correctly formatted/colored before, now starting with prefixes like [0m) then hangs there any doesn't display any more console output. Also, when expanding logged objects, I get various "middle steps" to expand like arg1 which weren't there before. Here is a screenshot of the messed up output (nothing else is printed afterwards, this is the end of the output):

I also can't try without extensions disabled because then I can't start my app within Vscode. This problem is occuring only on Vscode debugger and there's no issue if I use e.g. standalone React Native Debugger. This happens persistently every time I debug my app and stays the same even if I stop the debug session. When I start a new debug session, nothing changes (output isn't cleared and stays as in the screenshot). When I click Clear Console button on Vscode nothing happens (the output is NOT cleared). The only way to clear is to restart/reload Vscode window. I've also observed that the crash happens when I log many objects (e.g. using redux-logger) into the console and doesn't occur if I disable redux-logger. Though the "bad formatting with arg1" is still there. I don't think the issue is caused by redux-logger but Vscode itself because the debug console stays hung up even after I finish my debug session and clear button etc. doesn't work.
VS Code version: Code 1.54.3 (2b9aebd5354a3629c3aba0a5f5df49f43d6689f8, 2021-03-15T11:57:12.728Z)
OS version: Darwin x64 20.3.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz (16 x 2400)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 2

Memory (System)
64.00GB (35.08GB free)

Process Argv
--crash-reporter-id 61520765-68a9-4877-bb92-92fa245a771b

Screen Reader
no

VM
0%

Extensions (11)

Extension
Author (truncated)
Version

mustache
daw
1.1.1

vscode-npm-script
eg2
0.3.18

spark-ar-studio
fac
1.1.0

vscode-graphql
Gra
0.3.15

customize-ui
ioc
0.1.51

monkey-patch
ioc
0.1.12

vscode-language-babel
mgm
0.0.30

debugger-for-chrome
msj
4.12.12

vscode-react-native
msj
1.4.1

color-highlight
nau
2.3.0

vetur
oct
0.33.1

(1 theme extensions excluded)

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383:30185418
pythonvspyt700cf:30270857
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstry244:30276681
pythonvsdeb440:30248342
pythonvsded773:30248341
pythonvspyt875:30259475
pythonvspyt639:30281910
pythontbcf:30265426
openwsldoc:30282072
vspre833:30267464
pythonptprofiler:30281270
vshan820cf:30276953

Thanks for filling this issue. Can you reproduce using Visual Studio Code Insiders https://code.visualstudio.com/insiders/
If you can, can you create a repository on GitHub which reproduces this issue? So I can simply clone it and investigate further on my machine?

@isidorn I've just downloaded the latest insiders build. I confirm that it occurs also on the Insiders build.

If you can, can you create a repository on GitHub which reproduces this issue? So I can simply clone it and investigate further on my machine?

I will try to but it might take some time.

Great, thanks!

I have the same issue.
It is unusable.
Any help?


docker: podman-friendly image locations

Adds fully qualified canonical locations of container images, making the container technology setup podman-friendly.
Amends cluster creation scripts to support either Docker or Podman container technologies based on docker version information.
Closes reanahub/reana#729.

Codecov Report

Merging #730 (7f5670b) into master (6f86e14) will decrease coverage by 0.04%.
The diff coverage is 0.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files

@@            Coverage Diff             @@
##           master     #730      +/-   ##
==========================================
- Coverage   18.90%   18.87%   -0.04%
==========================================
  Files          26       26
  Lines        2195     2199       +4
==========================================
  Hits          415      415
- Misses       1780     1784       +4

Impacted Files
Coverage Δ

reana/config.py
100.00% <ø> (ø)

reana/reana_dev/cluster.py
0.00% <0.00%> (ø)

reana/reana_dev/docker.py
0.00% <0.00%> (ø)

reana/reana_dev/kind.py
0.00% <0.00%> (ø)

The 34 PR set is finished and the tests are passing with Podman:
$ reana-dev run-ci -m /var/reana:/var/reana -c r-d-r-roofit --admin-email xxx --admin-password yyy

...

$ reana-dev run-example -c DEMO --submit-only

...

$ reana-dev run-example -c DEMO --check-only
...
Test matrix:
  - 9 demo example(s): reana-demo-alice-lego-train-test-run, reana-demo-alice-pt-analysis, reana-demo-atlas-recast, reana-demo-bsm-search, reana-demo-cms-dimuon-mass-spectrum, reana-demo-cms-h4l, reana-demo-helloworld, reana-demo-root6-roofit, reana-demo-worldpopulation
  - 4 workflow engine(s): cwl, serial, snakemake, yadage
  - 1 compute backend(s): kubernetes

Test results:
  - 18 submitted: alice-lego-train-test-run-serial-kubernetes, alice-pt-analysis-serial-kubernetes, atlas-recast-yadage-kubernetes, bsm-search-yadage-kubernetes, cms-dimuon-mass-spectrum-serial-kubernetes, cms-h4l-snakemake-kubernetes, helloworld-cwl-kubernetes, helloworld-serial-kubernetes, helloworld-snakemake-kubernetes, helloworld-yadage-kubernetes, root6-roofit-cwl-kubernetes, root6-roofit-serial-kubernetes, root6-roofit-snakemake-kubernetes, root6-roofit-yadage-kubernetes, worldpopulation-cwl-kubernetes, worldpopulation-serial-kubernetes, worldpopulation-snakemake-kubernetes, worldpopulation-yadage-kubernetes
  - 0 running
  - 0 pending
  - 0 queued
  - 18 passed
  - 0 failed

OK

Going to test with Docker later this evening...


Add scripts for 2.5 vs 2.3 runtime and memory usage experiments to research-experiments repo

Follow up to #9433
We should add the script used for 9433 as well as any other notes or tools to the research-experiments repo.
Definition of Done

[  ] script and documentation is added to the repo such that someone else could use them to replicate the experiments in 9433

In case anyone's wondering: I've assigned this issue to me since I'm the one who needs to document the steps and it's my script :)


Avoid beeping on every keydown.

Assuming it is unintentional. :)

This seems new, thanks for the fix!


chore: update cfnspec from source

Updates CFN spec from source.
Source spec now fixes the VpcEndpointType case error: https://github.com/awslabs/aws-cdk/issues/765
Fixes https://github.com/awslabs/aws-cdk/issues/1388

Pull Request Checklist

[ ] Testing

Unit test added (prefer not to modify an existing test, otherwise, it's probably a breaking change)
CLI change?: coordinate update of integration tests with team
cdk-init template change?: coordinated update of integration tests with team

[ ] Docs

jsdocs: All public APIs documented
README: README and/or documentation topic updated

[ ] Title and Description

Change type: title prefixed with fix, feat will appear in changelog
Title: use lower-case and doesn't end with a period
Breaking?: last paragraph: "BREAKING CHANGE: <describe what changed + link for details>"
Issues: Indicate issues fixed via: "Fixes #xxx" or "Closes #xxx"

[ ] Sensitive Modules (requires 2 PR approvers)

IAM Policy Document (in @aws-cdk/aws-iam)
EC2 Security Groups and ACLs (in @aws-cdk/aws-ec2)
Grant APIs (only if not based on official documentation with a reference)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

Should this be chore or fix(cfnpec)?

@sam-goodwin - chore: is appropriate, I think. Could also be feat I reckon, had there are actually been new features in there.