text:
[BUG] Harvester management URL shows Unavailable in the console

Describe the bug
After installation the console shows:

Log
Logs in /var/log/console.go:

Environment:

Harvester ISO version: v0.1.0-rc2

I have the same problem，URL is unavailable，status is settingup...

Can you access the UI by https://<node-ip>:8443?

Can you access the UI by https://<node-ip>:8443?

node-ip ？I can't , it seems that static ip cannot be configured，my previous ip eth0 is 200.201.9.128，now ip eth0 is 169.254.45.193，the network segment has changed.

DHCP service is required at the moment, static IP support is tracked in https://github.com/rancher/harvester/issues/367

DHCP service is required at the moment, static IP support is tracked in #367
root@colibri-t30:~# connmanctl
connmanctl> config ethernet_00142d259a48_cable --ipv4 manual 192.168.10.2 255.255.255.0 192.168.10.1
connmanctl> exit
like this, I configured the static IP， --ipv4 manual 200.201.9.128 255.255.248.0 200.201.15.254，the status changed to running state，but still can't ping.

okay! thank you very much,I reboot the host,
it's succeessful!now，not only can ping, but can also log in dashboad！

link to PR https://github.com/rancher/harvester-installer/pull/47

Validated on master-head, that kind of error messages were not found.

authors: DoNotSayYes DreamTeamWangbowen gitlawr guangbochen

repo: rancher/harvester


text:
ship Toolbox (or similar) to allow users to bring their own debugging tools

K3OS is a stripped down, immutable operating system offering very few tools beyond busybox and curl.
This is unquestionably a feature. However, if a user wished to debug processes on the system with tools like tshark, gdb, valgrind, etc, this would require them to build and deploy their own rootfs today to bring their own tools.
In Fedora CoreOS and RHEL they ship a script called Toolbox that gives users a way to manage container environments with their own tools.
https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/
Pros:

reads a config file to allow you to use any container base
keeps the state of your container around (a pet container)
can do things unprivileged if this matches the use case

Cons:

requires podman, which is not packaged in Alpine today.

Something you can do with the included tooling right now...
${runc} image pull docker.io/library/ubuntu:latest
${runc} run --privileged --net-host -t docker.io/library/ubuntu:latest ubuntu bash

@bhale ctr looks a multi-call target for k3s. see the output from k3s ctr --version / k3s ctr --help

@bhale ctr looks a multi-call target for k3s. see the output from k3s ctr --version / k3s ctr --help

Nice. Fixed that.

source: gharchive/issue

authors: bhale dweomer

license_type: permissive

license_source: github-api


text:
Allow flannel interface to be specified on the command line

This should fix #200 and #72.
I am having issues building this on my local system to test properly as dapper keeps flaking out. I am hoping someone can review this while I try and fix dapper.

I've now completed testing this. My dapper problems were caused by an out-dated version of Docker.
Test setup
2 Ubuntu VMs with a GRE tunnel configured.
Test 1
Run k3s as per the quick start instructions on k3s.io:
        sudo k3s server &
        # Kubeconfig is written to /etc/rancher/k3s/k3s.yaml
        sudo k3s kubectl get node

        # On a different node run the below. NODE_TOKEN comes from /var/lib/rancher/k3s/server/node-token
        # on your server
        sudo k3s agent --server https://192.168.1.24:6443 --token ${NODE_TOKEN}

Check agent log file to ensure that default interface is selected for flannel. Run a simple load and monitor network traffic using iftop.
Test 2
Run k3s specifying tunnel IP and flannel interface:
        sudo k3s server --node-ip 10.10.10.1 --flannel-iface gre1 &
        # Kubeconfig is written to /etc/rancher/k3s/k3s.yaml
        sudo k3s kubectl get node

        # On a different node run the below. NODE_TOKEN comes from /var/lib/rancher/k3s/server/node-token
        # on your server
        sudo k3s agent --server https://10.10.10.1:6443 --flannel-iface gre1 --node-ip 10.10.10.2 --token ${NODE_TOKEN}

Check agent log file to ensure that gre1 interface is selected for flannel. Run a simple load and monitor network traffic using iftop.
Result
Both tests behaved as I expected.

Resolved conflicts

@galal-hussein can you review this?

@galal-hussein Commits squashed. Thanks!

source: gharchive/pull-request

license_source: bigquery


text:
Ansible: Test for Raspbian before assuming

What's changing
Adds a test for the Raspbian OS -specific file before assuming file can be modified.
Why
Currently the role assumes /boot/cmdline.txt file exists.
On other ARM OS's (Armbian) it does not, nor does it need editing.

Works for me!

authors: itwars tamsky


text:
WIP: Gke private cluster

Add the ability to set private clustets in GKE.  This also means that we
must give the user the ability to set the master ip range and also the
networks and subnets.
Depends on:
https://github.com/rancher/types/pull/473
Issue:
https://github.com/rancher/rancher/issues/13980

This feature went GA with GCP yesterday.
Is it worth while having a NAT gateway provisioned as part of this process so the worker nodes can access the web? Or is it assumed the user will have configured the VPC themselves?

close in favor of https://github.com/rancher/kontainer-engine/pull/106

authors: cjellick imduffy15 nathan-jenan-rancher

repo: rancher/kontainer-engine


text:
Allow the installer to set the disk to bootable

Please see my tweet for reference.
After 2.5hrs of trying to get the server to boot, turns out sysadmin stuff is hard and I didn't set the boot flag on the disk. So, this would be nice to have the install script handle the boot flag when it installs to the target disk.

Well shucks... that's a simple one to fix.  Just curious what's your configuration?  What actually needs that flag set?  Typically it's only read by legacy boot loaders and we install grub to the disk root.  So honestly didn't think we needed it.

@ibuildthecloud Created a bootable USB ISO via sudo dd if=... of=... and than booted up by USB on the HP MicroServer. I did originally have the RAID config set to AHCI if that makes any difference?
From there I simply ran the sudo ros inst... command.
I will however try to re-install ROS with my RAID config if that helps?

Hi,
I have been fighting hours to get rancheros installed on my HP microserver...
Not only ros install does not set the bootable flag, it also removes it!
@ibuildthecloud The reason why we need this is that on these servers, a typical setup is the following : 4HDD in the front bay front storage + 1 SSD  in the ODD bay on the 5th SATA connector.
Problem : when in AHCI, the 5th SATA is not bootable (only the first HDD of the first controller (front bay) is).
The only other options are to boot from USB (Internal/External/SDslot) and have your system here (or on the SSD)

@fbndsprz v0.8.0 replaces that install code (fdisk) with parted - though its not currently configurable.
I've got a HP microserver - waiting for me to get back home - but I generally boot from USB

authors: NigelGreenway SvenDowideit fbndsprz ibuildthecloud

repo: rancher/os


text:
add support for volume plugins

@ibuildthecloud The tests require docker1.9 dind to work.

Cover:
activate
deactivate
remove
But consider we need to keep 1.18 API behavior for remove.

repo: rancher/python-agent


text:
User vs group

https://github.com/rancher/rancher/issues/8744

Note to self: dont merge until vendor is updated to nonfork

LGTM

authors: cjellick mrajashree

repo: rancher/rancher-auth-service


text:
Import YAML from url in UI

Rancher versions:
rancher/rancher:2.0.2
In workaload--> import YAML
include option to import YAML from URL

I think we need backend to provide the API for importing YAML from URL. There is a whitelist in rancher magic proxy. So UI can not use it for this.

authors: Itiho loganhz

repo: rancher/rancher


text:
iscsi persistent volume requires secret even when no auth is selected

Rancher versions:
rancher/server or rancher/rancher: 2.0.4
Steps to Reproduce:

create a persistent volume of type iSCSI Target
fill in required fields

IQN is a required field but not indicated as such

fill in IQN and target portal
leave chap discovery and auth set to No
save

Results:
spec.iscsi.secretRef.name: Required value

Can you try to use kubectl, please? It's a k8s limitation. User has to config it.
spec.volumes[0].iscsi.secretRef: Required value

authors: loganhz oskapt


text:
The Resource quotas  display error when editing the namespace

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
1.add a project

2.add a namespace

3.edit this namespace
Result:
as shown,the other namespaces is a,but there is only one namespace actually.

Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
Installation option (single install/HA):
single install

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):
Machine type (cloud/VM/metal) and specifications (CPU/memory):
Kubernetes version (use kubectl version):

(paste the output here)

Docker (use docker info):

(paste the output here)

I can confirm this issue. In addition, the UI prevents you from increasing the quotas, if the "other" workspaces takes up the remaining resources.
Thus, if you have one namespace using half the resources, you cannot increase the quotas for this namespace in the UI.

same issue on v2.1.1 install from helm

Thanks for the report
Fixed in https://github.com/rancher/ui/pull/2408
It will be out in v2.2

authors: dongjuanwinhong loganhz myclau rustymunkey


text:
Create user with uppercase letters works, but local login doesn't

What kind of request is this (question/bug/enhancement/feature request):
You can create users that can't log in
Steps to reproduce (least amount of steps as possible):

create user with uppercase characters using the rancher UI
logout
login with new user

Result:
Login doesn't work
Other details that may be helpful:
When I removed the user and created the same without uppercase chars it worked
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): 2.1.1
Installation option (single install/HA): HA

I can not reproduce this issue by the following steps:

Start rancher with command docker run -d -p 80:80 -p 443:443 rancher/rancher:v2.1.1
Login as default admin user
Create a user with username ABCd, and choose Standard User
Logout admin user
Login with ABCd

Did I miss something?

Good question :-)

I created a user with the name deployment-TEST-infra and used custom rights. The user has only login right on rancher and then more rights on some cluster.

I can reproduce this issue in v2.2.1 by the following steps:

Create a user with username deployment-TEST-infra and global custom role with Login permission only
Enable Github auth
Logout default admin
Try to login deployment-TEST-infra with local auth

It works in rancher/rancher:master

Reproduction in rancher:v2.1.1
Steps:

Started a Rancher Server v2.1.1
Added a user which username is ABC-def-G with custom permission.
Enabled Github auth.
Logout default admin.
Tried to login ABC-def-G with local auth.

Got the following error
Logging in failed: Check credentials, or your account may not be authorized to log in.

Validation on rancher:master 11/16
Did the same procedures as the above with Rancher Server rancher:master on 11/16. And local user can log in successfully.
Bug fix validated.

authors: jiaqiluo loganhz pcornelissen


text:
UI node view does not remove "Control Plane" role label on demotion

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):

Create 3 node RKE k8s cluster with all roles (rke v0.2.0)
Install Rancher 2.2 HA via helm
Remove Control Plane and etcd role for one node in RKE yaml and apply

Result:
Control plane and etcd removed but Control Plane role is still showed on node view.

Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): Rancher 2.2
Installation option (single install/HA): HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): esxi
Machine type (cloud/VM/metal) and specifications (CPU/memory): VM 4 vCPU, 8 GB Ram
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.6", GitCommit:"ab91afd7062d4240e95e51ac00a18bd58fddd365", GitTreeState:"clean", BuildDate:"2019-02-26T12:59:46Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"c27b913fddd1a6c480c229191a087698aa92f0b1", GitTreeState:"clean", BuildDate:"2019-02-28T13:30:26Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version): 18.6.1

@sangeethah can we try to reproduce the issue and if reproduced, check if it existed in 2.1.x line.

rancher/rancher:v2.2.0
rancher/rancher:v2.1.7
I was able to reproduce this in both v2.2.0 & v2.1.7

Created RKE cluster - 3 nodes, all roles
Installed Rancher via helm
Updated local cluster via rke - changing one node to have only worker role
Cluster updates
etcd role is removed
Control Plane is still present
kubectl get nodes shows the correct labels

NAME             STATUS   ROLES                      AGE   VERSION
x.x.x.x   Ready    controlplane,etcd,worker   13m   v1.13.4
x.x.x.x   Ready    controlplane,etcd,worker   13m   v1.13.4
x.x.x.x   Ready    worker                     13m   v1.13.4

moving out of v2.2.2

Issue still exists in version 2.4.3 too.


text:
decompressed etcd backups not removed on restore

What kind of request is this (question/bug/enhancement/feature request): Bug
Steps to reproduce (least amount of steps as possible):

Backup etcd via UI
Restore etcd via UI

Result:

the decompressed file is kept in the filesystem after the restore is done
Expectation: The decompressed file should be removed after the restore ended

root@host (host) [/opt/rke/etcd-snapshots]
# ls -l
total 18328
-rw-r--r--. 1 root root 13422624 Jul 23 08:39 c-nb4mv-rs-8ts89
-rw-------. 1 root root  5340711 Jul 23 08:39 c-nb4mv-rs-8ts89.zip

Other details that may be helpful:
Environment information
Rancher 2.2.5

Merging this into https://github.com/rancher/rancher/issues/21703

authors: OlliL superseb


text:
Add ability to issue cluster and project scoped API tokens for Rancher CLI use

What kind of request is this (question/bug/enhancement/feature request):
Feature reqeust
Details:
API tokens at the moment can be created with either no scope or with cluster scope.
The Rancher CLI works with tokens created with no scope as opposed to those with cluster scope that can only be used with the Authorized Cluster Endpoint.
Adding the ability to generate cluster or project scope tokens for use by Rancher CLI, means permissions will be limited to the cluster/project rather than using global permissions(e.g. in case the user creating the token happens to be Rancher admin).

you can check https://gitlab.com/lfdominguez/rancher_proxy

authors: lfdominguez panacz


text:
Infinite error logging loop caused by App parsing error

When installing or upgrading an App, if there is a parsing error in the chart or it's values, Rancher infinitely logs the failure until the app is deleted or upgraded to fix the parsing error.
While this is happening we are seeing other App install/upgrades sitting in the Deploying state (rather than going to Active) for upwards of an hour. These upgrades normally finish within a couple minutes. The upgrade seems to work right away, just that the status doesn't transition to Active.
What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
rancher app install docker-registry docker-registry --no-prompt --version 1.9.2 --set "value=foo\,bar"

Result:
The App should show a parsing error in the UI

Server logs are full of errors like these
2020/05/14 17:58:35 [ERROR] AppController p-qsxvn/docker-registry [helm-controller] failed with : wait helm template failed. Error: failed parsing --set data: key "bar" has no value (cannot end with ,)
: exit status 1
2020/05/14 17:58:35 [ERROR] AppController p-qsxvn/docker-registry [helm-controller] failed with : wait helm template failed. Error: failed parsing --set data: key "bar" has no value (cannot end with ,)
: exit status 1
2020/05/14 17:58:35 [ERROR] AppController p-qsxvn/docker-registry [helm-controller] failed with : wait helm template failed. Error: failed parsing --set data: key "bar" has no value (cannot end with ,)
: exit status 1
2020/05/14 17:58:35 [ERROR] AppController p-qsxvn/docker-registry [helm-controller] failed with : wait helm template failed. Error: failed parsing --set data: key "bar" has no value (cannot end with ,)
: exit status 1

Other details that may be helpful:
Environment information

Rancher version: v2.4.2, v2.4.3
Installation option: HA

Cluster information

Cluster type: Imported
Machine type: Cloud
Kubernetes version: v1.15.11-eks-af3caf

How can I delete such failed installation?

Related to https://github.com/rancher/rancher/issues/27146

authors: Ilya-Kuchaev kevinfrommelt-wf


text:
Grafana with persistence enabled will not seamlessly upgrade

What kind of request is this (question/bug/enhancement/feature request):
enhancement
Steps to reproduce (least amount of steps as possible):
Launch cluster-monitoring or project-monitoring v0.1.0 with persistence enabled for Grafana
Upgrade chart to v0.1.1
Result:
The replacement Grafana pod in the deployment is created before the original pod is deleted, resulting in a stuck upgrade as the PVC is still bound to the first pod.
Other details that may be helpful:
maxSurge is currently undefined in the chart, so defaults to 25%. Changing to 0% should resolve this.
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
v2.4.5
Installation option (single install/HA):
HA

gz#10888

Relating to https://github.com/rancher/rancher/issues/27450

closed. duplication of https://github.com/rancher/rancher/issues/27450

authors: jiaqiluo ryanelliottsmith sangeethah


text:
Update the packaging of charts and partner charts

Currently only charts.rancher.io is automatically added into Rancher, but it's not added as the correct repo level.

Needs to be moved to cluster scoped repo
Need to have charts.rancher.io and partner-charts.io

Rancher version `master-head (08/12/2020) d19f179c4
This is what we see
https://git.rancher.io/partner-charts dev-v2.5
https://git.rancher.io/charts dev-v2.5
And we're still not able to deploy charts in clusters other than the local HA.
https://github.com/rancher/rancher/issues/28159

The dev-v2.5 should be fine, thats just what branches are set at: https://github.com/rancher/rancher/blob/master/package/Dockerfile#L17
Believe that after the other bug mentioned here is fixed, this should be gtg.

authors: cbron deniseschannon izaac


text:
[Monitoring V1] can not upgrade from 0.1.4 to v0.2.0

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):
Path 1:

run rancher:v2.5.3 single-install
add a cluster with supported version
enable the cluster monitoring 0.1.4
upgrade rancher to v2.5-head  3d7ffc
upgrade monitoring from 0.1.4 to 0.2.0

Path 2:

run rancher:v2.5-head  3d7ffc single-install
add a cluster with supported version
enable the cluster monitoring 0.1.4
upgrade monitoring from 0.1.4 to 0.2.0

Path 3:

run rancher:v2.5.3 single-install
add a cluster with supported version
enable the cluster monitoring 0.1.4
change the branch of system-library to dev-v2.5
upgrade monitoring from 0.1.4 to 0.2.0

Result:
Failed to upgrade the monitoring because the following 2 PUT requests failed

And the responses are the same

no error shows in Rancher's logs

Once this bug is fixed, the following will be checked after upgrading the monitoring

[ ] Monitoring continue working
[ ] CRD api version is changed to apiextensions.k8s.io/v1
[ ] Memory request for Prometheus Operator has been updated to 100m
[ ] two new images are used

A couple things from the UI side, short of some small changes for a dependency update (framework syntax changes) there have been no major updates to the code controlling this area. I did investigate a bit more and tested an upgrade from 0.1.3 -> 0.1.4 and the upgrade succeeds without error. It seems to be related to the 0.2.0 upgrade only. Additionally I was able to upgrade a traditional Wordpress app without issue which I added as a sort of control.
The UI flow to upgrade Monitoring is as follows:
POST to cluster action editMonitoring with the payload containing only the answers object
PUT to project app cluster-monitoring with the payload containing only the new externalId and targetNamespace.
PUT to project app monitoring-operator with the payload containing only the new externalId and targetNamespace.
POST to cluster action viewMonitoring  with the payload containing only the action viewMonitoring
The two PUT calls fail with the same error above but no additional info.
I am not 100% sure why the monitoring UI doesn't upgrade the app like the traditional global and project apps but I suspect it has to do with the custom backend that we wrote to tie all this together. The difference being the traditional apps use an upgrade action where here we're doing everything by sending the external id's. Initially this doesn't seem to be related to any specific UI change.

@guangbochen @aiwantaozi would you have any insight into why we're seeing this error?

@aiyengar2 This seems to be an existing problem, but because we added kubeVersion: ">=1.16.0-0" to Chart.yaml of 0.2.0, it was triggered.
we can check here
https://github.com/rancher/rancher/blob/master/pkg/catalog/manager/manager.go#L215-L227
the clusterName here is empty, which results in failure to get the cluster
https://github.com/rancher/rancher/blob/master/pkg/api/norman/store/app/store.go#L69-L70
I think it will be fixed if add parameter projectId when UI PUT to project app cluster-monitoring and monitoring-operator

@GGGitBoy Thanks for the info that worked like a charm!

Tested with rancher server version - v2.5-e2295c

Add a cluster
Enable the cluster monitoring 0.1.4
Upgrade monitoring from 0.1.4 to 0.2.0

Able to upgrade to 0.2.0 successfully.

Steps:

run rancher:v2.5.3 single-install
add a cluster with supported version
enable the cluster monitoring 0.1.4
enable the project monitoring 0.1.4
upgrade rancher to v2.5-head e2295c
upgrade cluster monitoring from 0.1.4 to 0.2.0
upgrade project monitoring from 0.1.4 to 0.2.0

Results:

the upgrade succeeds
projectId is in the payload of the PUT request

authors: GGGitBoy aiyengar2 jiaqiluo sangeethah westlywright


text:
Not able to create ingresses on amazon ec2 node driver clusters in an HA rancher on 1.20 cluster

Information about the Cluster
Rancher Server Setup

Rancher version: v2.5.11
Installation option (Docker install/Helm Chart): Helm Chart

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE1, v1.20.12-rancher1-2, 1.2.14

Proxy/Cert Details: Selfsigned

Information about the Cluster

Kubernetes version: v1.20.12
Cluster Type (Local/Downstream): Downstream node driver 1 worker, 1 etcd, 1 cp RKE1

Describe the bug
Creation of ingress on an AWS node driver cluster created on a rancher HA server does not go through and errors out with Failed calling webhook error. More details in the result and additional info.
To Reproduce

Create a rancher HA server on v2.5.11
Create a downstream RKE1 node driver Amazon EC2 cluster with any node count
From any project create a workload
Create an ingress pointing to this workload

Result
The ingress creation does not go through and it errors out
baseType: "error"
code: "InternalError"
message: "Internal error occurred: failed calling webhook \"validate.nginx.ingress.kubernetes.io\": Post \"https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1beta1/ingresses?timeout=10s\": context deadline exceeded"
status: 500
type: "error"

Expected Result
Expected the ingress creation to go through without any error.
Additional context

This is not seen on node driver RKE DO clusters on HA or custom clusters
Not seen on docker install DO,Amazon ec2 or custom clusters.
Only seen on Amazon ec2 node driver HA.
Also not seen on clusters on k8s v1.19.16

Errors seen in the rancher logs:

 7 warnings.go:80] extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
W1204 02:19:48.667464       7 warnings.go:80] extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
W1204 02:20:04.308015       7 warnings.go:80] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition
W1204 02:22:02.682439       7 warnings.go:80] extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
W1204 02:26:15.307942       7 warnings.go:80] apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinition

2021/12/04 02:04:45 [ERROR] error syncing 'ingress-ip-domain': handler copy-settings: the server could not find the requested resource, requeuing
2021/12/04 02:04:45 [ERROR] error syncing 'install-uuid': handler copy-settings: the server could not find the requested resource, requeuing
2021/12/04 02:04:45 [ERROR] error syncing 'ingress-ip-domain': handler copy-settings: the server could not find the requested resource, requeuing
2021/12/04 02:04:45 [ERROR] error syncing 'install-uuid': handler copy-settings: the server could not find the requested resource, requeuing
2021/12/04 02:04:45 [ERROR] error syncing 'ingress-ip-domain': handler copy-settings: the server could not find the requested resource, requeuing

Errors seen in ingress-controller:
E1204 02:26:15.592042       6 server.go:77] "Failed to decode request body" err="couldn't get version/kind; json parse error: unexpected end of JSON input"
2021/12/04 02:26:16 http: TLS handshake error from :38364: read tcp 172.31.13.232:8443->:38364: read: connection reset by peer
E1204 02:26:17.685127       6 server.go:77] "Failed to decode request body" err="couldn't get version/kind; json parse error: unexpected end of JSON input"
E1204 02:26:17.758252       6 server.go:77] "Failed to decode request body" err="couldn't get version/kind; json parse error: unexpected end of JSON input"
 - - [04/Dec/2021:02:26:45 +0000] "GET /v3/connect/config HTTP/2.0" 200 19691 "-" "Go-http-client/2.0" 2902 0.010 [cattle-system-rancher-80] [] 10.42.0.6:80 19704 0.012 200 69048a76b18c5e7762850db3ecb19c5d
 - - [04/Dec/2021:02:27:40 +0000] "GET /v3/connect/config HTTP/2.0" 200 19708 "-" "Go-http-client/2.0" 2900 0.007 [cattle-system-rancher-80] [] 10.42.2.6:80 19721 0.008 200 73e8898aea23c402278561bdbec31eaa

@samkulkarni20 Can we confirm that this is still an active issue on 2.5-head?

@anupama2501 This issue is working as expected on 2.5 head.
Setup configuration:
Rancher server setup:

Installation option : Helm chart.
If Helm Chart, Kubernetes cluster and version : RKE1, rke:1.2.15-rc1, kubernetes:v1.20.13-rancher1-1

Information about the Cluster:

Kubernetes version: v1.20.12
Cluster Type (Local/Downstream): Downstream node driver 1 worker, 1 etcd, 1 cp RKE1

Steps taken to validate:

Create a rancher HA server on 2.5-head
Create a downstream RKE1 node driver Amazon EC2 cluster with any node count
Create a nginx deployment
Create an ingress pointing to this nginx workload.
The service must be accessible at <node_ip>/index.html

Result:
The ingress creation goes through without any errors.
cc: @deniseschannon @samkulkarni20

This issue is seen on 2.6-head commit id: e62e1ae

Cluster - AWS EC2 rke1 k8s version - v1.20.13
Ingress created through v2 API gives the error:

Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1beta1/ingresses?timeout=10s": context deadline exceeded

Seeing this on v2.6.2 k8s 1.19.16-rancher1-2 AWS node driver SLES and post upgrading the rancher server to 2.6-head e62e1ae on the cluster
But not on fresh install of the cluster AWS node driver SLES on k8s 1.19.16-rancher1-2 on 2.6-head e62e1ae.

Couldn't reproduce the issue with the following set up:
Rancher version: 2.5.11
Rancher cluster type: HA
Docker version: 20.10
Downstream cluster type: aws ec2 node cluster
Downstream K8s version: 1.20.12
I have two  downstream clusters: rhel and ubuntu (3etcd, 2 cp, 3 workers)

Testing:

Create a rancher HA server on 2.5.11

Create a downstream RKE1 node driver Amazon EC2 cluster with any node count (see info about clusters above)

Create a deployment

Create an ingress pointing to this workload
ingresses are created
i can curl services

Upgrade

i still can curl services

NOTE:
Running automation jobs for pre-upgrade/post-upgrade which create and check Ingresses passed for both downstream cluster

I wasn't able to reproduce this on 2.6. This is what I tried, guided by this:

Installed rancher v2.6.2 on single-node k3s cluster with helm chart
Created a single-node RKE v1.19.6-rancher1-2 cluster on Amazon EC2 infrastructure provider

I tried using the default AMI and also tried overriding with ami-0174313b5af8423d7 which is the public SLES 15 SP2 image

Navigated to the Ember UI
Created a workload using image nginx:latest and exposing port 80
Created an ingress resource with cluster IP pointing to the workload
Workload and ingress came up successfully, clicking the ingress URL correctly forwards me to the nginx welcome page
Upgraded Rancher to v2.6-head
Existing ingress still works
Created a second ingress which also works
No errors seen in the rancher logs or ingress controller logs

Is there anything else I might be missing that could reproduce this?

I was able to reproduce this in rancher. The trick seems to be using a cluster with more than 2 nodes.
I was also able to reproduce this without rancher, with rke alone. So I think this issue should be transferred to the rke team.
Repro steps for RKE alone:

Create two EC2 nodes
Create an rke cluster with cluster.yml:

nodes:
    - address: <addr>.us-west-2.compute.amazonaws.com
      user: ubuntu
      role:
        - controlplane
        - etcd
      ssh_key_path: /home/colleen/Downloads/colleen-ec2.pem
    - address: <addr>.us-west-2.compute.amazonaws.com
      user: ubuntu
      role:
        - worker
      ssh_key_path: /home/colleen/Downloads/colleen-ec2.pem
services:
    etcd:
        snapshot: true
        creation: 6h
        retention: 24h
kubernetes_version: v1.20.13-rancher1-1
ingress:
    provider: nginx

Create workload

$ kubectl create deploy nginx --image=nginx:latest --port=80
deployment.apps/nginx create

Create service

$ kubectl create svc clusterip nginx --tcp=80:80
service/nginx created

Create ingress

$ cat ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test1
  namespace: default
spec:
  rules:
  - host: test1.example.com
    http:
      paths:
      - backend:
          service:
            name: nginx
            port:
              number: 80
        path: /
        pathType: ImplementationSpecific
$ kubectl apply -f ingress.yaml
Error from server (InternalError): error when creating "ingress.yaml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1beta1/ingresses?timeout=10s": context deadline exceeded

Also happens with extensions/v1beta1 and networking.k8s.io/v1beta:
$ cat ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test1
  namespace: default
spec:
  rules:
  - host: test1.example.com
    http:
      paths:
      - backend:
          serviceName: nginx
          servicePort: 80
        path: /
$ kubectl apply -f ingress.yaml
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
Error from server (InternalError): error when creating "ingress.yaml": Internal error occurred: failed calling webhook "validate.nginx.ingress.kubernetes.io": Post "https://ingress-nginx-controller-admission.ingress-nginx.svc:443/networking/v1beta1/ingresses?timeout=10s": context deadline exceeded

Extending the timeout in the ingress-nginx-admission validatingwebhookconfiguration doesn't help, nor does changing the apiGroups or apiVersions setting.
This issue seems to be known and unsolved in the upstream ingress-nginx controller: https://github.com/kubernetes/ingress-nginx/issues/5401

Some more debugging information: there's a connection issue between the API server docker container and the nginx-ingress admission controller service. On v1.20.13-rancher1-1 and v1.20.12-rancher1-1, where it's not working:
$ kubectl -n ingress-nginx get svc ingress-nginx-controller-admission
NAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
ingress-nginx-controller-admission   ClusterIP   10.43.127.209   <none>        443/TCP   37m
$ docker exec -it kube-apiserver curl -ivk https://10.43.127.209
*   Trying 10.43.127.209:443...
* TCP_NODELAY set
* connect to 10.43.127.209 port 443 failed: Connection timed out
* Failed to connect to 10.43.127.209 port 443: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to 10.43.127.209 port 443: Connection timed out

On v1.21.6-rancher1-1, where it is working:
$ kubectl -n ingress-nginx get svc ingress-nginx-controller-admission
NAME                                 TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
ingress-nginx-controller-admission   ClusterIP   10.43.102.67   <none>        443/TCP   2m2s
$ docker exec -it kube-apiserver curl -ivk https://10.43.102.67
*   Trying 10.43.102.67:443...
* TCP_NODELAY set
* Connected to 10.43.102.67 (10.43.102.67) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: O=nil2
*  start date: Dec 15 03:31:33 2021 GMT
*  expire date: Nov 21 03:31:33 2121 GMT
*  issuer: O=nil1
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: 10.43.102.67
> User-Agent: curl/7.68.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
HTTP/1.1 400 Bad Request
< Date: Wed, 15 Dec 2021 03:42:46 GMT
Date: Wed, 15 Dec 2021 03:42:46 GMT
< Content-Length: 0
Content-Length: 0

<
* Connection #0 to host 10.43.102.67 left intact

So maybe some problem with the CNI in rke.

Additional notes: seen consistently on EC2 in us-west-2, not seen on GCP or DO. Still seen on EC2 when switching the CNI to Calico from Canal:
...
network:
    plugin: calico
    calico_cloud_provider: aws

Workaround summary for release notes:
On custom clusters with two or more nodes provisioned using the Amazon EC2 infrastructure provider using default settings, a configuration problem causes creation of Ingress resources to fail. Options to work around this are:

Select a cluster version of 1.21 or greater or upgrade the cluster to version v1.21 or greater.
In the EC2 node template, when configuring security groups, instead of selecting "Standard: Automatically create a rancher-nodes group", manually create the security group in the AWS console following the documented port requirements and then additionally allowing incoming access to port 8443 from within the security group, and select that group in "Choose one or more existing groups" in Rancher.

Pretty sure this is because the fix (https://github.com/rancher/rke/pull/2626) we implemented in RKE for this issue was not backported/changed scope as it was added for k8s 1.21 and up but the NGINX ingress version which was initially only used in k8s 1.21 and up was backported to older versions but the fix was not backported.
The fix here is to change the version scope from k8s to NGINX ingress and then scope it to>=0.48.0 (based on the templates) and backport it to Rancher 2.5/RKE 1.2

I see this issue on 2.5.12-rc4, SLES15-sp3 AMI on an AWS node driver cluster with 3 worker, 1 etcd, 1 cp, k8s version v1.19.16-rancher1-2

Moving to Team Area 2 to re-triage.

This issue should no longer be reproducible on 2.6.3 + latest versions from Jan 2022 KDM release (from 2/8/2022).
To fix it in 2.5.x, we would need to backport the fix from https://github.com/rancher/rancher/issues/35754#issuecomment-995566492 to RKE 1.2 and release new version of 2.5.x as RKE 1.2 is vendored in.
Since 2.5.x is EOM (end of maintenance) at this time, it's proposed to close this issue.
@anupama2501 (cc: @sowmyav27), could you please verify this is no longer an issue in 2.6.3 + latest versions from Jan 2022 KDM release and close this issue then?

@rishabhmsra @vivek-infracloud As mentioned by Sergey in this comment, could you please verify this is no longer an issue in 2.6.3 + latest versions from Jan 2022 KDM release and close this issue then?

Validated this on rancher v2.6.3 HA setup.
Rancher Server Setup

Rancher version: v2.6.3
Installation option (Docker install/Helm Chart): Helm Chart

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE1, k8s:v1.22.6, rke:1.3.7

Steps followed :

Provisioned 3 k8s v1.22.6-rancher1-1, v1.21.9-rancher1-1, v1.20.15-rancher1-1 clusters -> ec2 noder driver RKE1 (1-cp, 1-w, 1-etcd)
Deployed nginx with cluster Ip (port 80) in default ns on all downstream clusters.
Created ingress pointing to nginx. Ingress creation was successful.
Accessed <worker-node-ip>/index.html -> getting the nginx welcome page

Result:

Ingress creation was successful and was able to access the nginx.

authors: anupama2501 cmurphy deniseschannon doflamingo721 rishabhmsra sgapanovich snasovich sowmyav27 superseb


text:
remove Conteners from UI

Rancher Version:v0.59.1
Docker Version: 1.7.1 and 1.9.1
OS: CentOS 6.6 and CentOS 7
Steps to Reproduce:

create and start Stack from Sysdig (or sysdig-cloud version) in Library
remove Stack

Results: all containers are removed, but the user interface I see multiple servers hovering disposal container, but no Contener on the server, as in the Rancher was the problem that tried to remove these containers, I brushed rancher database from these Contener UI but they hang-bank (Sorry for bad english)
Expected:How to remove the names of the UI

When containers are in a purged state, they will be removed from the UI. If you click on refresh, it would be removed.
I've just tested this out with v0.59.1 and had no issues with the containers being removed from the UI.

@deniseschannon I know that, and therefore wrote the question, because it does not meet with this problem for half a year of operation Rancher.
For me it is a novelty, but can anyone met this problem

I remove all, from DB by id

authors: Negashev deniseschannon


text:
[BUG] Rancher handler cluster-create deleting secrets in other namespaces related to clusters

Rancher Server Setup

Rancher version: v2.6.5
Installation option (Docker install/Helm Chart): Helm chart RKE2

Information about the Cluster

Kubernetes version: v1.22.9+rke2r2
Cluster Type (Local/Downstream): Local

Describe the bug

We are creating clusters for ArgoCD based on our Rancher clusters by hitting the API and pulling their names, ids, and labels and creating a secret in the argocd namespace with this information.
General layout of the secret is
apiVersion: v1
kind: Secret
metadata:
  generateName: argocd-
  labels:
    app.kubernetes.io/managed-by: my-sync-job
    argocd.argoproj.io/secret-type: cluster
    objectset.rio.cattle.io/hash: ...
    ...Cluster Labels
  name: argocd-generated-name
  namespace: my-ns
type: Opaque
data:
  config: ...Things like access token, CA information, etc.
  name: ...Cluster Name in Rancher
  server: ...ServerURL in Rancher API

We have tried multiple methods to get Rancher to stop deleting the secret such as

Changing the name/generating it
Removing all contents of the secret
Removing all labels of the secret
Removing any annotations of the secret

Everything causes the secret to still be deleted, and we also confirmed its not related to the specific namespace as we cloned the secret to a different namespace and it still deletes it.
The only way we can get Rancher to stop deleting it is to make an OPA rule that deny's the ability to delete the secrets. Of which then puts all of the Clusters in ClusterProvisioning in an errored state with the error of
Failed to delete argocd/argocd-gen-name /v1, Kind=Secret for cluster-create fleet-default/my-cluster-name: admission webhook "validation.gatekeeper.sh" denied the request: [argocd-protection] Cannot delete Secret <argocd-gen-name> since it is set as a protected resource via a special label
This error is on all of our clusters now, except the local one which isn't deleted and seems to be ignored (guessing because it's in fleet-local).
To Reproduce

Create a K8s jobs to automate this process as well as sync things like labels from the API
Run cronjob

Result
Clusters (except the local) synced with this method are automatically deleted after around 30-45 seconds at most.
Expected Result
Nothing should happen.
Additional context
We are using ArgoCD for deployments and are trying to automate the syncing of Rancher cluster object to ArgoCD's cluster secrets.

@ADustyOldMuffin any chance you could share the cronjob and maybe details of how you have automated it?

@Shaked It's just a cronjob that runs the steps in the gist linked above that's about all I can share.

@ADustyOldMuffin that's what I thought. Thank you 🙏

authors: ADustyOldMuffin Shaked


text:
[RFE] Migrate rancher-[save,load]-images.[sh,ps1] functionality to a CLI utility

Is your feature request related to a problem? Please describe.
Currently, it is not possible to mirror a full OCI index using the rancher-save-images and rancher-load-images scripts. This is because of the default behaviour for docker pull, which matches your architecture against the images available in an index and downloads only the image that matches your current architecture.
Another pain point with the current scripts is that there is some code redundancy between these scripts.
Describe the solution you'd like
Have a CLI utility written in Golang to perform these tasks in a way that causes less divide between the Windows and Linux versions of the script, allow for better automated testing, and allow performing more complex tasks when copying the images. Examples of such tasks would be copying to more than a registry at a time and copying full OCI indices.
Describe alternatives you've considered
Update the bash and PowerShell scripts to use crane or skopeo instead of docker would allow for mirroring OCI indices.

#39609 is probably related to this issue


text:
[2.10] go get workflow is missing the go generate changes

port: https://github.com/rancher/rancher/issues/47014

the changes in the PR https://github.com/rancher/rancher/pull/47077 is same as v2.8 and v2.9 PRs and those worked fine hence closing this one as well.


text:
[cli] Adding a custom host via rancher CLI

I'd like to add a custom host (i.e., already provisioned) to an environment via the rancher CLI but the following command does not work:
rancher --url http://localhost:8080 --env k8 host create --driver custom h1
FATA[0000] Invalid driver: custom

--help on the create option lists the following driver options packet, amazonec2, azure, digitalocean [$MACHINE_DRIVER] but the UI shows custom (and gives an option to add more). I don't see anything about the CLI options in the general docs (https://docs.rancher.com/rancher/v1.5/en/hosts/custom/).
Is there a way to add a custom host via the CLI? What is the appropriate driver name?
Rancher versions:
rancher/server: 1.5.3
rancher/agent: 1.5.3
rancher/cli: 0.6.1

Custom doesn't actually do anything, it's just instructions for you to run the agent on the host.

Fair enough but is there a way to get that command via the CLI client?
The docs say:

If you are using different environments, the command provided through the UI will be unique to whatever environment that you are in.

So how can the specific command be generated?
(for reference, for anyone else that might come across this, the command will look similar to this: sudo docker run -e CATTLE_AGENT_IP="10.10.10.10"  -d --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.2.1 http://10.10.10.10:8080/v1/scripts/D46E3087637D38708210:1483143400000:Tt9QW2jK4xVMm0OEr1i6pss1Z1f

I have the same issue and sent a note on #rancher and the rancher forum on this "How to create a generic host via CLI" https://forums.rancher.com/t/how-to-create-a-generic-host-via-cli/7145
No response yet but I am watching.
In the meantime I looked into using the "generic" driver which (I think) will launch rancher/agent. I found that for the CLI to accept the generic driver I had to manually enable that machine-driver through the UI. I am currently working thru issues with passing the ssh key in the command (seems the rancher/server container can't get the key file as the host filesystem is not accessible in the rancher/server container...). But if I make progress on this including any way to script custom driver creation I will post that here. My overall goal is to create a CI/CD environment deploying and testing NFV applications using rancher as the cloud control plane (e.g. vs OpenStack) as part of our work in the OPNFV project (https://www.opnfv.org/).

@blsaws Thanks. It would be really helpful if you share the custom driver script.
I am using Rancher to automate ONAP (https://www.onap.org/) deployment on Kubernetes which I think will relate to OPNFV eventually. ;)

curl http://localhost:8080/v2-beta/registrationtokens
I'm using it like this in a script to setup my development environment shell script
URL=$(curl \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  http://localhost:8080/v2-beta/registrationtokens \
  | python -c "import sys,json;print(json.load(sys.stdin)['data'][0]['command'])")

I'm trying to create a generalized rancher install script:

https://github.com/jeff1evesque/machine-learning/blob/508f572357966d621026ff144731a29c6faed939/install_rancher

However, I'm having the following problems after running my custom rancher script:

each of the services in the stack doesn't not have any containers
no rancher host is created

Any willing to help me debug, and commit changes? Also, feel free to recycle this script for your own purpose.

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


text:
Fix to K3s checks on non-etcd cluster

Associated Issue: https://github.com/rancher/cis-operator/issues/100
This PR removes the if check around the etcd.yaml benchmarks, this was causing MIXED results on the scan. Now, all etcd related checks are run thru a helper script, which if etcd is running, performs the proper check. If etcd is not running, like on a single node using sqlite3, then the benchmarks are still run, but the helper script returns the correct answer for the check to pass.
Both k3s permissive and hardened cis-1.6 scans now pass, on both etcd and non-etcd clusters.

Changes look good, please can you squash all commits and push again?

@prachidamle Squashed.

authors: dereknola prachidamle

repo: rancher/security-scan


text:
OpenAPI Required Validation Broken, Possibly Others?

When using norman on 0.5.3 to specified a field is required, I see the schema and openapiv3schema gets generated, but it appears to be at the wrong level.
versions:
  - name: v1
    schema:
      openAPIV3Schema:
        properties:
          attributes:
            properties:
              additional:
                additionalProperties:
                  type: string
                type: object
              platform:
                required:
                - platform
                type: string
              serial:
                required:
                - serial
                type: string
              version:
                type: string
            type: object

For example platform and serial are required, but I can create a resource without setting these fields and kubernetes allows it.
versions:
  - name: v1
    schema:
      openAPIV3Schema:
        properties:
          attributes:
            properties:
              additional:
                additionalProperties:
                  type: string
                type: object
              platform:
                type: string
              serial:
                type: string
              version:
                type: string
            type: object
            required:
              - platform
              - serial

Opened a PR but it doesn't work against master.
diff --git a/pkg/schemas/openapi/generate.go b/pkg/schemas/openapi/generate.go
index ff5af90..3b73c1f 100644
--- a/pkg/schemas/openapi/generate.go
+++ b/pkg/schemas/openapi/generate.go
@@ -99,7 +99,7 @@ func parseSchema(schema *types.Schema, schemas *types.Schemas) (*v1beta1.JSONSch
                //}

                if f.Required {
-                       fieldJSP.Required = append(fieldJSP.Required, name)
+                       jsp.Required = append(jsp.Required, name)
                }

                if definition.IsMapType(f.Type) {
@@ -166,6 +166,7 @@ func parseSchema(schema *types.Schema, schemas *types.Schemas) (*v1beta1.JSONSch
                                        return nil, err
                                }
                                fieldJSP.Properties = subObject.Properties
+                               fieldJSP.Required = subObject.Required
                        }
                }

repo: rancher/wrangler


text:
Handle tarball install after rke2-uninstall

What type of PR is this?

[ ] bug
[X] cleanup
[ ] documentation
[ ] feature

What this PR does / why we need it:
There is a problem re-installing after removing a cluster using rke2-uninstall.sh. Here are the reproduction steps:

git clone https://github.com/aceeric/rke2-ansible.git esace-fork-rke2-ansible && cd esace-fork-rke2-ansible
Provision a single t3.xlarge Centos 7 EC2 instance with SELinux disabled on the OS
Verify in the instance:

sh-4.2$ getenforce
Disabled
sh-4.2$ sestatus
SELinux status:                 disabled

Back on the ansible controller:

mkdir inventory/testme
cat <<EOF > inventory/testme/inventory.yaml
---
all:
  children:
    rke2_cluster:
      children:
        rke2_servers:
          hosts:
            10.114.174.40:
          vars:
            rke2_config:
              selinux: false
  vars:
    install_rke2_version: v1.25.6+rke2r1
EOF

Get binaries for tarball install:

export RKE2VER=v1.25.6 REL=rke2r1 BASE=https://github.com/rancher/rke2/releases/download &&\
curl -sfL $BASE/$RKE2VER%2B$REL/rke2-images.linux-amd64.tar.zst\
  -o ./tarball_install/rke2-images.linux-amd64.tar.zst &&\
  curl -sfL $BASE/$RKE2VER%2B$REL/rke2.linux-amd64.tar.gz\
  -o ./tarball_install/rke2.linux-amd64.tar.gz &&\
  curl -sfL $BASE/$RKE2VER%2B$REL/sha256sum-amd64.txt\
  -o ./tarball_install/sha256sum-amd64.txt

Perform the tarball install: ansible-playbook -i inventory/testme site.yml
After successful install, uninstall: sudo /usr/local/bin/rke2-uninstall.sh
Observe RKE2 service status:

sh-4.2$ sudo systemctl list-unit-files --all | grep 'UNIT\|rke2'
UNIT FILE                                     STATE
rke2-agent.service                            disabled
rke2-server.service                           disabled

If you now re-install, the "already installed" logic in the playbook that this PR modifies believes that RKE2 has already been installed and it won't copy the .ZST to the server. This causes problems in an air-gapped environment when a registry is not reachable - the result is image pull backoffs.

This PR determines whether RKE2 is installed based on the service state. If "disabled" then RKE2 is considered not to be installed.
Which issue(s) this PR fixes:
I did't submit an issue for this.
Testing
I tested the steps above both in an air-gapped enviroment and a connected environment. I encountered the issue without the change in the air-gapped environment and the change resolved the issue.

Thank you for contributing @aceeric. I tested your reproduction steps and confirmed both the problem and the fix you proposed. It seems to be working. It failed the lint but ill override that and fix the linting error in a separate PR since you did not introduce this issue.

authors: aceeric mddamato


text:
Update terraform equinix provider to v2.5.0

We are currently on v2.4.1. See release notes at https://github.com/equinix/terraform-provider-equinix/releases/tag/v2.5.0

Superceded by https://github.com/rancherlabs/terraform-harvester-equinix/issues/100

repo: rancherlabs/terraform-harvester-equinix


text:
Skipping blank lines.

It would be great if this plugin was able to skip blank lines, and perhaps even commented lines.
Comments are slightly more tricky, though, as one should distinguish between ordinary comments and block comments.

it would be also tricky to skip blank lines.
For example, consider the following julia code
a = """
apple

orange
"""

The middle empty line is not really an empty line but a line in a string.

I think there is a slight misunderstanding. By 'skip' I do not mean that
blank lines should be discarded or ignored, but that the algorithm should not
stop on a blank line (or a commented line), but keep advancing (and sending lines) until it comes to the
next non-empty, non-commented line.
Right now I sometimes come across code that looks like this:
function foo()
    blah()
end

# jfklsdjfkljdsf
# fjdsjfkdlsjfkldjs
# jkdlsjfklds
# fjildsjkfldsj
# fjdksljfkdls

function bar()
    bleh()
end

I then need to hit cmd+enter 9 times to move to the function bar.

er....it should work if you highlight the whole a stuff.

Is the skipping thing working? Or is it too difficult? I could have a go at it, but I don't actually know Python...

Now, it skips blank lines. It will require more work to skip comments, I would probably not go for it now.

Great! :)

I changed the default back to the old behavior, i.e., only advance to next line. The settings auto_advance_non_empty will control this. a85cd0b

license: mit


text:
Priority headings are not shown on lazy loading

Steps:

have > 25 priority A todos
have any number of other priority todos
sort by priority

Expected behavior: priority heading (B), (C) etc is shown before their todos.
Actual behavior: further headings are not loaded on lazy loading. Nothing separates the last (A) todo from the first (B) todo.

Hi @9z0 . Can I ask you to take a quick look at this pre release if it solves this issue on your side?
https://github.com/ransome1/sleek/releases/tag/v1.1.2-rc.1

Seems fixed 👍

license: MIT


text:
Feature Request: Dual Priority Option for Bi-directional Interfaces

It would be really handy to be able to set a different priority for input vs output on Bi-directional interfaces such as the External Storage Module.
For example:
I have a chest slowly filling up with cobblestone automatically, attached to a network via an External Storage Module and a 1k drive on the same system to handle overflow.
I have a High priority set on the external storage so that any cobblestone I put in the system manually tries to go to the External Storage First and any overflow ends up on the 1k drive.
However because of the high priority when I pull cobblestone from the system it grabs it from the chest first and not the overflow in the 1k drive. The end result is that the overflow eventually fills up.
Ideally I would like to be able to pull from the overflow drive first then from the external storage while still having cobblestone i put in the system going back into the external storage first.

It's fine as is

LOL no its not but thats fine i perfer AE2 anyway :P

authors: Cheata raoulvdberge

repo: raoulvdberge/refinedstorage


text:
Massive FPS loss whilst controller is filling with power

And I mean massive from 120 FPS to 10 FPS, once the controller is full of power it's ok.
If you break the controller whilst it's filling up the FPS is regained, if you place it back down again the FPS is lost until it fills up so it's def the controller.
Forge 1865
refinedstorage-0.5.5

Not your issue this is the mod which is powering the controller

Sorry after further tests it is the controller which is causing this.  It seems the constant texture drawing is hitting FPS hard.   What made me close it was I went to use another machine and my FPS dropped, thinking it was the power gen mod.  But by draining power using this other machine it made the controller power indicator flicker causing FPS loss.
So I broke the power connection to the controller and my FPS dropped until it ran out of power, this most definitely concludes that the controller texture redrawing is causing the issue.

Do you have any machines connected? If so, how much?

I do but it does it with just the controller on it's own.
Currently have Solderer, controller, disk drive and grid and 1 cable.

I'm pretty sure this issue is not about texture redrawing, all the controller status textures are pre-baked when MC launches.

Try to disconnect all the machines, is the controller still laggy?

Well if you've managed to make a block lose 100 FPS and it's not about the textures that's a new one on me lol :D
Have a video on the issue specially just made for you - https://youtu.be/dGM9AQmjsT4 unedited so excuse the interruption lol

Thanks, I know where the issue is and will solve this for the next version.

The issue was not really a texture bug -- more like a "me causing a chunk update when energy level changes" bug :P

Fixed (I hope :P)

I released a 0.5.6 version on Curse that fixes this error.


text:
October 2020  Goals

Starting out on my own, lets see how what we can accomplish in October using GitHub

A game  that I have always wanted to build
A  static website for my new venture
Udacity Labs
AWS Cloud practitioner labs

@makerrdgmh and @rdgmh  will help out if needed since they will be joining my IOT start up

#1

@makerrdgmh lets do it

@makerrdgmh lets @rdgmh
Duplicate of #1

[ terraform associate]

[ jenkins is a must for october as well ]

#so what's next
@raphaelgmh

#October goals
@makerrdgmh

repo: raphaelgmh/github-slideshow


text:
Update README.md

fixed umap link

Solved in #192

repo: rapidsai/notebooks-contrib


text:
Q28 fails when run from benchmark runner on a single node

Q28 appears to fail when run from the benchmark runner at SF1K on a DGX-2. Naively, it looks like the compilation may silently fail which causes a KeyError on the task at runtime.
python benchmark_runner.py --config_file=benchmark_runner/benchmark_config.yaml
Using default arguments
Connected to tcp://172.22.1.26:8786
Pure Dask Queries
28
Encountered Exception while running query
Traceback (most recent call last):
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/lowering.py", line 30, in from_fndesc
    return cls._memo[fndesc.env_name]
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/weakref.py", line 137, in __getitem__
    o = self.data[key]()
KeyError: '_ZN08NumbaEnv3_2814map_labels$241Ei'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/funcdesc.py", line 93, in lookup_module
    return sys.modules[self.modname]
KeyError: '28'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/dask/dataframe/utils.py", line 174, in raise_on_meta_error
    yield
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/dask/dataframe/core.py", line 5125, in _emulate
    return func(*_extract_meta(args, True), **_extract_meta(kwargs, True))
  File "queries/q28/tpcx_bb_query_28.py", line 91, in <lambda>
    y = reviews_df["pr_review_rating"].map_partitions(lambda x: x.applymap(map_labels))
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/series.py", line 2578, in applymap
    res_col = self._unaryop(udf)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/frame.py", line 1926, in _unaryop
    return self.__class__._from_table(Frame(data, self._index))
  File "cudf/_lib/table.pyx", line 44, in cudf._lib.table.Table.__init__
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/column_accessor.py", line 38, in __init__
    self._data = OrderedColumnDict(data)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/frame.py", line 1924, in <genexpr>
    data_columns = (col.unary_operator(op) for col in self._columns)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/column/numerical.py", line 68, in unary_operator
    return _numeric_column_unaryop(self, op=unaryop)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/column/numerical.py", line 449, in _numeric_column_unaryop
    return libcudf.transform.transform(operand, op)
  File "cudf/_lib/transform.pyx", line 80, in cudf._lib.transform.transform
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/utils/cudautils.py", line 311, in compile_udf
    compiled = decorated_udf.compile(type_signature)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/cuda/compiler.py", line 165, in compile
    inline=self.inline)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/cuda/compiler.py", line 44, in compile_cuda
    locals={})
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler.py", line 603, in compile_extra
    return pipeline.compile_extra(func)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler.py", line 339, in compile_extra
    return self._compile_bytecode()
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler.py", line 401, in _compile_bytecode
    return self._compile_core()
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler.py", line 381, in _compile_core
    raise e
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler.py", line 372, in _compile_core
    pm.run(self.state)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_machinery.py", line 341, in run
    raise patched_exception
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_machinery.py", line 332, in run
    self._runPass(idx, pass_inst, state)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_machinery.py", line 291, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_machinery.py", line 264, in check
    mangled = func(compiler_state)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/typed_passes.py", line 442, in run_pass
    NativeLowering().run_pass(state)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/typed_passes.py", line 369, in run_pass
    metadata=metadata)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/lowering.py", line 80, in __init__
    self.env = Environment.from_fndesc(self.fndesc)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/lowering.py", line 32, in from_fndesc
    inst = cls(fndesc.lookup_globals())
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/funcdesc.py", line 81, in lookup_globals
    return self.global_dict or self.lookup_module().__dict__
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/funcdesc.py", line 96, in lookup_module
    f"can't compile {self.qualname}: "
ModuleNotFoundError: can't compile map_labels: import of module 28 failed

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/tmp/nicholasb/prod/tpcx-bb/tpcx_bb/xbb_tools/utils.py", line 280, in run_dask_cudf_query
    config=config,
  File "/tmp/nicholasb/prod/tpcx-bb/tpcx_bb/xbb_tools/utils.py", line 61, in benchmark
    result = func(*args, **kwargs)
  File "queries/q28/tpcx_bb_query_28.py", line 346, in main
    client=client, train_data=train_data, test_data=test_data
  File "queries/q28/tpcx_bb_query_28.py", line 285, in post_etl_processing
    y_train = build_labels(train_data)
  File "queries/q28/tpcx_bb_query_28.py", line 91, in build_labels
    y = reviews_df["pr_review_rating"].map_partitions(lambda x: x.applymap(map_labels))
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/dask/dataframe/core.py", line 642, in map_partitions
    return map_partitions(func, self, *args, **kwargs)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/dask/dataframe/core.py", line 5175, in map_partitions
    meta = _emulate(func, *args, udf=True, **kwargs)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/dask/dataframe/core.py", line 5125, in _emulate
    return func(*_extract_meta(args, True), **_extract_meta(kwargs, True))
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/contextlib.py", line 130, in __exit__
    self.gen.throw(type, value, traceback)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/dask/dataframe/utils.py", line 195, in raise_on_meta_error
    raise ValueError(msg) from e
ValueError: Metadata inference failed in `lambda`.

You have supplied a custom function and Dask is unable to
determine the type of output that that function returns.

To resolve this please provide a meta= keyword.
The docstring of the Dask function you ran should have more information.

Original error is below:
------------------------
ModuleNotFoundError("Failed in nopython mode pipeline (step: nopython mode backend)\ncan't compile map_labels: import of module 28 failed")

Traceback:
---------
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/dask/dataframe/utils.py", line 174, in raise_on_meta_error
    yield
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/dask/dataframe/core.py", line 5125, in _emulate
    return func(*_extract_meta(args, True), **_extract_meta(kwargs, True))
  File "queries/q28/tpcx_bb_query_28.py", line 91, in <lambda>
    y = reviews_df["pr_review_rating"].map_partitions(lambda x: x.applymap(map_labels))
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/series.py", line 2578, in applymap
    res_col = self._unaryop(udf)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/frame.py", line 1926, in _unaryop
    return self.__class__._from_table(Frame(data, self._index))
  File "cudf/_lib/table.pyx", line 44, in cudf._lib.table.Table.__init__
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/column_accessor.py", line 38, in __init__
    self._data = OrderedColumnDict(data)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/frame.py", line 1924, in <genexpr>
    data_columns = (col.unary_operator(op) for col in self._columns)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/column/numerical.py", line 68, in unary_operator
    return _numeric_column_unaryop(self, op=unaryop)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/core/column/numerical.py", line 449, in _numeric_column_unaryop
    return libcudf.transform.transform(operand, op)
  File "cudf/_lib/transform.pyx", line 80, in cudf._lib.transform.transform
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/cudf/utils/cudautils.py", line 311, in compile_udf
    compiled = decorated_udf.compile(type_signature)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/cuda/compiler.py", line 165, in compile
    inline=self.inline)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/cuda/compiler.py", line 44, in compile_cuda
    locals={})
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler.py", line 603, in compile_extra
    return pipeline.compile_extra(func)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler.py", line 339, in compile_extra
    return self._compile_bytecode()
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler.py", line 401, in _compile_bytecode
    return self._compile_core()
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler.py", line 381, in _compile_core
    raise e
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler.py", line 372, in _compile_core
    pm.run(self.state)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_machinery.py", line 341, in run
    raise patched_exception
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_machinery.py", line 332, in run
    self._runPass(idx, pass_inst, state)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_machinery.py", line 291, in _runPass
    mutated |= check(pss.run_pass, internal_state)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/compiler_machinery.py", line 264, in check
    mangled = func(compiler_state)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/typed_passes.py", line 442, in run_pass
    NativeLowering().run_pass(state)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/typed_passes.py", line 369, in run_pass
    metadata=metadata)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/lowering.py", line 80, in __init__
    self.env = Environment.from_fndesc(self.fndesc)
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/lowering.py", line 32, in from_fndesc
    inst = cls(fndesc.lookup_globals())
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/funcdesc.py", line 81, in lookup_globals
    return self.global_dict or self.lookup_module().__dict__
  File "/raid/nicholasb/miniconda3/envs/rapids-tpcxbb-20200727/lib/python3.7/site-packages/numba/core/funcdesc.py", line 96, in lookup_module
    f"can't compile {self.qualname}: "

I suspect this might be related to the JIT compiled function's bytecote not being visible during the query loading/compilation process in the benchmark runner

@beckernick , I think this might be good to close now? Can you confirm.

Not yet, we'll need to refactor either q28, how the runner loads the primary query functions, or special case q28's loading

Not yet, we'll need to refactor either q28, how the runner loads the primary query functions or special case q28's loading

Agreed.   The other options are:

Check if moving the function to an importable utility helps.
Get rid of map_labels altogether (it should be more performant in all probability to do so via cudf boolean operations )

I will likely take this on with https://github.com/rapidsai/tpcx-bb/issues/50.

Discussed offline. The above sounds great 👍

authors: VibhuJawa beckernick

repo: rapidsai/tpcx-bb


text:
Unable to build Docker image.

I am trying to build docker image through CICD provided. But is giving the following error:
Sending build context to Docker daemon  6.656kB
Step 1/14 : FROM node:16.13.0-buster as build
 ---> 5964aa70c11d
Step 2/14 : WORKDIR /app/
 ---> Using cache
 ---> b07cc8fec922
Step 3/14 : COPY packages/transaction-backend/package.json /app/package.json
COPY failed: file not found in build context or excluded by .dockerignore: stat packages/transaction-backend/package.json: file does not exist

How could I resolve this?

@abhalawat I think it's fixed atm
Feel free to contact me if there is an issue

authors: abhalawat evgenynacu

repo: rarible/sdk


text:
While using animated ores with frames and nautilus 3d, the ores appear with copper ore texture mixed.

Hi, I can't reproduce your issue. Although I downloaded “Nautilus 3D” and “Animated Ores with Frames” and selected so that “Animated Ores with Frames” is above “Nautilus 3D” when loading the resource pack. These resource packs are not compatible. They don't even display the ore frames in my resource pack. In the sense they display, but in the form of an item in the hand.

authors: Kloytz raspberrygitq

repo: raspberrygitq/Aminated-Ore-with-Frames


text:
[BUG] ValueError: numpy.dtype size changed

Please only report one bug per issue!
Describe the bug
I tried to run the following code in Thonny (under Python3), but I got Traceback, which indicates binary incompatibility:
from picamera2 import Picamera2
import Preview
import time
import cv2
picamera = Picamera2()
camera_config = picamera.create_still_configuration(main={"size":(1920, 1080)}, lores={"size": (640, 480)}, display="lores")
picamera.configure(camera_config)
picamera.start_preview(Preview.QTGL)
picamera.start()
#allow the camera to warm up
time.sleep(2.0)
#save image into file
picamera.capture_file("test.jpg")
picamera.stop_preview()
picamera.close()
#show image until a key is pressed
image = cv2.imread("test.jpg")
cv2.imshow("Image", image)
cv2.waitKey(0)
cv2.destroyAllWindows()
To Reproduce
Run with Python3, or in Thonny.
Expected behaviour
The program should start correctly.
Console Output, Screenshots
I got the following messages:
Traceback (most recent call last):
File "/home/anemethhunor/Desktop/beagyazott/gyak8/7_access_camera.py", line 1, in
from picamera2 import Picamera2
File "/usr/local/lib/python3.11/dist-packages/picamera2/init.py", line 11, in
from .picamera2 import Picamera2, Preview
File "/usr/local/lib/python3.11/dist-packages/picamera2/picamera2.py", line 27, in
from picamera2.encoders import Encoder, H264Encoder, MJPEGEncoder, Quality
File "/usr/local/lib/python3.11/dist-packages/picamera2/encoders/init.py", line 6, in
from .jpeg_encoder import JpegEncoder
File "/usr/local/lib/python3.11/dist-packages/picamera2/encoders/jpeg_encoder.py", line 3, in
import simplejpeg
File "/usr/lib/python3/dist-packages/simplejpeg/init.py", line 1, in
from ._jpeg import encode_jpeg
File "simplejpeg/_jpeg.pyx", line 1, in init simplejpeg._jpeg
ValueError: numpy.dtype size changed, may indicate binary incompatibility. Expected 96 from C header, got 88 from PyObject
Hardware :
Raspberry Pi Zero 2W with Pi Camera (wide).
Additional context
Nope

I forgot to mention, the aforementioned numpy module's version is 2.1.3


text:
CMake Deprecation Warning: cmake_minimum_required

Recently, when building pioasm and/or elf2uf2, CMake warns about cmake_minimum_required:
[ 96%] Performing configure step for 'PioasmBuild'
loading initial cache file /home/gmt/Projects/pico/build/pico-sdk/src/rp2_common/pico_cyw43_driver/pioasm/tmp/PioasmBuild-cache-Release.cmake
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

#1477 reported the problem, but submitted patch is not correct.

https://github.com/raspberrypi/pico-sdk/pull/1546

I can't seem to reproduce this. Do you still have the problem if you delete your build folder and start from scratch?

merged into develop

authors: gmt3141 kilograham peterharperuk

repo: raspberrypi/pico-sdk


text:
flash_safe_execute() doesn't recognise FreeRTOS SMP define for the number of cores

Hello,
in pico-sdk/src/rp2_common/pico_flash/flash.c, on line 18,
when compiled with FreeRTOS SMP support,
configNUM_CORES is expected to be set to 2 through FreeRTOSConfig.h.
But the FreeRTOS uses a different name for this define: configNUMBER_OF_CORES.
See for instance line 100 in https://github.com/FreeRTOS/FreeRTOS-Community-Supported-Demos/blob/main/CORTEX_M0%2B_RP2040/Standard_smp/FreeRTOSConfig.h
This leads to an assert/error when calling flash_safe_execute() with FreeRTOS SMP, see line 172 in flash.c.
As a quick fix I had to add the following in my FreeRTOSConfig.h:
#define configNUM_CORES configNUMBER_OF_CORES
With best regards, Anton

I guess this'll be fixed by #1530 ?

That's true. Sorry I didn't find the 1530 before.

Duplicate

authors: antonwtw lurch peterharperuk


text:
Please don't squash on releases

The 1.3.0 release was done by squashing all commits together into one.
This makes is very difficult to find out which commits are in a certain release. I'm generally all for squashing history in PRs and similar, but I would greatly appreciate it if future releases were a merge or fast-forward instead.

I second this. Squashed releases make commands like "git log 1.3.0..origin/develop" basically useless.
For reference to anyone else who finds this issue, commit 60c5a929ccf9d475e5bd050937af4d599fa92e64 "Remove  from mutex doxygen due to PDF generation bug" on the develop branch appears to be what they squash-merged the to master for the 1.3.0 tag, their git trees are identical.

agreed

anyone have an opinion on whether to retag 60c5a92 as 1.3.1?

I created a new merge commit in master ea79d29c which i may retag as 1.3.0. this has the actual history and matched 60c5a92 exactly.
8195d99f which is currently  branch sdk1.3.1-candidate is what should become the new release (building on that)

actually i did update the tag and note it in the release notes

Thank you, I appreciate it! I didn't see the earlier comment, but I'm definitely in favor of retagging.

The retagging broke our use of pico-sdk as a submodule. https://github.com/circuitpython has a specialized action for updating submodules, but it's possible it might have broken it anyway. We'll advance to 1.3.1.
From https://github.com/raspberrypi/pico-sdk
 * branch            2062372d203b372849d573f252cf7c6dc2800c0a -> FETCH_HEAD
 ! [rejected]        1.3.0      -> 1.3.0  (would clobber existing tag)
fatal: run_command returned non-zero status for ports/raspberrypi/sdk
.
make: *** [Makefile:332: fetch-submodules] Error 128

ah, sorry about that. six of one, half a dozen of the other.. you could just delete the local tag too first

actually i did update the tag and note it in the release notes

@kilograham Please don't change existing tags in the future. It breaks anything using tags to download the source tree for a specific version, and relying on each download being identical. For example, Linux distro packaging
Also, from the git-tag docs (emphasis mine):

But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things:

The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have different "X"'s. So just call it "X.1" and be done with it.

The insane thing. You really want to call the new version "X" too, even though others have already seen the old one. So just use git tag -f again, as if you hadn’t already published the old one.

... If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names.

authors: aswild dhalbert flaviut kilograham xxc3nsoredxx


text:
Fix missing headers leading to #include failing when pulling in hardware_irq and pico_bootrom

As suggested by @kilograham (in https://github.com/raspberrypi/pico-sdk/issues/1929#issuecomment-2364746391), add pico_runtime_init as well as pico_runtime and boot_picobin_headers to the CMakeLists.txts defining hardware_irq and pico_bootrom_headers.
While the issue initially was reported only for hardware_irq missing pico_runtime_init, the same issue affect the other mentionned.
Fixes #1929

/usr/lib/gcc/arm-none-eabi/12.2.1/../../../arm-none-eabi/bin/ld: cannot find -lboot_bootrom_headers: No such file or directory
I used your changes and  could remove error in compilation but at the time of linking I had the same error

cannot find -lboot_bootrom_headers: No such file or directory

You'll get this if the sdk doesn't know about boot_bootrom_headers, which would indicate you're not using the latest sdk.

cannot find -lboot_bootrom_headers: No such file or directory

You'll get this if the sdk doesn't know about boot_bootrom_headers, which would indicate you're not using the latest sdk.

@peterharperuk  I am using SDK git tag 2.0.0 , look the output of git log command
`j@raspberrypi:~/pico/pico-sdk $ git log
commit 2f1d186769a7f070cd2b193d580827c8d75e3e11 (HEAD, master)
Author: jaymin patel jaymin.1328@gmail.com
Date:   Tue Nov 5 14:50:51 2024 +0000
added fixes to work with 2.0.0 from internet didn't working

commit efe2103f9b28458a1615ff096054479743ade236 (tag: 2.0.0, origin/master, origin/HEAD)
Author: graham sanderson graham.sanderson@raspberrypi.com
Date:   Thu Aug 8 06:02:04 2024 -0500
SDK 2.0.0 release

commit 45984e276f85aa24d33aa0ab62ed1e6df96a0784
`

Have you deleted your build folder?

Have you deleted your build folder?

Yes!
What I did was setup a RaspberryPi5 with pico_setup.sh and git clone my code and trying to compile
@aabizri This is my cmakelist.txt
cmake_minimum_required(VERSION 3.15)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)
set(PICO_BOARD pico)
set(CMAKE_BUILD_TYPE Debug)
# Set the Pico SDK path if not already set
# set(PICO_SDK_PATH "/path/to/pico-sdk")

# Pull in Raspberry Pi Pico SDK (must be before project)
include($ENV{PICO_SDK_PATH}/pico_sdk_init.cmake)

# # Project node -----------------------------------------------------------------------------------------
# set(PROJECT_NODE node)
# project(${PROJECT_NODE} C CXX ASM)
# pico_sdk_init()

# # Include subdirectories for the node project
# add_subdirectory(sensors/SCD41)
# add_subdirectory(sensors/AS7331)
# add_subdirectory(sensors/BME688)
# add_subdirectory(sensors/ICS43434)
# add_subdirectory(sensors/ONEWIRE)
# add_subdirectory(sensors/dht)
# add_subdirectory(sensors/VEML7700)
# add_subdirectory(sensors/STHS34)
# add_subdirectory(sensors/SENSIRION)
# add_subdirectory(sensors/multiSensor)
# add_subdirectory(CAN)
# add_subdirectory(SEREEPROM)
# add_subdirectory(CMD)
# add_subdirectory(FS)
# add_subdirectory(FS/littlefs-lib)
# add_subdirectory(FS/stdinit-lib)
# add_subdirectory(WIZNET)
# add_subdirectory(SEGGER)
# add_subdirectory(MQTT_LWIP)

# add_executable(${PROJECT_NODE} main_node.cpp)

# target_include_directories(${PROJECT_NODE} PRIVATE ${CMAKE_CURRENT_LIST_DIR})

# pico_set_program_name(${PROJECT_NODE} "${PROJECT_NODE}")
# pico_set_program_version(${PROJECT_NODE} "0.1")

# pico_enable_stdio_uart(${PROJECT_NODE} 0)
# pico_enable_stdio_usb(${PROJECT_NODE} 1)

# target_link_libraries(${PROJECT_NODE} PRIVATE
# pico_stdlib
# # pico_runtime_init
# # pico_runtime_init_headers
# # pico_runtime
# # boot_picoboot_headers
# # boot_bootrom_headers
# # boot_picobin_headers
# # pico_runtime_init_headers
# hardware_rtc
# hardware_i2c
# hardware_spi
# segger
# SCD41
# AS7331
# BME680
# VEML7700
# STHS34
# MIC
# pico_one_wire
# CAN
# EEPROM
# CMD
# littlefs-lib
# stdinit-lib
# FS
# SENSIRION
# BME680
# multiSensor
# )

# pico_add_extra_outputs(${PROJECT_NODE})

# Project gateway --------------------------------------------------------------------------------------
set(PROJECT_GATEWAY gateway)
project(${PROJECT_GATEWAY} C CXX ASM)
pico_sdk_init()

set(CMAKE_C_FLAGS_DEBUG "-Og -g")      # Debugging info with some optimization
set(CMAKE_CXX_FLAGS_DEBUG "-Og -g")    # C++ Debug flags

# Include subdirectories for the node project
add_subdirectory(sensors/SCD41)
add_subdirectory(sensors/AS7331)
add_subdirectory(sensors/BME688)
add_subdirectory(sensors/ICS43434)
add_subdirectory(sensors/ONEWIRE)
add_subdirectory(sensors/dht)
add_subdirectory(sensors/VEML7700)
add_subdirectory(sensors/STHS34)
add_subdirectory(sensors/multiSensor)
add_subdirectory(CAN)
add_subdirectory(SEREEPROM)
add_subdirectory(CMD)
add_subdirectory(FS)
add_subdirectory(FS/littlefs-lib)
add_subdirectory(FS/stdinit-lib)
add_subdirectory(WIZNET)
add_subdirectory(SEGGER)
add_subdirectory(MQTT_LWIP)

add_executable(${PROJECT_GATEWAY} main_gw.cpp)

target_include_directories(${PROJECT_GATEWAY} PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})

pico_set_program_name(${PROJECT_GATEWAY} "${PROJECT_GATEWAY}")
pico_set_program_version(${PROJECT_GATEWAY} "0.1")

pico_enable_stdio_uart(${PROJECT_GATEWAY} 0)
pico_enable_stdio_usb(${PROJECT_GATEWAY} 1)

target_link_libraries(${PROJECT_GATEWAY} PRIVATE
        pico_stdlib
        #pico_runtime_init
        hardware_spi
        hardware_i2c
        hardware_dma
        hardware_adc
        hardware_pio
        hardware_clocks
        pico_multicore
        CMD
        CAN
        segger
        STHS34
        AS7331
        EEPROM
        FS
        littlefs-lib
        stdinit-lib
        MIC
        dht
        TEGMQTT
        BME680
        VEML7700
        multiSensor
)

pico_add_extra_outputs(${PROJECT_GATEWAY})

I'm not able to reproduce the linking error. boot_bootrom_headers should not even be involved in linking as it's an INTERFACE library.
This looks like the CMake definition of boot_bootrom_headers is not being reached, which should not happen as rp2_common.cmake adds the relevant subdirectory in the same way as any other required for building.
Are you (@jaymin1328) calling pico_sdk_init as required ? Did you clear the CMake cache/build directory since the upgrade to 2.0.0 ? Do you have a code reproduction to share ?

@aabizri Here is the full code . I am trying to build BOTH folder
BOTH.zip

@jaymin1328 Make sure you have these two commits (the fix for this defect) in pico-sdk. Your code builds for me.
bc8ded18 (HEAD -> fix-missing-interface-links) Adjust targets being included
49a2a01c Fix compilation issues when including in hardware_irq and pico_bootrom (#1929)

@jaymin1328 Make sure you have these two commits (the fix for this defect) in pico-sdk. Your code builds for me.
bc8ded18 (HEAD -> fix-missing-interface-links) Adjust targets being included 49a2a01c Fix compilation issues when including in hardware_irq and pico_bootrom (#1929)

Thanks a lot for the help!
However, I could not see the commits in my local repo
j@raspberrypi:~/pico/pico-sdk $ git log --format="%h" | grep bc8ded18
j@raspberrypi:~/pico/pico-sdk $ git log --format="%h" | grep 49a2a01c

can you send me the links of the commits like this one ?
https://github.com/raspberrypi/pico-sdk/pull/1956/commits/29b1fa99382cd512021f3773fcf2a97a85efd226

The changes are in this PR - see the commit tab...
https://github.com/raspberrypi/pico-sdk/pull/1956/commits/29b1fa99382cd512021f3773fcf2a97a85efd226
https://github.com/raspberrypi/pico-sdk/pull/1956/commits/56efb281b00e93c718492287cdf3e063fa36fafb

The changes are in this PR - see the commit tab...
29b1fa9 56efb28

Error still persists ...
After incorporating changes mentioned in 56efb281
CMakeOutput.log
make.log
After incorporating changes mentioned in 29b1fa99
CMakeOutput.log
make.log
Also you mentioned first bc8ded18 and 49a2a01c
and now you mentioned second time 29b1fa99 and 56efb281
Are they both same things or am I seeing things wrongly ?

@kilograham Can I merge this. This build issue seems to be causing confusion.

@jaymin1328 The pull requests proposes to merge the two commits specified by @peterharperuk and that you said you incorporated. (29b1fa9 56efb28).
Without the changes in this pull request, both the master (latest 2.0.0) & develop (tip) branch of this repository are succeptible to issue #1929. Indeed, some targets (let's call them A (1)) defined by the SDK should have header-only dependencies on targets (which we'll call B (2)), but don't, leading to missing headers when compiling. This is the symptom of the issue solved by the current PR.
This doesn't happen all the time, as depending on how the downstream target C (3) configured the include directories & targets, even when A is added as a dependency, it is possible for the required targets B to have been also added as a depdency otherwise, leading to no error in compilation as the headers can then be found.
If you are hitting the issue as specified in the description of this PR and/or issue #1929, and until this is fixed upstream in develop and then released in master/2.1.0. I recommend either using the branch of the pull request (4) or applying the workarounds in issue #1929, which are essentially to target_link_libraries(C PRIVATE A B) where today you do target_link_libraries(C PRIVATE A).
(1): hardware_irq, pico_bootrom
(2): that is, other targets whose headers are required for the aforementioned targets
(3): in your posted CMakeLists.txt, that is the one producing gateway.elf
(4): on my fork, branch fix-missing-interface-links: https://github.com/aabizri/pico-sdk/tree/fix-missing-interface-links

@jaymin1328 The pull requests proposes to merge the two commits specified by @peterharperuk and that you said you incorporated. (29b1fa9 56efb28).
Without the changes in this pull request, both the master (latest 2.0.0) & develop (tip) branch of this repository are succeptible to issue #1929. Indeed, some targets (let's call them A (1)) defined by the SDK should have header-only dependencies on targets (which we'll call B (2)), but don't, leading to missing headers when compiling. This is the symptom of the issue solved by the current PR.
This doesn't happen all the time, as depending on how the downstream target C (3) configured the include directories & targets, even when A is added as a dependency, it is possible for the required targets B to have been also added as a depdency otherwise, leading to no error in compilation as the headers can then be found.
If you are hitting the issue as specified in the description of this PR and/or issue #1929, and until this is fixed upstream in develop and then released in master/2.1.0. I recommend either using the branch of the pull request (4) or applying the workarounds in issue #1929, which are essentially to target_link_libraries(C PRIVATE A B) where today you do target_link_libraries(C PRIVATE A).
(1): hardware_irq, pico_bootrom (2): that is, other targets whose headers are required for the aforementioned targets (3): in your posted CMakeLists.txt, that is the one producing gateway.elf (4): on my fork, branch fix-missing-interface-links: https://github.com/aabizri/pico-sdk/tree/fix-missing-interface-links

Thanks a lot for the detailed explanation. I will try your branch and let you know.

@kilograham Can I merge this. This build issue seems to be causing confusion.

I had glanced at this a couple of times, but change looked a bit weird and didn't dig in further, I have made a comment

superseded by #2031

authors: aabizri jaymin1328 kilograham peterharperuk


text:
🛑 SJTU Mirror (mirror.sjtu.edu.cn) is down

In b336f83, SJTU Mirror (mirror.sjtu.edu.cn) (https://mirror.sjtu.edu.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SJTU Mirror (mirror.sjtu.edu.cn) is back up in 65e9381.

repo: raspbian-addons/status


text:
Unable to determine number river. Failed to start ...everse proxy server.

Please post the link after running:
debug -l

in the command line to assess this.

I can't ssh into it

If a reboot doesn't help try to reflash.

authors: maximotodev openoms

repo: raspiblitz/raspiblitz


text:
[BUG] Tor warning

Describe the bug
By chance i came across the following error message in the log after a reboot
Tor[942]: We compiled with OpenSSL 30000070: OpenSSL 3.0.7 1 Nov 2022 and we are running with OpenSSL 30000090: 3.0.9. These two versions should be binary compatible.
Tor[942]: Tor 0.4.7.13 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.4 and Glibc 2.36 as libc.
Tor[942]: Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Tor[942]: Tor was compiled with zstd 1.5.2, but is running with zstd 1.5.4. For safety, we'll avoid using advanced zstd functionality.

When checking the version a warning is displayed too, which seems point to the same issue.
`$ tor --version
Aug 03 08:34:33.434 [warn] Tor was compiled with zstd 1.5.2, but is running with zstd 1.5.4. For safety, we'll avoid using advanced zstd functionality.
Tor version 0.4.7.13.
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd 1.5.4 and Glibc 2.36 as libc.
Tor compiled with GCC version 12.2.0`
`

Location in guide
https://raspibolt.org/guide/raspberry-pi/privacy.html#installation
Expected behavior

Displaying version
No error message when checking version

Screenshots
N/A
Environment

Hardware platform: Apple Macmini6,2
Operating system: Debian 12
Version: No LSB modules are available. Debian GNU/Linux 12 (bookworm)

Additional context
Tor was installed quite a while ago using using the raspibolt guide
$ sudo apt install tor
It seems the guide has been updated as it's now installed using
$ sudo apt install apt-transport-https
Suggestion
Add an update section for tor

I would try sudo apt update and sudo apt upgrade and then check if problem still persists.

Removing the old version of tor and installing again didn't help either, so for now I will simply ignore the error.
Obviously, people are aware of this, for more information see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963151#14

Obviously, people are aware of this, for more information see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963151#14

This looks like out of the scope of the RaspiBolt guide, we should wait for an upstream fix.

repo: raspibolt/raspibolt