text:
Windows worker registration wrong vni

Rancher version: 2.3.5
Platform: Amazon AWS
OS: Control Plane and Etcd + 1 worker - RHEL 7.7
Windows workers - Windows Sever 2019 DataCenter - 1809 (Build 17763.973)
What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):
Run the registration command provided from the Rancher UI for a WIndows worker node
PowerShell -NoLogo -NonInteractive -Command "& {docker run -v c:/:c:/host -e AGENT_IMAGE=818213630802.dkr.ecr.eu-west-1.amazonaws.com/rancher/rancher-agent:v2.3.5 818213630802.dkr.ecr.eu-west-1.amazonaws.com/rancher/rancher-agent:v2.3.5 bootstrap --server https://pt02.containers.aws-euw1-np.avivacloud.com --token nxc5hkck6spgs5rbw9g4p7vjrqtdcz86qpps9hhzkmdkvrfwsc65gv --worker | iex}"
Result:
In the UI the Node is shown as registered. However the cattle-node-agent pad fails (as does the exportner-node-windows-cluster-monitoring workload).
The service-sidekick and kube-proxy container continuously restart

PS C:\Aviva\Scripts\rancher> PowerShell -NoLogo -NonInteractive -Command "& {docker run -v c:/:c:/host -e AGENT_IMAGE=818213630802.dkr.ecr.eu-west-1.amazonaws.com/rancher/rancher-agent:v2.3.5 818213630802.dkr.ecr.eu-west-1.amazonaws.com/rancher/rancher-agent:v2.3.5 boots
trap --server https://pt02.containers.aws-euw1-np.avivacloud.com --token nxc5hkck6spgs5rbw9g4p7vjrqtdcz86qpps9hhzkmdkvrfwsc65gv --worker | iex}"
INFO: Detecting running permission ...
INFO: Detecting host CPU reservation ...
INFO: Detecting host RAM reservation ...
INFO: Detecting host DISK reservation ...
INFO: Detecting host Docker name pipe existing ...
INFO: Detecting host Docker release version ...
INFO: Detecting host network interface ...
INFO: Configuring host Docker startup mode to automatical ...
INFO: Enabling host msiscsi service to support iscsi storage ...
895e39e9f7e4610dfda46e3c01e37930a0c065bb0d66fa6b06652a7c4075fdef
PS C:\Aviva\Scripts\rancher> docker container ls
CONTAINER ID        IMAGE                                                                       COMMAND                  CREATED             STATUS              PORTS               NAMES
895e39e9f7e4        818213630802.dkr.ecr.eu-west-1.amazonaws.com/rancher/rancher-agent:v2.3.5   "pwsh -NoLogo -NonIn…"   11 seconds ago      Up 9 seconds                            priceless_montalcini
PS C:\Aviva\Scripts\rancher> docker container ls
CONTAINER ID        IMAGE                                                                             COMMAND                  CREATED             STATUS              PORTS               NAMES
1869735c1c12        818213630802.dkr.ecr.eu-west-1.amazonaws.com/rancher/rke-tools:v0.1.52            "pwsh -NoLogo -NonIn…"   7 seconds ago       Up 6 seconds                            nginx-proxy
325f01213948        818213630802.dkr.ecr.eu-west-1.amazonaws.com/rancher/hyperkube:v1.17.2-rancher1   "pwsh -NoLogo -NonIn…"   10 seconds ago      Up 10 seconds                           kubelet
d1689ca2eb8c        818213630802.dkr.ecr.eu-west-1.amazonaws.com/rancher/hyperkube:v1.17.2-rancher1   "pwsh -NoLogo -NonIn…"   15 seconds ago      Up 14 seconds                           kube-proxy
4310c656feb0        818213630802.dkr.ecr.eu-west-1.amazonaws.com/rancher/rke-tools:v0.1.52            "pwsh -NoLogo -NonIn…"   19 seconds ago      Up 18 seconds                           service-sidekick
895e39e9f7e4        818213630802.dkr.ecr.eu-west-1.amazonaws.com/rancher/rancher-agent:v2.3.5         "pwsh -NoLogo -NonIn…"   33 seconds ago      Up 32 seconds                           priceless_montalcini

Other details that may be helpful:
Using flannel in VXLAN mode.
Contents of C:\etc\kube-flannel\net-conf.json
{"Backend":{"Name":"vxlan0","VNI":1,"Port":4789,"Type":"vxlan"},"Network":"10.42.0.0/16"}
Examining the service-sidecar logs it can be seen that the VNI value is incorrect for Windows (it has a value of 1 instead of 4096+) ...
Error registering network: invalid VXLAN backend config. VNI [1] must be greater than or equal to 4096 on Windows
{"log":"INFO: Copying kubelet volume plugins ...          \n","stream":"stdout","time":"2020-04-10T23:31:19.6245225Z"}
{"log":"INFO: Copying running binaries ...                \n","stream":"stdout","time":"2020-04-10T23:31:19.7642097Z"}
{"log":"INFO: Copying running scripts ...                 \n","stream":"stdout","time":"2020-04-10T23:31:19.8134949Z"}
{"log":"INFO: Start flanneld with: --kubeconfig-file=c:\\etc\\kubernetes\\ssl\\kubecfg-kube-node.yaml --ip-masq --kube-subnet-mgr --iptables-forward-rules=false --iface=10.63.131.171\n","stream":"stdout","time":"2020-04-10T23:31:20.2524851Z"}
{"log":"I0411 00:31:24.220150    9096 main.go:454] Searching for interface using 10.63.131.171\n","stream":"stderr","time":"2020-04-10T23:31:24.2211194Z"}
{"log":"I0411 00:31:24.232829    9096 main.go:531] Using interface with name Ethernet 3 and address 10.63.131.171\n","stream":"stderr","time":"2020-04-10T23:31:24.233806Z"}
{"log":"I0411 00:31:24.232829    9096 main.go:548] Defaulting external address to interface address (10.63.131.171)\n","stream":"stderr","time":"2020-04-10T23:31:24.233806Z"}
{"log":"I0411 00:31:24.247454    9096 kube.go:119] Waiting 10m0s for node controller to sync\n","stream":"stderr","time":"2020-04-10T23:31:24.2474542Z"}
{"log":"I0411 00:31:24.247454    9096 kube.go:306] Starting kube subnet manager\n","stream":"stderr","time":"2020-04-10T23:31:24.2474542Z"}
{"log":"E0411 00:31:25.260253    9096 reflector.go:201] github.com/coreos/flannel/subnet/kube/kube.go:307: Failed to list *v1.Node: Get https://127.0.0.1:6443/api/v1/nodes?resourceVersion=0: dial tcp 127.0.0.1:6443: connectex: No connection could be made because the target machine actively refused it.\n","stream":"stderr","time":"2020-04-10T23:31:25.261274Z"}
{"log":"E0411 00:31:27.282153    9096 reflector.go:201] github.com/coreos/flannel/subnet/kube/kube.go:307: Failed to list *v1.Node: Get https://127.0.0.1:6443/api/v1/nodes?resourceVersion=0: dial tcp 127.0.0.1:6443: connectex: No connection could be made because the target machine actively refused it.\n","stream":"stderr","time":"2020-04-10T23:31:27.2828624Z"}
{"log":"E0411 00:31:29.297816    9096 reflector.go:201] github.com/coreos/flannel/subnet/kube/kube.go:307: Failed to list *v1.Node: Get https://127.0.0.1:6443/api/v1/nodes?resourceVersion=0: dial tcp 127.0.0.1:6443: connectex: No connection could be made because the target machine actively refused it.\n","stream":"stderr","time":"2020-04-10T23:31:29.2978167Z"}
{"log":"I0411 00:31:32.256789    9096 kube.go:126] Node controller sync successful\n","stream":"stderr","time":"2020-04-10T23:31:32.2580217Z"}
{"log":"I0411 00:31:32.256789    9096 main.go:246] Created subnet manager: Kubernetes Subnet Manager - ec2amaz-brmldvj\n","stream":"stderr","time":"2020-04-10T23:31:32.2580217Z"}
{"log":"I0411 00:31:32.256789    9096 main.go:249] Installing signal handlers\n","stream":"stderr","time":"2020-04-10T23:31:32.2580217Z"}
{"log":"I0411 00:31:32.256789    9096 main.go:390] Found network config - Backend type: vxlan\n","stream":"stderr","time":"2020-04-10T23:31:32.2580217Z"}
{"log":"E0411 00:31:32.257539    9096 main.go:291] Error registering network: invalid VXLAN backend config. VNI [1] must be greater than or equal to 4096 on Windows\n","stream":"stderr","time":"2020-04-10T23:31:32.2580217Z"}
{"log":"I0411 00:31:32.258021    9096 main.go:370] Stopping shutdownHandler...\n","stream":"stderr","time":"2020-04-10T23:31:32.2580217Z"}
...

This also shows in the kublet container log because the /run/flannel/subnet.env does not get created :
... network: open /run/flannel/subnet.env: The system cannot find the path specified
{"log":"E0411 00:31:44.554643    7612 cni.go:364] Error adding cattle-system_cattle-node-agent-windows-42q5q/bf20fc45a6fb476f5a13384b30d7e258dff534b71810472e56ebba7b755bc54d to network flannel/vxlan0: open /run/flannel/subnet.env: The system cannot find the path specified.\n","stream":"stderr","time":"2020-04-10T23:31:44.5605365Z"}
{"log":"E0411 00:31:44.923521    7612 remote_runtime.go:105] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = failed to set up sandbox container \"bf20fc45a6fb476f5a13384b30d7e258dff534b71810472e56ebba7b755bc54d\" network for pod \"cattle-node-agent-windows-42q5q\": networkPlugin cni failed to set up pod \"cattle-node-agent-windows-42q5q_cattle-system\" network: open /run/flannel/subnet.env: The system cannot find the path specified.\n","stream":"stderr","time":"2020-04-10T23:31:44.9245014Z"}

and the kube-proxy container log:
{"log":"INFO: Waiting for servcie-sidekick to prepare the entrypoint.ps1 ...\n","stream":"stdout","time":"2020-04-10T23:31:23.9036935Z"}
{"log":"FATA: Could not get vxlan0 HNS network: \u001b[31mFATA\u001b[0m[2020-04-11T00:31:37+01:00] rpc error: code = InvalidArgument desc = could not get HNS network vxlan0 via v2 api: Network Id  not found \n","stream":"stdout","time":"2020-04-10T23:31:37.9409222Z"}
{"log":"INFO: Waiting for servcie-sidekick to prepare the entrypoint.ps1 ...\n","stream":"stdout","time":"2020-04-10T23:31:41.3741949Z"}
{"log":"FATA: Could not get vxlan0 HNS network: \u001b[31mFATA\u001b[0m[2020-04-11T00:31:54+01:00] rpc error: code = InvalidArgument desc = could not get HNS network vxlan0 via v2 api: Network Id  not found \n","stream":"stdout","time":"2020-04-10T23:31:54.9860341Z"}
{"log":"INFO: Waiting for servcie-sidekick to prepare the entrypoint.ps1 ...\n","stream":"stdout","time":"2020-04-10T23:32:00.1557549Z"}

Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):

Rancher version: 2.3.5
Platform: Amazon AWS
OS: Control Plane and Etcd + 1 worker - RHEL 7.7
Windows workers - Windows Sever 2019 DataCenter - 1809 (Build 17763.973)

Installation option (single install/HA):

HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):  Custom

Machine type (cloud/VM/metal) and specifications (CPU/memory): All nodes AWS m52xLarge

Kubernetes version (use kubectl version): 1.17.2

Docker version (use docker version): 19.3.5

I created a debug image for rke-tools and ensured that the vni was left at 4096, however doing so did NOT resolve this issue. Instead I saw 'index out of range' errors in the logs ?
sidecar.ps1
if ($networkConfigObj)
{
    switch ($networkConfigObj.plugin)
    {
        "flannel" {
            Log-Info "AVIVA - Configuring flannel"
            $type = "vxlan"
             # VXLAN Identifier (VNI) to be used, it must be `greater than or equal to 4096` if the cluster includes Windows node
            $vni = 4096
            # UDP port to use for sending encapsulated packets, it must be `equal to 4789` if the cluster includes Windows node
            $port = 4789
            try {
                $options = $networkConfigObj.options

                $ptype = $options.flannel_backend_type
                if ($ptype) {
                    $type = $ptype
                }

                # VXLAN Identifier (VNI) to be used, it must be `greater than or equal to 4096` if the cluster includes Windows node
                $pvni = $options.flannel_backend_vni
                if ($pvni) {
                   **Log-Info "AVIVA - Surpressing change of flannel VXLAM VNI - It MUST be 4096 of greater for Windows"
                   #$vni = [int]$pvni**
                }
            } catch {
                Log-Info "AVIVA - Could not patch flannel network configration: $($_.Exception.Message)"
                Log-Warn "Could not patch flannel network configration: $($_.Exception.Message)"
            }

            @{
                Network = $clusterCIDR
                Backend = @{
                    Name = $cniInfo.Interface
                    Type = $type
                    VNI  = $vni
                    Port = $port
                }
            } | ConvertTo-Json -Compress -Depth 32 | Out-File -NoNewline -Encoding utf8 -Force -FilePath "c:\host\etc\kube-flannel\net-conf.json"

Resolved.  The Cluster config needs to use the value 4096 (or above) for the VNI (not just Windows worker nodes).
Example YAML:
...
  network:
    mtu: 0
    options:
      flannel_backend_port: '4789'
      flannel_backend_type: vxlan
      flannel_backend_vni: '4096'
    plugin: flannel


text:
Monitoring - new chart 0.1.1 is  for v2.4.5 and above

The chart 0.1.1 should be available for Rancher v2.4.5 and above.

This should be the case already. Based on this PR: https://github.com/rancher/system-charts/pull/250. @jiaqiluo can you check again?

Confirmed that the new version v0.1.1 show on Rancher v2.4.5 only
and Rancher v2.4.4 will NOT show it even changing the branch of system-chart to dev-v2.4

source: gharchive/issue

authors: jiaqiluo maggieliu

repo: rancher/rancher

license_type: permissive

license_source: github-api


text:
Internal Address Setting is not alterable, etcd from private network can't join the cluster

I recently connected a second site to an existing cluster, it was wished that the etcd runs also on one node of the other connected side, since this infrastructure should gradually migrate.
The problem: Everything is fine, connection works perfect routing is working, just RKE won't configure etcd correctly. This should,  at least what the docs are saying, be fixable by deploying with the internalAddress specified in the RKE config. However, this is not editable in the rancher ui and I don't seem to find a way to make it work.
So finally reaching out here, see log below for some insight.
2020-07-24 21:32:58.977617 I | embed: rejected connection from "192.168.1.4:44064" (error "tls: \"192.168.1.4\" does not match any of DNSNames [\"node-1\" \"node-2\" \"localhost\" \"kubernetes\" \"kubernetes.default\" \"kubernetes.default.svc\" \"kubernetes.default.svc.cluster.local\"] (lookup kubernetes.default.svc.cluster.local on 1.1.1.1:53: no such host)", ServerName "", IPAddresses ["pub-ip" "pub-ip2" "127.0.0.1" "10.43.0.1"], DNSNames ["node-1" "node-2" "localhost" "kubernetes" "kubernetes.default" "kubernetes.default.svc" "kubernetes.default.svc.cluster.local"])

Version is currently rancher v2.4.3

anyone an idea how to fix that or make rancher add those missing ips. I tried already adjusting the values in the metadata inside the local cluster (I took a backup before), but even if I change those resources there, it will restore to the before state, so either I did not alter the right ones, or I am missing something :/
@superseb maybe you can help on that?

trying my luck again, anyone who can help on this?

ping, trying with you  @superseb again :/ sry to bother so much

Please describe the issue in detail, meaning:

Provide the docker run command used to register the host
Provide docker inspect etcd from the current nodes and the newly added to see what is configured
Details on network config on the current and newly added host (ip a s/ip route show)

~It is also unclear if you actually added it with the correct addresses initially or if you are trying to edit to the correct address afterwards? I wouldn't expect the latter to work, it would just need to be deleted, cleaned and re-added with the correct configuration.~ I see the edited title. Why is removing and re-adding the node not an option? You are basically running into https://github.com/rancher/rancher/issues/14102 now.

@superseb  The nodes run also openebs, removing them would mean to have huge trouble with not loosing the data of the existing pvs... . I tried just resubmitting the joining command with the internal address provided on the old nodes, but this has no effect at all.

Provide the docker run command used to register the host

Which one, the new one or the old? This is not a problem with adding a new host, this is a problem altering an old one. The old one was added without the internal/external address provided, exactly that is the problem and is not alterable in the aftermath.

Provide docker inspect etcd from the current nodes and the newly added to see what is configured

https://pastebin.com/84Np0JxJ - From one of the current nodes (newly added, I had to remove it currently b/c it can't be added need to add that first again)
Replaced ips node1 and node2 are the public ips of the nodes, those need to be the private ones instead, which is exactly what I am trying to solve.

Details on network config on the current and newly added host (ip a s/ip route show)

That I will not post publicly, only in a disclosed channel.
However:
ip addresses assigned: NIC1 6 Public IPs
ip addresses assigned: NIC2 2 Private IPs
For the new machine on the other side
ip addresses assigned: NIC1 1 Private IP - This one does not have a public ip, the networks are connected to each other and communicate normally on layer2, but only on the private range not publicly (this node is not exposed to the internet just the ethernet which all nodes have access to).
Routes:
Nothing special: Calico routing, I have nodes on the other side for the workers, communication is fine.

What I have tried was editing the metadata state of rancher for this cluster already. I edited the cluster resource and node resources, however rancher will restore the state from somewhere again as soon as an update for those nodes runs. And that is where it gets stuck, where the information is coming from. In theory the task should be easy:
Reconfigure rke to use internal adresses, rollout new certificates for etcd, done.

More infos what I tried
kubectl edit clusters/clusterId - edit ips accordingly
kubectl edit nodes/nodename - edit ips accordingly
kubectl -n clusterid edit nodes.management.cattle.io/internal-id - edit ips accordingly
rerun setup task by minor settings change

I finally solved it oO, I just had an idea: What happens when I change the /etc/hosts file accordingly to resolve to the private ip. Did that, restarted docker, and now it started displaying the correct ips... . I tried to add the etcd host again, and worked without problems.

ok happy to early, etcd can't join since etcd is still reporting  rejected connection from "192.168.1.3:43152" (error "tls: "192.168.1.3" does not match any of DNSNames

even with spoofed dns entries it will result in this:
2020-08-05 17:48:17.473226 E | rafthttp: request cluster ID mismatch (got f43462c8c88a5f56 want 4137c9d7f3e23b91)

I guess best thing is stop letting rancher handle etcd and take into my own hands :/

Okay, I had the exact same issue: my original cluster was created on a cloud provider and only had public IP's. I wanted to move all the nodes behind a firewall, on private network. However, I could not get the new master to join the exisiting etcd cluster. Rancher would mix the external IP and the internal IP (there are numerous issues about that) and the same error would keep popping up:
embed: rejected connection from "10.1.0.106:51728" (error "tls: \"10.1.0.106\" does not match any of DNSNames

I could not get 10.1.0.106 (which is the internal IP of the machine I'd like to get off the public network) in the SSL certificate. I could not set rke.cattle.io/internal-ip and then rotate the certificates (to let them be regenerated).
My solution to this (after trying so much options), was to use iptables routing to rewrite the IP:
iptables -t nat -A OUTPUT -p tcp -d 10.1.0.61 -j DNAT --to-destination EXTERNALIP
iptables -t nat -A PREROUTING -p tcp -d 10.1.0.61 -j DNAT --to-destination EXTERNALIP
iptables -t nat -A POSTROUTING -j MASQUERADE

10.1.0.61 is the IP of the new internal master node
EXTERNALIP is an external IP (on the firewall) which I used to NAT (just for the time being).
This makes the request to etcd appear from the original external IP (which is inside the etcd certificate /etc/kubernetes/ssl/kube-etcd-*.pem and allows the certificate to be used and etcd to be migrated! 🎉

still an issue wont ever be stale

Is this the same as https://github.com/rancher/rancher/issues/14102 or does it have something else to it?

They could be very well related. There's currently no way to change IP addresses. Rancher generates ETCD SSL certs which are bound to specific IP addresses and are not regenerated which break communications with new nodes.

no not at all related.
This is about existing clusters that are trying to add afterwards a private network and connect a new etcd node on this private network. With rke without rancher this is easy pie, with rancher controlling rke it is impossible. In general I would wish more control of rke since rancher is breaking just too many things and it is really hard and some things impossible to fix those issues....

still an issue

iptables -t nat -A OUTPUT -p tcp -d 10.1.0.61 -j DNAT --to-destination EXTERNALIP
iptables -t nat -A PREROUTING -p tcp -d 10.1.0.61 -j DNAT --to-destination EXTERNALIP
iptables -t nat -A POSTROUTING -j MASQUERADE

@gerwim do you have any script for that?
@superseb may reopen that issue.... its still valid

@ItsReddi script? What do you mean? Those are three lines of commands. :-)

authors: ItsReddi gerwim mxm-tr superseb wzrdtales


text:
Can not create secrets with dot in the name using Rancher UI.

What kind of request is this (question/bug/enhancement/feature request): bug
Steps to reproduce (least amount of steps as possible):
Try to create a secret using Rancher UI and name the secret with a name that contains a dot "." like tt.test
Result:
You will fail with an error message:
"Name" contains an invalid character. .
Other details that may be helpful:
Using kubectl secrets is created without problems.
 kubectl create secret tls tt.test --cert=one.pem --key=one.key
secret/tt.test created
The issue is like issue #25955
This one is reported in version 2.4.8
gz#13612

Tested this on Rancher v2.4.8 and v2.5.5
Steps:

Deploy rancher single install.
In ember UI, go to default project, create a secret naming with dot -> "sec.test", "sec.t.t".

Result:
Secret created successfully. There is no error message.

Additional test:
Name the secret with two continuous dots ".." such as "tt..test", it will have an error:

I tested this on release/v2.4 HEAD and release/v2.5 HEAD and am able to successfully create a secret with name: hello.world. There doesn't appear to be anything to fix here.

@Ellenqs Can you validate this issue on 2.5-head and 2.4-head and close it out?

Validated this on rancher v2.4-4847-head, and 2.5-head,4cb2ebe.
Do same steps on the two versions:
Steps:

Deploy rancher single install.
In ember UI, go to default project, create a secret naming with dot.

Results
Secret created successfully.
Result on v2.4-head:

Result on v2.5-head:

I did some additional research, the secrets can be created, it fails when you try to add the certificate.

authors: Ellenqs ranchersvet ryansann sowmyav27


text:
Introduce support for IP dual-stack

Feature gate IPv6DualStack for IPv4/IPv6 dual-stack networking is enabled by default for 1.21 kubernetes cluster. But cluster needs to meet a few requirements and configurations before it works correctly.
So we're going to disable the feature flag by default in Rancher 2.6, k8s 1.21. In order to support this, we need to validate prerequisites and configure the command args to kubernetes components in RKE.
Refer to https://kubernetes.io/docs/concepts/services-networking/dual-stack/ for more details.

We switched it off - this ask is to turn it back on and verify that it works.

k8s upstream enables this feature gate by default, so the idea is to leave it as is once #33085 is fixed.
So now there's no need to introduce a field/flag to enable/disable it.
For better user experience, we'll validate the flags passed for IPv6DualStack with networking requirements (similar to how k3s/kubeadm implements it https://github.com/k3s-io/k3s/pull/3212) and error out if cluster's not configured correctly.
Otherwise we'll default to ipv4 and nothing should error out.

To test this:

It should only work on Calico, selecting a different CNI should error
We only successfully tested this on AWS EC2, with the following prerequisites:

Add IPv6 default gateway to VPC routes
Disable source/destination checks on all EC2 instances in the cluster

Use the configuration below:

kubernetes_version: "v1.21.1-rancher2-1"
services:
  kube-api:
    service_cluster_ip_range: 10.43.0.0/16,fd98::/108
  kube-controller:
    service_cluster_ip_range: 10.43.0.0/16,fd98::/108
    cluster_cidr: 10.42.0.0/16,fd01::/64

network:
  plugin: calico

Commands that can be used:
kubectl create deployment nginx --image=nginx --replicas=5
# IPv4 + IPv6 pod addresses
kubectl get pods -l app=nginx -o jsonpath='{range .items[*]}{@.status.podIPs[0].ip}{@.status.podIPs[1].ip}{" "}{@.spec.nodeName}{"\n"}{end}'

And the adjusted overlay check script for IPv6:
#!/bin/sh
cat <<EOF | kubectl create -f -
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: overlaytest
spec:
  selector:
      matchLabels:
        name: overlaytest
  template:
    metadata:
      labels:
        name: overlaytest
    spec:
      tolerations:
      - operator: Exists
      containers:
      - image: busybox:1.28
        imagePullPolicy: Always
        name: busybox
        command: ["sh", "-c", "tail -f /dev/null"]
        terminationMessagePath: /dev/termination-log
EOF

kubectl rollout status ds/overlaytest -w

echo "=> Start network overlay test"; kubectl get pods -l name=overlaytest -o jsonpath='{range .items[*]}{@.metadata.name}{" "}{@.spec.nodeName}{"\n"}{end}' | while read spod shost; do kubectl get pods -l name=overlaytest -o jsonpath='{range .items[*]}{@.status.podIPs[1]}{" "}{@.spec.nodeName}{"\n"}{end}' | while read tip thost; do kubectl --request-timeout='10s' exec $spod -- /bin/sh -c "ping -c2 $tip > /dev/null 2>&1"; RC=$?; if [ $RC -ne 0 ]; then echo $shost cannot reach $thost; fi; done; done; echo "=> End network overlay test"

The network requirement (and I assume the reason it only works on AWS EC2), is  based on the comment from Calico Slack:
For IPv6, calico assigns /128s to pods from IP pools just like IPv4.  We don't currently support any kind of overlay for IPv6 so you need to peer with your fabric over BGP to advertise out the routes.  We don't currently support borrowing IPs from the host's subnet.
As with IPv4, Calico assigns IPs to hosts in blocks and those are then sub-divided into /128s for the individual pods.
You can use multiple IP pools to assign different IP ranges to different groups of pods.

We only successfully tested this on AWS EC2, with the following prerequisites:

Add IPv6 default gateway to VPC routes
Disable source/destination checks on all EC2 instances in the cluster

In order to facilitate the dualstack testing on AWS, adding few additional notes to prepare the environment:

Enable AWS ipv6 support: set the network range at vpc and its subnetworks
Add the ipv6 default gateway at vpc routes
Add ipv6 info to AWS security groups
Create vms with Auto-assign IPv6 IP: Enable
Disabled source/destination check at vms

More info at https://docs.aws.amazon.com/vpc/latest/userguide/get-started-ipv6.html

rke version: v1.3.0-rc13
os: 'Linux ip-10-0-0-39 5.4.0-1045-aws #47~18.04.1-Ubuntu SMP Tue Apr 13 15:58:14 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux'
docker: '20.10.7'
Steps

created a single ec2 with ipv4 and ipv6 support
installed docker
ran rke up with the config from above
kubectl create deployment nginx --image=nginx --replicas=1
kubectl get pods -l app=nginx -o jsonpath='{range .items[*]}{@.status.podIPs[0].ip}{@.status.podIPs[1].ip}{" "}{@.spec.nodeName}{"\n"}{end}'

I observed an ipv6 and ipv4 address assigned to the pod.
Running the given overlay check script fails:
=> Start network overlay test
command terminated with exit code 1
<node ip> cannot reach <node ip>
=> End network overlay test

Tested again with updated script
rke version: v1.3.0-rc13
os: Linux ip-10-0-0-39 5.4.0-1045-aws #47~18.04.1-Ubuntu SMP Tue Apr 13 15:58:14 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
docker: 20.10.7
Steps

created a single ec2 with ipv4 and ipv6 support
installed docker
ran rke up with the config from above
kubectl create deployment nginx --image=nginx --replicas=1
kubectl get pods -l app=nginx -o jsonpath='{range .items[*]}{@.status.podIPs[0].ip}{@.status.podIPs[1].ip}{" "}{@.spec.nodeName}{"\n"}{end}'

Results

I observed an ipv6 and ipv4 address assigned to the pod
The tests script from above was run and passed

Notes
I used the same steps on a 3 node cluster and bumped the nginx replica count to 3 and saw the same results.

Reopening for QA to check dev validation and close if OK.

authors: SheilaghM kinarashah paynejacob rawmind0 snasovich superseb


text:
v2.6.4 Release Task - Release CLI

Rancher Backend Engineering Task
This is a Rancher backend engineering task for (https://github.com/rancher/rancher/issues/36375) for the rancher engineering release captain:

[ ] Validate that the commits in go.mod are valid, then tag the RC.

https://github.com/rancher/cli/releases/tag/v2.6.4

authors: Jono-SUSE-Rancher paynejacob


text:
[BUG] "02 Start the server" doesn't work

Rancher Server Setup

Rancher version: 2.7
Installation option (Docker install/Helm Chart):

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc):

Proxy/Cert Details:
almalinux 9.1
fresh system
bare metal
podman, also docker ce 23

Information about the Cluster

Kubernetes version:
Cluster Type (Local/Downstream):

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider):

Custom
User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom)

If custom, define the set of permissions:

root
Describe the bug

the container fails to start
To Reproduce

setenforce 0
// add http https to firewall, reload firewall (done via cockpit webui)
docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher

Result
Expected Result

A running and accessible rancher node via :80 or :443
Screenshots

Additional context

docker logs
INFO: Running k3s server --cluster-init --cluster-reset

ERROR:

time="2023-02-11T19:01:54Z" level=warning msg="remove /var/lib/rancher/k3s/agent/etc/k3s-api-server-agent-load-balancer.json: no such file or directory"

time="2023-02-11T19:01:54Z" level=info msg="Starting k3s v1.24.4+k3s1 (c3f830e9)"

time="2023-02-11T19:01:54Z" level=info msg="Managed etcd cluster bootstrap already complete and initialized"

time="2023-02-11T19:01:54Z" level=info msg="Starting temporary etcd to reconcile with datastore"

{"level":"info","ts":"2023-02-11T19:01:54.782Z","caller":"embed/etcd.go:131","msg":"configuring peer listeners","listen-peer-urls":["http://127.0.0.1:2400"]}

{"level":"info","ts":"2023-02-11T19:01:54.782Z","caller":"embed/etcd.go:139","msg":"configuring client listeners","listen-client-urls":["http://127.0.0.1:2399"]}

{"level":"info","ts":"2023-02-11T19:01:54.782Z","caller":"embed/etcd.go:308","msg":"starting an etcd server","etcd-version":"3.5.3","git-sha":"Not provided (use ./build instead of go build)","go-version":"go1.18.1","go-os":"linux","go-arch":"amd64","max-cpu-set":8,"max-cpu-available":8,"member-initialized":true,"name":"9cdd045aaa4a-6ceb887a","data-dir":"/var/lib/rancher/k3s/server/db/etcd-tmp","wal-dir":"","wal-dir-dedicated":"","member-dir":"/var/lib/rancher/k3s/server/db/etcd-tmp/member","force-new-cluster":true,"heartbeat-interval":"500ms","election-timeout":"5s","initial-election-tick-advance":true,"snapshot-count":10000,"snapshot-catchup-entries":5000,"initial-advertise-peer-urls":["http://127.0.0.1:2400"],"listen-peer-urls":["http://127.0.0.1:2400"],"advertise-client-urls":["http://127.0.0.1:2399"],"listen-client-urls":["http://127.0.0.1:2399"],"listen-metrics-urls":[],"cors":["*"],"host-whitelist":["*"],"initial-cluster":"","initial-cluster-state":"new","initial-cluster-token":"","quota-size-bytes":2147483648,"pre-vote":true,"initial-corrupt-check":true,"corrupt-check-time-interval":"0s","auto-compaction-mode":"","auto-compaction-retention":"0s","auto-compaction-interval":"0s","discovery-url":"","discovery-proxy":"","downgrade-check-interval":"5s"}

{"level":"info","ts":"2023-02-11T19:01:54.783Z","caller":"etcdserver/backend.go:81","msg":"opened backend db","path":"/var/lib/rancher/k3s/server/db/etcd-tmp/member/snap/db","took":"839.774µs"}

{"level":"info","ts":"2023-02-11T19:01:54.785Z","caller":"etcdserver/server.go:529","msg":"No snapshot found. Recovering WAL from scratch!"}

{"level":"info","ts":"2023-02-11T19:01:54.796Z","caller":"etcdserver/raft.go:556","msg":"forcing restart member","cluster-id":"b6c7ec2c9e50402b","local-member-id":"6d7c3a166a7ff3dc","commit-index":795}

{"level":"info","ts":"2023-02-11T19:01:54.796Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6d7c3a166a7ff3dc switched to configuration voters=()"}

{"level":"info","ts":"2023-02-11T19:01:54.796Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6d7c3a166a7ff3dc became follower at term 7"}

{"level":"info","ts":"2023-02-11T19:01:54.796Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"newRaft 6d7c3a166a7ff3dc [peers: [], term: 7, commit: 795, applied: 0, lastindex: 795, lastterm: 7]"}

{"level":"warn","ts":"2023-02-11T19:01:54.871Z","caller":"auth/store.go:1220","msg":"simple token is not cryptographically signed"}

{"level":"info","ts":"2023-02-11T19:01:54.883Z","caller":"mvcc/kvstore.go:415","msg":"kvstore restored","current-rev":758}

{"level":"info","ts":"2023-02-11T19:01:54.896Z","caller":"etcdserver/quota.go:94","msg":"enabled backend quota with default value","quota-name":"v3-applier","quota-size-bytes":2147483648,"quota-size":"2.1 GB"}

{"level":"info","ts":"2023-02-11T19:01:54.913Z","caller":"etcdserver/corrupt.go:46","msg":"starting initial corruption check","local-member-id":"6d7c3a166a7ff3dc","timeout":"15s"}

{"level":"info","ts":"2023-02-11T19:01:54.913Z","caller":"etcdserver/corrupt.go:116","msg":"initial corruption checking passed; no corruption","local-member-id":"6d7c3a166a7ff3dc"}

{"level":"info","ts":"2023-02-11T19:01:54.913Z","caller":"etcdserver/server.go:851","msg":"starting etcd server","local-member-id":"6d7c3a166a7ff3dc","local-server-version":"3.5.3","cluster-version":"to_be_decided"}

{"level":"info","ts":"2023-02-11T19:01:54.913Z","caller":"etcdserver/server.go:752","msg":"starting initial election tick advance","election-ticks":10}

{"level":"info","ts":"2023-02-11T19:01:54.914Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6d7c3a166a7ff3dc switched to configuration voters=(7889244515196728284)"}

{"level":"info","ts":"2023-02-11T19:01:54.914Z","caller":"membership/cluster.go:421","msg":"added member","cluster-id":"b6c7ec2c9e50402b","local-member-id":"6d7c3a166a7ff3dc","added-peer-id":"6d7c3a166a7ff3dc","added-peer-peer-urls":["https://10.88.0.2:2380"]}

{"level":"info","ts":"2023-02-11T19:01:54.914Z","caller":"membership/cluster.go:584","msg":"set initial cluster version","cluster-id":"b6c7ec2c9e50402b","local-member-id":"6d7c3a166a7ff3dc","cluster-version":"3.5"}

{"level":"info","ts":"2023-02-11T19:01:54.914Z","caller":"api/capability.go:75","msg":"enabled capabilities for version","cluster-version":"3.5"}

{"level":"info","ts":"2023-02-11T19:01:54.915Z","caller":"embed/etcd.go:277","msg":"now serving peer/client/metrics","local-member-id":"6d7c3a166a7ff3dc","initial-advertise-peer-urls":["http://127.0.0.1:2400"],"listen-peer-urls":["http://127.0.0.1:2400"],"advertise-client-urls":["http://127.0.0.1:2399"],"listen-client-urls":["http://127.0.0.1:2399"],"listen-metrics-urls":[]}

{"level":"info","ts":"2023-02-11T19:01:54.915Z","caller":"embed/etcd.go:581","msg":"serving peer traffic","address":"127.0.0.1:2400"}

{"level":"info","ts":"2023-02-11T19:01:54.915Z","caller":"embed/etcd.go:553","msg":"cmux::serve","address":"127.0.0.1:2400"}

{"level":"info","ts":"2023-02-11T19:02:03.797Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6d7c3a166a7ff3dc is starting a new election at term 7"}

{"level":"info","ts":"2023-02-11T19:02:03.797Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6d7c3a166a7ff3dc became pre-candidate at term 7"}

{"level":"info","ts":"2023-02-11T19:02:03.797Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6d7c3a166a7ff3dc received MsgPreVoteResp from 6d7c3a166a7ff3dc at term 7"}

{"level":"info","ts":"2023-02-11T19:02:03.797Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6d7c3a166a7ff3dc became candidate at term 8"}

{"level":"info","ts":"2023-02-11T19:02:03.797Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6d7c3a166a7ff3dc received MsgVoteResp from 6d7c3a166a7ff3dc at term 8"}

{"level":"info","ts":"2023-02-11T19:02:03.797Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"6d7c3a166a7ff3dc became leader at term 8"}

{"level":"info","ts":"2023-02-11T19:02:03.797Z","logger":"raft","caller":"etcdserver/zap_raft.go:77","msg":"raft.node: 6d7c3a166a7ff3dc elected leader 6d7c3a166a7ff3dc at term 8"}

{"level":"info","ts":"2023-02-11T19:02:03.908Z","caller":"etcdserver/server.go:2044","msg":"published local member to cluster through raft","local-member-id":"6d7c3a166a7ff3dc","local-member-attributes":"{Name:9cdd045aaa4a-6ceb887a ClientURLs:[http://127.0.0.1:2399]}","request-path":"/0/members/6d7c3a166a7ff3dc/attributes","cluster-id":"b6c7ec2c9e50402b","publish-timeout":"15s"}

{"level":"info","ts":"2023-02-11T19:02:03.908Z","caller":"embed/serve.go:98","msg":"ready to serve client requests"}

{"level":"info","ts":"2023-02-11T19:02:03.909Z","caller":"embed/serve.go:140","msg":"serving client traffic insecurely; this is strongly discouraged!","address":"127.0.0.1:2399"}

time="2023-02-11T19:02:03Z" level=info msg="Defragmenting etcd database"

{"level":"info","ts":"2023-02-11T19:02:03.910Z","caller":"v3rpc/maintenance.go:89","msg":"starting defragment"}

{"level":"info","ts":"2023-02-11T19:02:03.975Z","caller":"backend/backend.go:497","msg":"defragmenting","path":"/var/lib/rancher/k3s/server/db/etcd-tmp/member/snap/db","current-db-size-bytes":2396160,"current-db-size":"2.4 MB","current-db-size-in-use-bytes":2392064,"current-db-size-in-use":"2.4 MB"}

{"level":"info","ts":"2023-02-11T19:02:04.050Z","caller":"backend/backend.go:549","msg":"finished defragmenting directory","path":"/var/lib/rancher/k3s/server/db/etcd-tmp/member/snap/db","current-db-size-bytes-diff":0,"current-db-size-bytes":2396160,"current-db-size":"2.4 MB","current-db-size-in-use-bytes-diff":-4096,"current-db-size-in-use-bytes":2387968,"current-db-size-in-use":"2.4 MB","took":"139.901625ms"}

{"level":"info","ts":"2023-02-11T19:02:04.050Z","caller":"v3rpc/maintenance.go:95","msg":"finished defragment"}

time="2023-02-11T19:02:04Z" level=info msg="etcd temporary data store connection OK"

time="2023-02-11T19:02:04Z" level=info msg="Reconciling bootstrap data between datastore and disk"

time="2023-02-11T19:02:04Z" level=info msg="Cluster reset: backing up certificates directory to /var/lib/rancher/k3s/server/tls-1676142124"

time="2023-02-11T19:02:04Z" level=warning msg="Updating bootstrap data on disk from datastore"

time="2023-02-11T19:02:04Z" level=info msg="stopping etcd"

{"level":"info","ts":"2023-02-11T19:02:04.140Z","caller":"embed/etcd.go:368","msg":"closing etcd server","name":"9cdd045aaa4a-6ceb887a","data-dir":"/var/lib/rancher/k3s/server/db/etcd-tmp","advertise-peer-urls":["http://127.0.0.1:2400"],"advertise-client-urls":["http://127.0.0.1:2399"]}

{"level":"info","ts":"2023-02-11T19:02:04.141Z","caller":"etcdserver/server.go:1453","msg":"skipped leadership transfer for single voting member cluster","local-member-id":"6d7c3a166a7ff3dc","current-leader-member-id":"6d7c3a166a7ff3dc"}

time="2023-02-11T19:02:04Z" level=fatal msg="starting kubernetes: preparing server: start managed database: Managed etcd cluster membership was previously reset, please remove the cluster-reset flag and start k3s normally. If you need to perform another cluster reset, you must first manually delete the /var/lib/rancher/k3s/server/db/reset-flag file"

INFO: Running k3s server --cluster-init --cluster-reset

2023/02/11 19:02:25 [INFO] Rancher version v2.7.1 (bb1c35fc4) is starting

2023/02/11 19:02:25 [INFO] Rancher arguments {ACMEDomains:[] AddLocal:true Embedded:false BindHost: HTTPListenPort:80 HTTPSListenPort:443 K8sMode:auto Debug:false Trace:false NoCACerts:false AuditLogPath:/var/log/auditlog/rancher-api-audit.log AuditLogMaxage:10 AuditLogMaxsize:100 AuditLogMaxbackup:10 AuditLevel:0 Features: ClusterRegistry:}

2023/02/11 19:02:25 [INFO] Listening on /tmp/log.sock

2023/02/11 19:02:25 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:02:27 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:02:29 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:02:31 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:02:33 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:02:35 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:02:40 [FATAL] k3s exited with: exit status 2

INFO: Running k3s server --cluster-init --cluster-reset

2023/02/11 19:03:02 [INFO] Rancher version v2.7.1 (bb1c35fc4) is starting

2023/02/11 19:03:02 [INFO] Rancher arguments {ACMEDomains:[] AddLocal:true Embedded:false BindHost: HTTPListenPort:80 HTTPSListenPort:443 K8sMode:auto Debug:false Trace:false NoCACerts:false AuditLogPath:/var/log/auditlog/rancher-api-audit.log AuditLogMaxage:10 AuditLogMaxsize:100 AuditLogMaxbackup:10 AuditLevel:0 Features: ClusterRegistry:}

2023/02/11 19:03:02 [INFO] Listening on /tmp/log.sock

2023/02/11 19:03:02 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:05 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:07 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:09 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:11 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:13 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:15 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:17 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:19 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:21 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:26 [FATAL] k3s exited with: exit status 2

INFO: Running k3s server --cluster-init --cluster-reset

2023/02/11 19:03:49 [INFO] Rancher version v2.7.1 (bb1c35fc4) is starting

2023/02/11 19:03:49 [INFO] Rancher arguments {ACMEDomains:[] AddLocal:true Embedded:false BindHost: HTTPListenPort:80 HTTPSListenPort:443 K8sMode:auto Debug:false Trace:false NoCACerts:false AuditLogPath:/var/log/auditlog/rancher-api-audit.log AuditLogMaxage:10 AuditLogMaxsize:100 AuditLogMaxbackup:10 AuditLevel:0 Features: ClusterRegistry:}

2023/02/11 19:03:49 [INFO] Listening on /tmp/log.sock

2023/02/11 19:03:49 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:51 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:53 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:55 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:57 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:03:59 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:01 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:04 [INFO] Running in single server mode, will not peer connections

2023/02/11 19:04:05 [INFO] Applying CRD features.management.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD navlinks.ui.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD clusters.management.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD apiservices.management.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD clusterregistrationtokens.management.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD settings.management.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD preferences.management.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD features.management.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD clusterrepos.catalog.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD operations.catalog.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD apps.catalog.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD fleetworkspaces.management.cattle.io

2023/02/11 19:04:05 [INFO] Applying CRD managedcharts.management.cattle.io

2023/02/11 19:04:06 [INFO] Applying CRD clusters.provisioning.cattle.io

2023/02/11 19:04:06 [INFO] Applying CRD clusters.provisioning.cattle.io

2023/02/11 19:04:06 [INFO] Applying CRD rkeclusters.rke.cattle.io

2023/02/11 19:04:06 [INFO] Applying CRD rkecontrolplanes.rke.cattle.io

2023/02/11 19:04:06 [INFO] Applying CRD rkebootstraps.rke.cattle.io

2023/02/11 19:04:06 [INFO] Applying CRD rkebootstraptemplates.rke.cattle.io

2023/02/11 19:04:06 [INFO] Applying CRD rkecontrolplanes.rke.cattle.io

2023/02/11 19:04:06 [INFO] Applying CRD custommachines.rke.cattle.io

2023/02/11 19:04:06 [INFO] Applying CRD etcdsnapshots.rke.cattle.io

2023/02/11 19:04:06 [FATAL] k3s exited with: exit status 2

INFO: Running k3s server --cluster-init --cluster-reset

2023/02/11 19:04:29 [INFO] Rancher version v2.7.1 (bb1c35fc4) is starting

2023/02/11 19:04:29 [INFO] Rancher arguments {ACMEDomains:[] AddLocal:true Embedded:false BindHost: HTTPListenPort:80 HTTPSListenPort:443 K8sMode:auto Debug:false Trace:false NoCACerts:false AuditLogPath:/var/log/auditlog/rancher-api-audit.log AuditLogMaxage:10 AuditLogMaxsize:100 AuditLogMaxbackup:10 AuditLevel:0 Features: ClusterRegistry:}

2023/02/11 19:04:29 [INFO] Listening on /tmp/log.sock

2023/02/11 19:04:29 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:31 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:33 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:35 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:37 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:39 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:41 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:43 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:45 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:04:49 [FATAL] k3s exited with: exit status 2

INFO: Running k3s server --cluster-init --cluster-reset

2023/02/11 19:05:14 [INFO] Rancher version v2.7.1 (bb1c35fc4) is starting

2023/02/11 19:05:14 [INFO] Rancher arguments {ACMEDomains:[] AddLocal:true Embedded:false BindHost: HTTPListenPort:80 HTTPSListenPort:443 K8sMode:auto Debug:false Trace:false NoCACerts:false AuditLogPath:/var/log/auditlog/rancher-api-audit.log AuditLogMaxage:10 AuditLogMaxsize:100 AuditLogMaxbackup:10 AuditLevel:0 Features: ClusterRegistry:}

2023/02/11 19:05:14 [INFO] Listening on /tmp/log.sock

2023/02/11 19:05:14 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:05:16 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:05:18 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:05:20 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:05:22 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:05:24 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:05:26 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:05:28 [INFO] Waiting for server to become available: Get "https://127.0.0.1:6444/version?timeout=15m0s": dial tcp 127.0.0.1:6444: connect: connection refused

2023/02/11 19:05:33 [FATAL] k3s exited with: exit status 2

INFO: Running k3s server --cluster-init --cluster-reset

Please supply the output of docker info and docker cp <rancher-container>:/var/lib/rancher/k3s.log . && cat k3s.log, I will see if I can include this output by default in the log.

# docker info
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
host:
  arch: amd64
  buildahVersion: 1.27.3
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.4-1.el9.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.4, commit: 24a4eb8c5272ea46c28889a24fc0a9ba1f4b0c74'
  cpuUtilization:
    idlePercent: 98.71
    systemPercent: 0.16
    userPercent: 1.12
  cpus: 8
  distribution:
    distribution: '"almalinux"'
    version: "9.1"
  eventLogger: journald
  hostname: data.local
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.14.0-162.12.1.el9_1.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 32057274368
  memTotal: 33467703296
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.5-1.el9.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.5
      commit: 54ebb8ca8bf7e6ddae2eb919f5b82d1d96863dea
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_NET_RAW,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-2.el9_0.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.2
  swapFree: 16800280576
  swapTotal: 16800280576
  uptime: 0h 11m 56.00s
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0

You can't comment at this time — your comment is too long (maximum is 65536 characters).

https://pastebin.com/QJepfKDF

I am not an almalinux expert. However, I can see these panic logs from that pastebin url.
panic: F0217 14:09:36.199831      74 network_policy_controller.go:380] failed to run iptables command to create KUBE-ROUTER-INPUT chain due to running [/usr/bin/iptables -t filter -S KUBE-ROUTER-INPUT 1 --wait]: exit status 3: iptables v1.8.6 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

goroutine 10874 [running]:
k8s.io/klog/v2.(*loggingT).output(0x7eb5ea0, 0x3, 0x0, 0xc004a8c690, 0x1, {0x6469804?, 0x2?}, 0xc0000ae800?, 0x0)
	/go/pkg/mod/github.com/k3s-io/klog/v2@v2.60.1-k3s1/klog.go:820 +0x694
k8s.io/klog/v2.(*loggingT).printfDepth(0x7eb5ea0, 0x11?, 0x0, {0x0, 0x0}, 0x48cf9b?, {0x4cd8c99, 0x3b}, {0xc0059100c0, 0x2, ...})
	/go/pkg/mod/github.com/k3s-io/klog/v2@v2.60.1-k3s1/klog.go:630 +0x1f2
k8s.io/klog/v2.(*loggingT).printf(...)
	/go/pkg/mod/github.com/k3s-io/klog/v2@v2.60.1-k3s1/klog.go:612
k8s.io/klog/v2.Fatalf(...)
	/go/pkg/mod/github.com/k3s-io/klog/v2@v2.60.1-k3s1/klog.go:1496
github.com/cloudnativelabs/kube-router/pkg/controllers/netpol.(*NetworkPolicyController).ensureTopLevelChains(0xc00602ec00)
	/go/pkg/mod/github.com/k3s-io/kube-router@v1.5.1-0.20220630214451-a43bcd8511d2/pkg/controllers/netpol/network_policy_controller.go:380 +0x150c
github.com/cloudnativelabs/kube-router/pkg/controllers/netpol.(*NetworkPolicyController).Run(0xc00602ec00, 0xc00f497da0, 0xc000e50000, 0xc009730860)
	/go/pkg/mod/github.com/k3s-io/kube-router@v1.5.1-0.20220630214451-a43bcd8511d2/pkg/controllers/netpol/network_policy_controller.go:166 +0x16f
created by github.com/k3s-io/k3s/pkg/agent/netpol.Run
	/go/src/github.com/k3s-io/k3s/pkg/agent/netpol/netpol.go:135 +0xacc

This is not in the Rancher Support Matrix: https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-7-1/
I recommend this Helm CLI Quick Start. You may need to adjust k3s parameters to avoid panic.
https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli

Aparently nftables replace iptables. Not sure if only in Alma9 or if it's a RHEL thing in general or a Linux thing in general.
Gentoo wiki says https://wiki.gentoo.org/wiki/Nftables
I'm guessing before long k3s or rancher will have to adapt.
I installed Ubuntu 22.04 now and will close this issue.

authors: idc77 niusmallnan superseb


text:
I got errorcattle-node-agent

k get po
NAME                                    READY   STATUS             RESTARTS       AGE
cattle-cluster-agent-547d5cdc5b-9bj67   1/1     Running            5 (277d ago)   281d
cattle-cluster-agent-547d5cdc5b-g7rwv   1/1     Running            1 (277d ago)   281d
cattle-node-agent-6rt5d                 0/1     CrashLoopBackOff   49 (30s ago)   3h47m
cattle-node-agent-dj8th                 0/1     CrashLoopBackOff   36 (32s ago)   161m
cattle-node-agent-z4pgk                 1/1     Running            1 (277d ago)   281d

I got error below  on pod cattle-node-agent how to fix it
time="2023-02-14T13:26:11Z" level=error msg="Issuer of last certificate found in chain (CN=Kubernetes Ingress Controller Fake Certificate,O=Acme Co) does not match with CA certificate Issuer (CN=dynamiclistener-ca,O=dynamiclistener-org). Please check if the configured server certificate contains all needed intermediate certificates and make sure they are in the correct order (server certificate first, intermediates after)"
time="2023-02-14T13:26:11Z" level=fatal msg="Get \"https://rancher.xxx.co.th\": x509: certificate is valid for ingress.local, not rancher.kbjcapital.co.th"

First, you need to clarify which SSL configuration you want to use.
https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha#2-choose-your-ssl-configuration
The node-agent needs to verify the certificate, which depends on your SSL configuration.

let me check this one. Thanks

this one is cluster provisioning by rancher portal. as I check all option leave default

There are not enough steps missing in the issue description that I can't figure out where the problem is.
If, you use cert-manager, you can check its logs. It looks like the ingress doesn't match the correct certificate.

authors: kittisuw niusmallnan


text:
[rancher-compose] up updates loadbalancer without --upgrade reports out of sync on next run

Rancher Version: 1.0.2
Docker Version: 1.10.3
OS and where are the hosts located? (cloud, bare metal, etc): Ubuntu 16.04, bare metal
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB) single node rancher
Environment Type: (Cattle/Kubernetes/Swarm/Mesos) Cattle
Steps to Reproduce:
I'm checking config in web UI and reloading (F5) UI after rancher-compose up finishes.
loadbalancer:
  image: rancher/load-balancer-service
  ports:
    - '1000:1000'
  links:
    - alpha:alpha
#     - beta:beta
  labels:
    'io.rancher.loadbalancer.target.alpha': ':1000=80'
#     'io.rancher.loadbalancer.target.beta': ':1000=80'

alpha:
  image: httpd:2.4
  command: sh -c 'echo "alpha" > /usr/local/apache2/htdocs/index.html && exec httpd-foreground'

beta:
  image: httpd:2.4
  command: sh -c 'echo "beta" > /usr/local/apache2/htdocs/index.html && exec httpd-foreground'

> rancher-compose up -d
INFO[0000] Project [lb]: Starting project
INFO[0000] [0/3] [alpha]: Starting
INFO[0000] [0/3] [beta]: Starting
INFO[0000] [1/3] [beta]: Started
INFO[0000] [2/3] [alpha]: Started
INFO[0000] [2/3] [loadbalancer]: Starting
INFO[0000] [3/3] [loadbalancer]: Started
INFO[0000] Project [lb]: Project started
> # uncomment beta target and link of loadbalancer service
> sed -i 's/# \(    .*beta.*\)/\1/' docker-compose.yml
> rancher-compose up -d
INFO[0000] Project [lb]: Starting project
INFO[0000] [0/3] [alpha]: Starting
INFO[0000] [0/3] [beta]: Starting
INFO[0000] [1/3] [beta]: Started
INFO[0000] [2/3] [alpha]: Started
INFO[0000] [2/3] [loadbalancer]: Starting
WARN[0000] Service loadbalancer is out of sync with local configuration file
INFO[0000] [3/3] [loadbalancer]: Started
INFO[0000] Project [lb]: Project started
> # at this point rancher-compose complains about out of sync service but has updated loadbalancer target and links
> rancher-compose up -d
... same output as previous rancher-compose up -d ...

Results:
rancher-compose reports service out of sync but updates its links and targets (labels).
WARN[0000] Service loadbalancer is out of sync with local configuration file

Expected:
No out of sync message after running rancher-compose up -d for third time (after target and link was updated).

Followup:
Removing service added to loadbalancer again using only rancher-compose up -d works.
Removing service that was there at the beginning (alpha) does work. Only the target is removed the link remains.
> # continuing after Steps to reproduce
> # comment beta target
> sed -i 's/\(    .*beta.*\)/# \1/' docker-compose.yml
> rancher-compose up -d
... no out of sync ...
> # beta is removed from config (Web UI)
> sed -i 's/# \(    .*beta.*\)/\1/' docker-compose.yml
> rancher-compose up -d
...
> sed -i 's/# \(    .*alpha.*\)/\1/' docker-compose.yml
> rancher-compose up -d
... again out of sync ...
> # link to alpha is removed but target to alpha is still present

@galal-hussein can you follow up on whether this is a real issue or not?

@mishak87 To upgrade the services after updating the docker-compose file, you should use the following command:
rancher-compose up --upgrade
for more information on upgrading the services you can checkout the official documentation

authors: galal-hussein mishak87 will-chan


text:
Version drop-down stays active after deactivating driver

Rancher Version: 1.2.0-pre4-rc2
Steps to Reproduce:

Activate vultr driver or a driver that has multiple version
Deactivate driver

Results: The version drop-down stay active
Expected:  Should not stay active

Version - master 10/19
Verified fixed


text:
Cannot swith to the Mesos Environment

Rancher Version: v1.2.0-pre4-rc11
**Docker Version:  1.12.3 **
OS and where are the hosts located? (cloud, bare metal, etc):
GCP
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Rancher with 3 nodes
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Mesos
Steps to Reproduce:
Create a new environment
Choose mesos
Select Mesos
Results:
Error
Reload to try again or log out
Expected:
Switch to Mesos

https://github.com/rancher/ui/commit/167b33a2402e968c7192319becbaad3c6d4daa2b

Version - master 11/22
@funkydorian Saw it yesterday and we fixed it.  Should be in the next build
Verified Fixed

authors: funkydorian tfiduccia vincent99


text:
Environment showing as degraded after upgrade from 1.1.2 to 1.2.2

Rancher Versions:
Server: 1.2.2
healthcheck:0.2.0
ipsec:0.8.1
network-services:0.4.0
scheduler:0.5.0
kubernetes (if applicable):N/A
Docker Version:
Client:
Version:      1.12.1
API version:  1.24
Go version:   go1.6.3
Git commit:   23cf638
Built:        Thu Aug 18 17:52:38 2016
OS/Arch:      linux/amd64
Server:
Version:      1.12.1
API version:  1.24
Go version:   go1.6.3
Git commit:   23cf638
Built:        Thu Aug 18 17:52:38 2016
OS/Arch:      linux/amd64
OS and where are the hosts located? (cloud, bare metal, etc):
AWS
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single Node rancher with externaldb (RDS)
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:
Upgrade Rancher from 1.1.2 to 1.2,2
Results:
-Under Environments / Manage environment our main environment shows up as Degraded
-Stacks are all running without issues, so we are not sure where the "Degrade" state comes from
Expected:
Environment should not show up as degraded, and/or there should be a way to identify the source of that status.

Degraded for environment is the same concept of degraded for stacks.
If any of your stacks have any issues and are not green/active, environment will be degraded.

All our stacks are green and healthy except for two that are marked as Inactive? does this mean that these Inactive stacks cause the environment state to be Degraded ?

Yes, those would cause them to be degraded. Just like how an inactive service causes a stack to appear degraded.

Really ?. A stack that has been explicitly set to inactive causes the whole environment to show as degraded, why ?  Degraded to me suggests that something is not working or exhibiting unexpected behaviour. If I deliberately stop a service for whatever reason, that is the behaviour I expect right ?

I agree, if a service was delierately stopped it should not show the environment as degraded. It's just confusing

@pythianarceri i have updated the title of this ticket to better reflect whats the issue discussed here.
@deniseschannon This issue makes the healthState property of environments useless as to determining whether all the services in those environments are healthy.
Imagine having to monitor 10+ environments. Instead of being able to rely on this aggregated view to get insight into the health of environments

one needs to navigate through each of the environments and check whether any stacks/services are actually unhealthy or just contain one or more deactivated stacks.

I completely agree, if a stack has been purposefully stopped, it should not be marked as unhealthy it should be marked as inactive and it should not degrade the entire environment.

:+1: Stopped stacks should not mark environment as degraded

With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.

authors: deniseschannon ekristen goffinf janeczku jjscarafia pythianarceri


text:
Add content handler to gzip chain

Problem:
Monitoring would break on certain browsers because header was not being.
Solution:
Set use content handler in gzip chain. This handler will properly set content type header when necessary.
Refactor of:
https://github.com/rancher/rancher/pull/19497
Issue:
https://github.com/rancher/rancher/issues/19507

LGTM

source: gharchive/pull-request

authors: cjellick rmweir


text:
Fix the issue OTC driver cannot be activated

Problem:
Previous otc download url is pointing to the latest version. We cannot make sure the checksum for it always correct.
Solution:
Point it to a particular version of otc driver.
https://github.com/rancher/rancher/issues/19223

LGTM


text:
implements external database configure for helm charts

Hi contributors!
This PR becomes to enable configure external Database value.
Now, Helm charts have not a data's persistent solution.
So, it should use a stateful layer outside.

Huh?  This chart is for rancher 2.x, which uses etcd and has no MySQL database.

oh, really? 🙇

@vincent99 btw, please teach me about "how to configure external etcd cluster" if you know.

The chart deploys Rancher into an existing Kubernetes cluster, which has its own etcd backing it, wherever it is.  Rancher 2.x's "database" is custom resource definitions (CRDs) within the Kubernetes API.

🆗 Thank you!


text:
Support OAuth for Rancher CLI

Issue: https://github.com/rancher/rancher/issues/42939
Problem

Solution

Testing

Engineering Testing
Manual Testing

Automated Testing

Test types added/modified:

Unit
Integration (Go Framework)
Integration (v2prov Framework)
Validation (Go Framework)
Other - Explain: EXPLAIN
None
REMOVE NOT APPLICABLE BULLET POINTS ABOVE

If "None" - Reason: EXPLAIN THE REASON

If "None" - GH Issue/PR: LINK TO GH ISSUE/PR TO ADD TESTS

Summary: TODO
QA Testing Considerations

Regressions Considerations

TODO
Existing / newly added automated tests that provide evidence there are no regressions:

TODO

We are exploring better ways of doing that so closing.


text:
CPU shares are not passed when container is started on Windows nodes

Copied from JIRA SURE-2921
Rancher Server Setup

Rancher version: 2.4.8

Information about the Cluster

Kubernetes version: v1.18.15

Describe the bug
When you set the resource limits on a container those values should be mapped to the --memory and --cpu-shares flags for the docker run command. I am not seeing this behavior. When I set limits on memory and cpu the memory is mapped to --memory but the cpu is mapped to --cpus.
To Reproduce
Try to pass the values just by running docker, It is successful.
docker run --rm --detach --name bonbon --cpu-shares "500" mcr.microsoft.com/windows/servercore/iis
Cpu shares show with docker inspect
"Isolation": "process",
"CpuShares": 500,
Repro steps:

step 1

Configure pod with cpu limit

step 2

Observe result with docker inspect

Result
Cpu shares are not configured
Expected Result
Cpu shares to be configured
Additional context
https://jira.suse.com/browse/SURE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel

Need more details from customer https://jira.suse.com/browse/SURE-2921?focusedCommentId=1138950&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1138950

Reason for close - it was fixed for a while now:

This appears to have been fixed in later version of 1.18. https://github.com/kubernetes/kubernetes/issues/75296

authors: sirredbeard snasovich

repo: rancher/windows


text:
Remove the need of 9345/9346 in UI

As of v0.24.0, we are running Rancher behind a proxy and no longer need the 9345 and 9346 ports to be open.
We need to remove this information from the UI and docs.

This was done at some point...

repo: rancherio/rancher

license_source: bigquery


text:
sms help

sending sms works flawlessly, is there anyway to check for an sms meeting x requirements within a certain timeframe, say past 5 minutes. Or make it continuously check on each sms recieved?

I know this is an old question, leaving here for future readers.
I believe this requires this lib to be refactored, been checking on how to read SMS. Pushbullet allows this, but seems that its not documented, as besides ephemerals, there are other endpoints, such as permanents.
To get all sms from a given device you could do something like this with current lib:
pb = Pushbullet(api_key)
some_device = pb.devices[x]
device_sms_url = "https://api.pushbullet.com/v2/permanents/%s_threads"%(some_device.device_iden)
messages = pb._session.get(device_sms_url).text
Json load messages or use .json() from requests to work the json response of all sms for given device.

authors: Ilhicas regendare

license: mit


text:
Correct typo for push_note() example in readme

Under "Pushing a text note", the pb.push_note() example has a trailing fullstop outside the inverted commas which is obviously invalid syntax.

Coverage remained the same at 56.89% when pulling 52fdf4f04105f32ccb3b0d86152e0ebd0c33a811 on jonmcalder:patch-1 into 79bddc4f585765e944b37333d08602b3fe0ed60a on randomchars:master.

Coverage remained the same at 56.89% when pulling 52fdf4f04105f32ccb3b0d86152e0ebd0c33a811 on jonmcalder:patch-1 into 79bddc4f585765e944b37333d08602b3fe0ed60a on randomchars:master.

authors: coveralls jonmcalder


text:
Add alltoone mode

Checks 1 - 11

Codecov Report

Merging #50 into master will increase coverage by 0.08%.
The diff coverage is 95%.

@@            Coverage Diff             @@
##           master      #50      +/-   ##
==========================================
+ Coverage   96.57%   96.66%   +0.08%
==========================================
  Files           5        5
  Lines         525      539      +14
==========================================
+ Hits          507      521      +14
  Misses         18       18

Impacted Files
Coverage Δ

src/raster.jl
99.06% <100%> (+0.04%)
:arrow_up:

src/network.jl
98.95% <83.33%> (+0.02%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 86d2c07...e476872. Read the comment docs.

authors: codecov-io ranjanan

license: MIT


text:
Logging update

enhancing logging in service.py and service_aggregator.py.
also added support for capturing uvicorn logs

i think those log entries may cause downstream issues until something is done about the trapi.
i have added the exception name in each log event.

repo: ranking-agent/aragorn


text:
Content disappears if todo.txt is edited externally

To Reproduce

Open a todo.txt in sleek.
Edit the same file in a text editor.

Expected behavior

Sleek updates its contents to reflect changes (as before).

Actual behavior

All content is hidden in sleek as if the file is empty. Clicking reset filters has no effect.

Content is shown again on reloading sleek.

Desktop (please complete the following information):

Windows
Latest sleek from Github.

Side thing: please add "Actual behavior" to bug report template.

Interesting, in particularly because the file watcher received quite some fine tuning and testing over the last couple of weeks. I quickly checked it on my Linux where it worked flawless, but I will check in on my Win 10 VM tomorrow.
Is the file you're editing synced by something like Dropbox, Syncthing or similar?

Is the file you're editing synced by something like Dropbox, Syncthing or similar?

Yes but the behavior happens even after it is disabled.
I noticed now that it happens with VS Code but not some other editors and only if you switch immediately to sleek after clicking save 😕

@9z0, I can't reproduce it, not even on Windows 10 with VS Code:
https://user-images.githubusercontent.com/11188741/120896644-c28adc00-c622-11eb-8036-446b899e40f3.mp4
The same happens when I switch to sleek immediately after saving the document.

OK. I tried to reproduce your reproduction. I found the following:
It seems to be about reaching Sleek before the save process is complete. So:

It doesn't occur if the file is small. A few lines will be saved too fast it seems. Try hundreds (or thousands) of todos.
I measured ~2.5s between the disappearance of the dirty marker and the switch in your video. The switch needs to be really fast. Reflexive CTRL+S ALT+TAB. Gamer-like. 😉

Alright, would you mind closing the issue, if it is resolved?

How is it resolved? 😕
I can try to wait a little while before switching as a workaround if you think it is unsolvable.

It certainly is somehow resolvable, but I can't be putting effort into an issue I can't even reproduce and that is an edge case.

Still not reproducible after my post-video comment?
If so, I can close the issue.

Yes, I have gave it my best shots (and I used to be a Gamer) but wasn't able to break it. Not even with my dummy todo list with around 500 entries and when I quadrupled the entries to over two thousand it still worked. But again, I'm not saying I don't believe you.
Even if I was able to reproduce it with 5000+ entries: Do you consider this workflow relevant? The typical use case imo is not that I use sleek and a text editor at the same time, working on my todos and do rapid tabbing between them.
A typical use case that might be affected by this would be if a sync service like Dropbox or Syncthing is involved, breaking the file watcher because of unexpected or slow file hanlding of VS Code. Actually this used to be a nasty issue in the past that led to the replacement of nodes native file watcher implementation with a more reliable one.

I understand. It is just that when you are that edge case, it doesn't make it less of an issue that no one else has it, I guess.
Thanks for your effort. 👍


text:
OTA update m5stick plus

try to configure m5stick to update firmware by OTA, but during firmware upload system show below error:

can you help me?

try to replace the  upload_port in platformio.ini with the IP of the ESP32

already try, but have still problem

Are you sure its the correct ip? Can you ping it?

Also, as the ESP is connecting subsequently to the pc, one common issue is that the connection will be blocked by the firewall on the PC. Make sure it's deactivated for the time of the update.

Also, as the ESP is connecting subsequently to the pc, one common issue is that the connection will be blocked by the firewall on the PC. Make sure it's deactivated for the time of the update.

With your instruction, working fine, thanks for support

authors: jangarga munzili raomin

repo: raomin/ESPAltherma


text:
Strange bug with network and unloading chunks

Issue description:
Whenever I leave my base for a couple minutes and come back there's a chance all of my refined storage machines stop working, the controller is still lit up but it doesn't show much in the GUI, when I replace the controller everything shows in the gui but only cables, drives and external storages work, machines only start working again after I replace them and the controller.
What happens:
I leave my base, when I come back there's a chance RS machines will not be lit up and will stop working, the controller stays lit but the things that show up in the gui are incomplete. I have to replace the controller and all grids, crafters, solderers, importers, exporters, disk manipulators for them to work BUT I don't have to replace any drives, external storages or cables, those work and show up in the controller after I just replace the controller.
Here's a video for clarification: [Link]
What you expected to happen:
I come back to my base and everything just works
Steps to reproduce:

Setup a small system with a variety of RS devices
Leave the area for a few minutes or disconnect for a few minutes
Come back and there's a chance things will look as I described

Version (make sure you are on the latest version before reporting):

Minecraft: 1.10.2
Forge: 12.18.3.2281
Refined Storage: 1.2.25
*FTB Beyond 1.6.1

Does this issue occur on a server? [yes/no] Yes (I haven't seen it happen offline)
If a (crash)log is relevant for this issue, link it here:
The server admin says nothing showed up in the console when this happens

I suppose you don't read closed issues or use the GH search function
#370

authors: HardwareAccelerated raoulvdberge

repo: raoulvdberge/refinedstorage


text:
fix: change npx to pnpm

Change npx to pnpm

As you requested @rapax00


text:
[BUG]Cannot manually install cuVS

cuvs/build.sh failed
Hi! I am trying to do some adjustment on your source code of cagra and check if it could work. However, I failed to manually install your cuvs package (without any modification).
Could you kindly tell me if there is a better way for me to complete it, or  help with the maunually installation problem.
/cuvs-branch-24.12$ ./build.sh python
Looking in indexes: https://mirrors.ustc.edu.cn/pypi/web/simple
Processing ./python/cuvs
  Preparing metadata (pyproject.toml) ... error
  error: subprocess-exited-with-error

  × Preparing metadata (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [30 lines of output]
      Traceback (most recent call last):
        File "/share/public/chenzk/Miniconda3/envs/transformer/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
          main()
        File "/share/public/chenzk/Miniconda3/envs/transformer/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
          json_out['return_val'] = hook(**hook_input['kwargs'])
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/share/public/chenzk/Miniconda3/envs/transformer/lib/python3.11/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 149, in prepare_metadata_for_build_wheel
          return hook(metadata_directory, config_settings)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/share/public/chenzk/Miniconda3/envs/transformer/lib/python3.11/site-packages/rapids_build_backend/impls.py", line 370, in prepare_metadata_for_build_wheel
          return _get_backend(config.build_backend).prepare_metadata_for_build_wheel(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/share/public/chenzk/Miniconda3/envs/transformer/lib/python3.11/site-packages/scikit_build_core/build/__init__.py", line 96, in prepare_metadata_for_build_wheel
          return _build_wheel_impl(
                 ^^^^^^^^^^^^^^^^^^
        File "/share/public/chenzk/Miniconda3/envs/transformer/lib/python3.11/site-packages/scikit_build_core/build/wheel.py", line 175, in _build_wheel_impl
          return _build_wheel_impl_impl(
                 ^^^^^^^^^^^^^^^^^^^^^^^
        File "/share/public/chenzk/Miniconda3/envs/transformer/lib/python3.11/site-packages/scikit_build_core/build/wheel.py", line 232, in _build_wheel_impl_impl
          metadata = get_standard_metadata(pyproject, settings)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/share/public/chenzk/Miniconda3/envs/transformer/lib/python3.11/site-packages/scikit_build_core/build/metadata.py", line 40, in get_standard_metadata
          metadata = StandardMetadata.from_pyproject(new_pyproject_dict)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/share/public/chenzk/Miniconda3/envs/transformer/lib/python3.11/site-packages/scikit_build_core/_vendor/pyproject_metadata/__init__.py", line 238, in from_pyproject
          version = packaging.version.Version(version_string) if version_string else None
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/share/public/chenzk/Miniconda3/envs/transformer/lib/python3.11/site-packages/packaging/version.py", line 202, in __init__
          raise InvalidVersion(f"Invalid version: '{version}'")
      packaging.version.InvalidVersion: Invalid version: '../../../VERSION'
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

My environment is:
Miniconda 24.7.1
python 3.11.10
cmake  3.27.4
gcc       11.4.0
nvcc      12.1
packaging 24.1

The VERSION file needed here is a symlink. The path cuvs-branch-24.12/python/cuvs/cuvs/VERSION should be a symlink that points to cuvs-branch-24.12/VERSION. You can see it on GitHub here: https://github.com/rapidsai/cuvs/blob/branch-24.12/python/cuvs/cuvs/VERSION
Note that to get this symlink, you must use git to clone the repository. The symlink is not present in the .zip archive of this repository, because .zip files do not support symlinks. I am guessing that you might have downloaded the .zip file of this repository, based on the name of your directory (cuvs-branch-24.12).
You can try git clone https://github.com/rapidsai/cuvs.git to clone from GitHub.

Thanks! I will try.

repo: rapidsai/cuvs


text:
[WIP] added documentation for several key steps

This pull request updates the documentation for the E2E notebook.

@paulhendricks Could you update the README.md file with the updated dataset link. This would address #116 in addition to #119.

@paulhendricks , is this ready for review, or is it still WIP?

@paulhendricks i gotta clean up the PRs.  Did a more recent PR solve the mortgage notebook issues?  Or Should i close this one?

Let's close this, I think the mortgage notebook is changing so I'm not sure how relevant these changes are.

authors: ayushdg paulhendricks taureandyernv

repo: rapidsai/notebooks


text:
[WIP] Update blazing params, add ORDER BY instead of bc.partition() for q10, q18 and q19

This PR update some BlazingSQL params as add some others.
This PR also avoid the use of bc.partition() , instead of that uses ORDER BY statement. As well, add a couple of dels  after drop tables. Finally add a line of code ( config["protocol"] = str(url)[0:3] ) just for tracking protocool.
Tested at sf 1K on the dgx201
(bsql-tpcx) christianc@rl-dgx2-d17-u05-rapids-dgx201:~/tpcx-bb/tpcx_bb$ python benchmark_runner.py --config_file=/home/christianc/yaml_dir/benchmark_1k_w_validation.yaml
['10', '18', '19']
Using default arguments
Connected to tcp://10.150.162.27:8786
BlazingContext ready
Blazing Queries
10
/home/christianc/miniconda3/envs/bsql-tpcx/lib/python3.7/site-packages/cudf/core/column/string.py:700: UserWarning: `n` parameter is not supported when `pat` and `repl` are list-like inputs
  "`n` parameter is not supported when "
/home/christianc/miniconda3/envs/bsql-tpcx/lib/python3.7/site-packages/cudf/core/column/string.py:700: UserWarning: `n` parameter is not supported when `pat` and `repl` are list-like inputs
  "`n` parameter is not supported when "
Sentiment Analysis Query
96.73181084836891% overlap with 6329652 rows (RAPIDS denominator)
97.47078162728856% overlap with 6281664 rows (Spark denominator)
Correctness Assertion True
18
/home/christianc/miniconda3/envs/bsql-tpcx/lib/python3.7/site-packages/cudf/core/column/string.py:700: UserWarning: `n` parameter is not supported when `pat` and `repl` are list-like inputs
  "`n` parameter is not supported when "
Sentiment Analysis Query
95.8086979543316% overlap with 1533533 rows (RAPIDS denominator)
95.90632204766145% overlap with 1531972 rows (Spark denominator)
Correctness Assertion True
19
/home/christianc/miniconda3/envs/bsql-tpcx/lib/python3.7/site-packages/cudf/core/column/string.py:700: UserWarning: `n` parameter is not supported when `pat` and `repl` are list-like inputs
  "`n` parameter is not supported when "
Sentiment Analysis Query
92.88446915692424% overlap with 84168 rows (RAPIDS denominator)
93.39489654513308% overlap with 83708 rows (Spark denominator)
Correctness Assertion True

looks good to me

Configuration changes:

BLAZING_DEVICE_MEM_CONSUMPTION_THRESHOLD and BLAZ_HOST_MEM_CONSUMPTION_THRESHOLD are both directly related with the GPU and HOST memories consumption respectively (as decimal values).
MAX_KERNEL_RUN_THREADS: The number of threads available to run kernels simultaneously. Increasing high this value can cause OOM problems.
TABLE_SCAN_KERNEL_NUM_THREADS: The number of threads used when reading data.
MAX_NUM_ORDER_BY_PARTITIONS_PER_NODE and ORDER_BY_SAMPLES_RATIO :  Related with the number of partitions and his size when a ORDER BY is applied.
MAX_SEND_MESSAGE_THREADS : The number of threads available to send outgoing messages.
MEMORY_MONITOR_PERIOD : How often the memory monitor checks memory consumption. Value in milliseconds.
LOGGING_LEVEL:  Level (as string) to register into the logs. Log levels have order of priority: {trace, debug, info, warn, err, critical, off}

To have more details about BlazingSQL params, please check this link https://docs.blazingdb.com/docs/blazingcontext

repo: rapidsai/tpcx-bb


text:
Context Manager and General Cleanup

Added self.camera_num  to class instantiation. This would mean that users would need to call and assign different names to a new Picamera2 class to use two cameras.
Changed open_camera to open to stay in tune with start,, stop ,close etc. I don't know if it is bad form to use it in a class.
Added enter and exit to allow for use of Picamera2 in a with statement.
Created conversions.py for file or buffer conversions that don't necessarily require Picamera2.
Changed camera_manager attribute to cm to reduce number of characters per line.
Changed verbose_print to __verbose_print so it can't be called by a user.
Changed start_, stop_ to __start, __stop so it can't be called by the user and to limit confusion when using interactive IDEs.
Added initialize and acquire functions to give more flexibility to developers.
Changed time.time() to time.monotonic() to remove interference with clock changes (although unlikely).
Added reset_flags, which could probably be made private.
Minor changes to messages displayed with errors.
Added camera id (cid) and camera index (cidx) to initialize. This gives the class access to camera identifying information that the user may not know or may input incorrectly at instance creation.
Moved self.sensor_resolution to still_configuration function because it had the only usage.
Cleaned up some lines to bring them close to pep8.

I now see a mistake with moving self.sensor_resolution, so that can be moved back to open().

Hi, thanks very much for doing all this. I'd like to adopt most of these changes, perhaps there are a few where we might think about exactly how to present them.
Mostly I think I'd like to split up the commits so that it's clear what each one is. Perhaps we could have a "PEP8" commit on it's own? Commits that just rename variables and functions might be separate from ones that rearrange code, perhaps. Also perhaps we could remove any diffs that do absolutely nothing (e.g. deleting newlines from the ends of files).
The purpose is simply to start making commits easier to review and to follow over time. I appreciate that things have been a bit random in the rush to get something out there for folks to try, but I would like to start improving the process a little. What do you think?

Can do.  I'll work on separating them out over the next couple of days. If you see anything else, let me know.

authors: IanTBlack davidplowman


text:
chore: update dependencies

Only thing I couldn't update yet is
Package            Current  Wanted  Latest  Location                        Depended by
@nextui-org/react    2.4.2   2.4.8   2.4.8  node_modules/@nextui-org/react  raspiblitz-web

In the new version, it ignores the secondary style somehow so the buttons in the settings page look purple.

Can try to update next-ui

authors: cstenglein escapedcat

repo: raspiblitz/raspiblitz-web


text:
Google started to require us to put APPLICATION_ID in AndroidManifest.xml from 05/10/2018

Hi, just found out that Google put a new requirement for using the Admob on 5/10/2018. Failed to do so would not be able to start the app.
I got the following error when I started the app on the real device. The App crashed right away while it started.
10-12 05:03:40.008 10510 10510 E AndroidRuntime: ******************************************************************************
The Google Mobile Ads SDK was initialized incorrectly. AdMob publishers
should follow the instructions here: https://goo.gl/fQ2neu to add a valid
App ID inside the AndroidManifest. Google Ad Manager publishers should
follow instructions here: https://goo.gl/h17b6x.

Reference link:
https://developers.google.com/admob/android/quick-start#update_your_androidmanifestxml
I tried to follow the instruction by putting the Application Id and the Admob Id to my AndroidManifest.xml. But it didnt help. Is there any way we could get around of this with the current version of Admob plugin?
Would the upcoming cordova-plugin-admob-free support this requirement?

This has been addressed. Thanks very much.
https://github.com/ratson/cordova-plugin-admob-free#installation

This has been addressed. Thanks very much.
https://github.com/ratson/cordova-plugin-admob-free#installation

If the app should work on both iOS and android, should I install with android ID for both platforms? what should i do with iOS later? change manually?

repo: ratson/cordova-plugin-admob-free


text:
I can't seem to get any ad to work.

I've tried for quite some time now but i cant seem to get any ad to work. Can I get some help please?
This is my code.

banner demo

Show

What kind of errors do you have?

Close as no reply.

authors: jhonoi ratson vintage


text:
[Bug] Custom css not loading from save in detached window

Describe the Bug
The custom css window shows up empty (doesnt load the saved css).
To Reproduce

Save any custom css
Set the Custom CSS Editor Location to Detached Window
Open the Custom CSS editor

Expected Behavior
It should load.
Screenshots

Discord Version
Stable 81171 (2a43a4e)
BD 1.0.0 (stable)
Host 0.0.14
Injector 0.6.0
Linux 64-Bit (5.10.0-5-Amd64)

Enable live update or save your changes before detaching.

Fixed in this commit https://github.com/rauenzi/BetterDiscordApp/commit/a2238060607a98720b761672f603bbff4a40f99b
It will go live in the next update

authors: Tropix126 WIPocket rauenzi

repo: rauenzi/BetterDiscordApp


text:
Emote menu semi-rewrite

This PR rewrites a good portion of the new emote system (mainly UI related fixes).

Light mode support
A lot of consistency fixes (arrows flipping the wrong directions, coloring, interaction, spacing, classnames, etc...)
Removal of some old or redundant code
Class restructure in the emote picker.

This doesn't affect the emote components in chat. I'd be willing to rewrite them, but it looks like the .jumboable classname is broken and therefore i can't do much to make it consistent with discord's design.

temp closing due to some unexpected bugs


text:
🛑 Gestion is down

In b32753c, Gestion (https://gestion.funsadu.ar/Radius/) was down:

HTTP code: 500
Response time: 325 ms

Resolved: Gestion is back up in c8d9d9d after 18 minutes.

repo: raulredes/funsadu


text:
[Bug][Doc] Increase default operator resource requirements, improve docs

Search before asking

[X] I searched the issues and found no similar issues.

KubeRay Component
ray-operator
What happened + What you expected to happen
We have some indication from users that the default resource limits for the KubeRay operator may be too small when managing many Ray pods.
See the discussion here: https://ray-distributed.slack.com/archives/C02GFQ82JPM/p1667409518664019

Increase the default resource limits
Document the fact that users need to observe resource usage and adjust as needed.

Reproduction script
See linked Ray Slack discussion thread.
Anything else
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

We did see some OOM issue internally and bump the resources in downstream. I think this would be helpful

We did see some OOM issue internally and bump the resources in downstream. I think this would be helpful

Any data you could share?
(e.g. how many pods managed and what resource limits you're using?)

authors: DmitriGekhtman Jeffwan

repo: ray-project/kuberay


text:
[Feature] Deterministic hostname for each Ray worker

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
Currently, the name of a Ray worker is generated randomly. However, a deterministic hostname for each Ray worker can benefit the following use cases:

TLS authentication: Because Ray workers do not have deterministic hostnames, we need to create the certificates whenever a worker restarts. Some users want to create a certificate once and use it multiple times. See this thread for more details.

"Currently our cert infra does not even consider IP as a reasonable part of the x509 certificate SAN" (link)

TPU support: TPU workers in Jax needs to directly communicate with each other using an open port

Use case
No response
Related issues
https://github.com/ray-project/kuberay/issues/908
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Discussed with the Ray team (@richardliaw ) and the Google Cloud TPU team. The current plan for JAX[TPU] support is to include the following code snippet to set the TPU_WORKER_ID and TPU_HOSTNAMES environment variables on Ray nodes:
NUM_TPU_HOSTS = 32

@ray.remote(resources={"google.com/tpu": 4})
def get_hostname():
    import time; time.sleep(1)
    return socket.gethostname()

results = ray.get([get_hostname.remote() for x in range(NUM_TPU_HOSTS)])
id_hostname_map = {
    hostname: worker_id for worker_id, hostname in enumerate(set(results))}

@ray.remote(resources={"google.com/tpu": 4})
class TPUTrainingActor:
    def __init__(self, id_hostname_map):
        self.hostname = socket.gethostname()
        self.worker_id = id_hostname_map[self.hostname]
        os.environ["TPU_WORKER_ID"] = str(self.worker_id)
        os.environ["TPU_HOSTNAMES"] = ",".join(list(id_hostname_map))

    def train(self):
        ...

The longer term plan is to add this to the ray.train libraries. This is similar to the current pattern used for pytorch training:  https://github.com/ray-project/ray/blob/master/python/ray/train/torch/config.py#L155

Close this issue because the Ray community will provide a solution for TPU support.


text:
Fix for deploy error with deprecated cli

Why are these changes needed?
CLI is being deprecated and this removes the file that was causing the deploy ci step to fail. Also removed residual cli/ mentions in the repo.
Related issue number

Checks

[ ] I've made sure the tests are passing.
Testing Strategy

[ ] Unit tests
[ ] Manual tests
[ ] This PR is not tested :(

@kevin85421

authors: andrewsykim chiayi


text:
Added formatting keymaps in README

Added the keymaps in README which were missing.

Tysm for merging, this was my first pull request.


text:
[Color Picker] Add color value to Color Picker

Extension
https://www.raycast.com/thomas/color-picker
Description
My most common use case is to confirm that a color is the correct value and often don't need to copy it. I currently use ColorSlurp's color picker for this (see screenshot) but would love to be able to use this extension.

Who will benefit from this feature?
Anyone who wants to confirm a color is correct without first having to copy it.
Anything else?
No response

I will look into it

Example repo that has live sampling (among other features) https://github.com/danielcapra/SCColorSampler

authors: aliaksandrZh tmm tomgenoni

repo: raycast/extensions


text:
Update pipedrive extension

Description

Updates the dependencies
Makes the org name copyable

Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hi!
Thank you for your contribution! My name is Milena and I will be reviewing it today.
I'm having trouble testing your changes as nothing loads when I try the extension. @ahpatel do you mind testing this and telling us if you are okay with the changes?

@mil3na doing a quick skim of the changes, there is some code missing for executing the shortcut Action.  And, there is probably an updated library that broke something.
I am traveling through the end of the month and don't have access to my device to test so I won't be able to look at it until I return in August.

@mil3na there looks to be some code missing for the shortcut Action.  And, the blanket library updates likely broke something.
I am traveling through the end of the month so won't have a chance to look at it until I return in August.  But, should be an easy add once I review.

@ahpatel it'd appreciate your feedback on this.

This functionality already exists, using Cmd+N from the action menu.
@cimnine - are you not able to use the existing functionality?

@ahpatel are you back yet?

@pernielsentikaer yes, I'm back.  Please reject these changes.  I have an implementation I was using locally for the last few months and will publish the changes this week.

Will it cover what @cimnine is doing and please add cmdr as contributor

authors: ahpatel cimnine mil3na pernielsentikaer