text:
SAML Auth Providers - Ping, Keycloak, ADFS, Okta, Shibboleth

Research courtesy of @mantis-toboggan-md in rancher/dashboard#794
SAML
(Ping, KeyCloak, AD FS, Okta, Shibboleth‡)
These types have some individualized configuration required within the SAML client, but all require the following inputs on the Rancher UI side

Label
Component
Required?
Default

Display Name Field
LabeledInput
Yes

User Name Field
LabeledInput
Yes

UID Field
LabeledInput
Yes

Groups Field
LabeledInput
Yes

Rancher API Host
LabeledInput
Yes
<your Rancher API url>

Private Key
Multiline Input with Paste-from-file
Yes

CA crt
Multiline Input with Paste-from-file
Yes

Metadata XML
Multiline Input with Paste-from-file
Yes

‡ Shibboleth can be configured with an OpenLDAP backend, and if so, should also show the LDAP-type inputs. I would probably hide that section by default and include:

Label
Component
Required?
Default

OpenLDAP backend?
Checkbox
No
No

Opened a couple issues around SAML. This first is blocking around 70% of the QA regression coverage:
https://github.com/rancher/dashboard/issues/2273
Others:
https://github.com/rancher/dashboard/issues/2274
https://github.com/rancher/dashboard/issues/2276

Rancher version v2.5-head (02/24/2021) 30e53bd
Rancher version master-head (02/24/2021) 465bb3b
P1 tests done using ADFS.

Some improvements are being worked on and the Authentication Providers is not available on Rancher master-head (03/10/2021) eda2a07 Reopening to reflect this.

@izaac Can you check on 2.5-head now, the Auth should be available

Rancher version v2.5-head (03/15/2021) 38649e2
P1 tests using PingFederate except groups (see: https://github.com/rancher/rancher/issues/31519)

Rancher version v2.5-head (03/15/2021) 38649e2
P1 tests using Keycloak

Rancher version v2.5-head (03/15/2021) 38649e2
P1 Site Access tests using Okta
Ember UI has this issue: https://github.com/rancher/rancher/issues/30401#issuecomment-790153866
This groups dropdown worked with the Dashboard UI.

Rancher version v2.5-head (03/15/2021) 38649e2
P1 Site Access tests using Shibboleth.
I opened separate UI issues for Shibboleth

#2545
#2546
#2547
#2548

authors: deniseschannon izaac sowmyav27


text:
View log buttons on bottom are either cut off or missing when text in logs

Steps:

Go to Pods
Show the cattle-system namespace
Select View Logs for one of those pods

results:  Since the log is full, you can't see the buttons on the bottom.  As more info goes it, the buttons slowly get cut off the bottom as well.

Design of View logs has changed so this issue isn't valid anymore.

source: gharchive/issue

authors: deniseschannon tfiduccia

repo: rancher/dashboard

license_type: permissive

license_source: github-api


text:
Prepare for versioning of the docs

I want to make sure these items are addressed before splitting the 2.5 docs from the other docs. https://rancher.atlassian.net/wiki/spaces/EN/pages/711393348/2.5+Documentation+Updates+excluding+feature+docs

Need to also raise issue on rancherlabs/website repo about adding a dropdown menu to allow a user to select a product version when reading the docs.

repo: rancher/docs


text:
Add clarification on Windows logging support

Add clarification on Windows logging support with some caveats. These
will be subject to change with upstream fixes and internal improvements.
Re-opened version of #2783 on master branch.

Adding @catherineluse for review!

https://github.com/rancher/docs/issues/2833

source: gharchive/pull-request

authors: maggieliu nickgerace


text:
ARM netboot ISOs

Depends on #526

Blocked by #930

Closing for now as we've published initial instructions for ARM in the development documentation

authors: kkaempf mudler mudlers

repo: rancher/elemental-toolkit


text:
[v2.0.x] Hostname backports

#1264
(cherry picked from commit 5e6bc8fa00cb34ce4adf2a398b1dbc7b491d086a)

@fgiudici if I understand it correctly this bringing the equivalent of 0bf9ba82f1f4850dc3258a8c1fbd92c000e0e953 and 5e6bc8fa00cb34ce4adf2a398b1dbc7b491d086a.

authors: davidcassany fgiudici

repo: rancher/elemental


text:
Ignore swap (.swp) files in manifests folder

Describe the bug
I created a manifest in /var/lib/rancher/k3s/server/manifests/test.yaml and started k3s in server mode. Decided to edit the file using vi, which generates a .swp file in the same folder. This caused the following error message about every 15 seconds:
ERRO[2019-03-29T05:16:53.428115408Z] failed to process config: failed to process /var/lib/rancher/k3s/server/manifests/.test.yaml.swp: yaml: control characters are not allowed
ERRO[2019-03-29T05:17:08.429939965Z] failed to process config: failed to process /var/lib/rancher/k3s/server/manifests/.test.yaml.swp: yaml: control characters are not allowed

To Reproduce
See above
Expected behavior
Would be nice if .swp files were ignored. Not sure if it would make sense to have a whitelist of extensions like ".yml", ".yaml", etc. or a blacklist of extensions to ignore like ".swp", ".bak", etc.
Additional context
Discovered while testing https://github.com/rancher/k3s/issues/222

We should do the reverse in look for only .yml, .yaml and .json only files.

and ignore any files that start with .

Tested on v0.5.0-rc3 (21a9dbe2). Successfully deployed files named test.yaml and test.yml by placing in /var/lib/rancher/k3s/server/manifests. Confirmed files with .swp and .txt were ignored. .test.yml was also ignored. Working as expected, closing issue.

license_source: bigquery


text:
Reboot Loop with hyper-V iso at 1024MB Ram

RancherOS Version: (ros os version)
1.3.0 from os image rancher/os:v1.3.0
Where are you running RancherOS?

Hyper-v
Gen1 VM
Windows 10 1709 OS Build 16299.309

Tested settings the memory to fixed at 1500MB or more and it'll boot fine. Same behaviour form the ISO boot or ros install to the system drive boot.
In the boot process before the screen updates the resolution size the kernel hangs with what seems to be memory address'

Made an issue more to document my problem really, I guess that's just not enough ram to get started now?
I'm testing this for running on a PI 3. Is this now a non-starter or does the rpi image avoid this issue?

Still occuring with ROS1.4

Is there any way to overcome the RAM limitation during installation? Maybe turning on swap partition use or zram?

Just to add to this, i've seen the same behaviour on ESXi 6.7. You need to allocate the RAM to the VM, and then reserve all guest memory by expanding the RAM settings in the VM, and checking the box that is labelled as such

repo: rancher/os


text:
[Feature] Rancher 2.0 & Cluster Autoscaling

Dear Rancher,
is there any plan to support for this feature which is supported since 1.10 on Azure for instance.
https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider
https://forums.rancher.com/t/node-autoscaling/9141
Thanks & Regards

https://github.com/jepp2078/autoscaler/tree/rancher-cloud-provider
https://github.com/kubernetes/autoscaler/compare/master...jepp2078:rancher-cloud-provider
@jepp2078 did some work on this 🙌

Is there any update on when this might be added to Rancher?

@casz  Do you know if the rancher provider works with v2 rancher?

@tmedford it's for v2.

I also looked at the State of the Cluster Autoscaler, and was clearly disappointed! I am talking about it in general and not about @jepp2078 addition to it, which is going in the right direction, but also needs some more work. I am writing down my thoughts about this here after the paragraph about the autoscaler itself.
So for everyone else, looking into this: The cluster autoscaler is if you're thinking like me, not what you think it is. It is not by far taking any action to make new machines available, it is (at least yet) a dump stupid unit that increases and decreases numbers based on resource requests. So throwing in  the autoscaler only works, if you have an auto scaling set in place that is capable of setting itself up to the point of automatically joining the cluster. The cluster autoscaler does not instruct, it only adjusts the number of needed hosts in the autoscaling set.
So for rancher: The implementation of @jepp2078 looks very good already. But it lacks support for scaling to zero, which is more a problem of rancher currently, not allowing this to be done. And the second thing is, to make the autoscaler work properly with rancher, I think it needs to be supported by rancher as a concept in the first place.
So here are my thoughts how it could look like:
Rancher will need a node pool that can be configured just like an auto scaling set. Pre defining the maximum amount of hosts possible in it, the minimum and the capability to scale down to zero and additionally be able to pass an arbitrary json to it. The api needs to return the following information about the node pool:

in which cloudprovider the host is
the instance (name) type selected
the scaling information (min, max, demanded, current)
the arbitrary json

The autoscaler will need to interpret this api information as the following: First take the cloudprovider and if avalable logic and templates into account. For example for aws take https://github.com/kubernetes/autoscaler/blob/c756ed3953dfd3abc43894e2034964b0853d438f/cluster-autoscaler/cloudprovider/aws/ec2_instance_types/gen.go and if available also the pricing information https://github.com/kubernetes/autoscaler/blob/c756ed3953dfd3abc43894e2034964b0853d438f/cluster-autoscaler/cloudprovider/gce/gce_price_model.go like for gce.
If it is a non supported provider, then from the arbitrary json information about the instance can be provided by the user (like instance type is gpu or not, also pricing information, whatever the user needs here).
There is certainly room for improvement on that, but with that in place we would have a pretty good stance for the autoscaler, which is in my view even superior to all the current ones. Since those are strictly bound to the cloud and have been exclusively build for them (which is pretty much a reflection of the development of k8s in general..., it is often petty much bound to the environment instead of being decoupled and being usable everywhere).
So I think this shouldn't be too hard to implement. Since the node pool already somehow has support for scaling to zero. At least you can write a zero manually into the form and it will actually be saved. So it would need to be extended with the bits mentioned.
I am not sure if I will find the time to look into that into my self, since this takes considerable amount of time, as I have not dived through ranchers core source yet much. But it is generally a topic I would like to see happen very soon, since I have an active need for it. So I will look how I can support to help make it happen.

Would it be possible to have a separate nodepool which acts as nodepool only for autoscaling?
We are using rancher with the official terraform provider where we define our nodetemplates and define a specific number of host to each of them.
The autoscaling machansim should not interfere with that state otherwise the state will drift.
When autoscaling happens and we want also to apply some changes via terraform it would be bad that terraform overwrites the current node number on the nodepool.

We are launching K8S clusters using Terraform and the Rancher2 provider.
Worker nodes are always part of an Auto Scaling Group (ASG), each ASG is tagged accordingly so that cluster-autoscaler can detect them and scale up/down:

KubernetesCluster - <cluster_name>
k8s.io/cluster-autoscaler/enabled - true
k8s.io/cluster-autoscaler/<cluster_name> - <cluster_name>

Each worker node registers with rancher using docker command in user-data:
docker run \
    -d \
    --privileged \
    --restart=unless-stopped \
    --net=host \
    -v /etc/kubernetes:/etc/kubernetes \
    -v /var/run:/var/run \
    rancher/rancher-agent:v2.2.5 \
        --server https://rancher-rnd.example.com \
        --token <token>  \
        --worker

This allows me to scale up workers freely, it takes a couple of minutes for a worker to be ready from the time it is launched in EC2 until it starts all the required components.
This is the easy part, it gets hard when you try to scale down, since terminated workers still remain in rancher in status Kubelet stopped posting node status..
My solution:
Create user in rancher with name node_remover, give it access to clusters you want to autoscale with Manage Nodes role, create an API key and save it somewhere.
To remove workers from rancher when scaling down I use a script that runs on instance termination:
#!/bin/bash
# chkconfig: 0123456 99 01
# description: EC2 Termination script
. /etc/rc.d/init.d/functions
start() {
    /usr/bin/touch /var/lock/subsys/ec2-termination
}
stop() {
    node_ip=`/usr/bin/curl -s http://169.254.169.254/latest/meta-data/local-ipv4`
    node_id=`/usr/bin/curl -k https://rancher.example.com/v3/nodes/?clusterId=<cluster_id> \
      -su "<user>:<pass>" \
      -H 'Accept: application/json' \
      | /usr/bin/jq -r --arg ip_address "${node_ip}" \
      '.data | .[] | select(.ipAddress == $ip_address) | .id'`
    /usr/bin/curl -k -XDELETE "https://rancher.example.com/v3/nodes/${node_id}" \
      -u "<user>:<pass>" \
      -H 'Accept: application/json'
    /usr/bin/rm -f /var/lock/subsys/ec2-termination
}
case "$1" in
    start)
       start
       ;;
    stop)
       stop
       ;;
    restart)
       stop
       start
       ;;
    status)
       ;;
    *)
       echo "Usage: $0 {start|stop|status|restart}"
esac
exit 0

You need to know cluster_id in advance, this is east with Terraform since it created the cluster in rancher so I just pass the output to user-data.
The final user-data looks like this:
#cloud-config

packages:
  - ca-certificates
  - docker
  - jq

write_files:
  - path: /etc/init.d/ec2-termination
    owner: root:root
    permissions: '0755'
    content: |
      #!/bin/bash
      # chkconfig: 0123456 99 01
      # description: EC2 Termination script
      . /etc/rc.d/init.d/functions
      start() {
          /usr/bin/touch /var/lock/subsys/ec2-termination
      }
      stop() {
          node_ip=`/usr/bin/curl -s http://169.254.169.254/latest/meta-data/local-ipv4`
          node_id=`/usr/bin/curl -k https://rancher.example.com/v3/nodes/?clusterId=<cluster_id> \
            -su "<user>:<pass>" \
            -H 'Accept: application/json' \
            | /usr/bin/jq -r --arg ip_address "${node_ip}" \
            '.data | .[] | select(.ipAddress == $ip_address) | .id'`
          /usr/bin/curl -k -XDELETE "https://rancher.example.com/v3/nodes/${node_id}" \
            -u "<user>:<pass>" \
            -H 'Accept: application/json'
          /usr/bin/rm -f /var/lock/subsys/ec2-termination
      }
      case "$1" in
          start)
             start
             ;;
          stop)
             stop
             ;;
          restart)
             stop
             start
             ;;
          status)
             ;;
          *)
             echo "Usage: $0 {start|stop|status|restart}"
      esac
      exit 0

runcmd:
  - chkconfig ec2-termination --level 12345 on
  - chkconfig ec2-termination --level 06 off
  - service ec2-termination start
  - systemctl start docker
  - systemctl enable docker
  - usermod -a -G docker ec2-user
  - docker run -d --privileged --restart=unless-stopped --net=host -v /etc/kubernetes:/etc/kubernetes -v /var/run:/var/run rancher/rancher-agent:v2.2.5 --server https://rancher.example.com --token <token>  --worker

I am working on something similar but more specific to GPU nodes. But the overall approach is the same:

custom rancher cluster
cloud-config to register with rancher and install any custom tools

the difference that I am building a custom auto-scaler for now before something is ready from the Rancher team.

I don't see a reason to build a custom autoscaler when Kubernetes provides its own official autoscaler.
Also Nvidia has Kubernetes support, so I believe cluster autoscaler can scale based on gpu metrics too.

@azelezni I am not suggesting anyone doing it, it's specific to our situation. As far as I know, official autoscaler doesn't allow you to have cloud-init for your nodes, if it did - would be awesome. If you check support for Azure specifically, it goes only for clusters built with aks-engine or managed azure service and we are using Rancher.

And one more reason doing it now is because Rancher will probably have to consider N variables/platforms before offering cluster-autoscaler, we just need one on Azure for now, so complexity on our side is much smaller than one of a generic solution.

The autoscaler is probably the most wrongly understood and overrated component. It is currently only designed to work with clouds and is yet actually quite limited in its functionality. When rancher matures its node pool concept, actually they would get a huge advantage in front of the whole market, b/c combined with an adaption for the rancher api on the autoscaler, this would mean, that the autoscaler for the first time would be platform agnostic, instead of relying on autoscaling sets on the side of the provider and an actual implementation behind it.
To the support argument, I disagree, there is not much support needed for a first version of this. First of all you can reuse and reflect the logic in the autoscaler that exists for aws, gce and azure to retain the functionality for the scaling strategy. However for all other platforms all you would need is to offer an option, to define a predefined json structure for your node pool, which contains information about the pricing, the specs and other related things. Everything else is already perfectly handled by the current docker-machine provisioning setup. If you want ultimate flexibility, allow the user to pass an url to a service that the user can create, from which they can retrieve the information dynamically, where the user might just write a passthrough for the specific cloud.

To the support argument, I disagree, there is not much support needed for a first version of this. fingers crossed :) I will gladly switch to it when it's done - having auto-scaler working as part of the cluster with node pools is much better user experience than custom cluster where you can't define node pools (or maybe you can, but I haven't found documentation on that)

I already did some work on this at my last employer @wzrdtales.
This fork of the official autoscaler, has a functional implementation of a cloud provider for the rancher api.
https://github.com/jepp2078/autoscaler/tree/rancher-cloud-provider
Back then some work was required from ranchers side, since scaledown was handled differently in rancher versus the autoscaler (rancher scales down by removing the newest node, autoscaler does so by removing the most under-used node).

yup ik @jepp2078 and I already evaluated it. It fell through though, since it is too limited yet. But that is due to ranchers unmatured node pool concept that doesn't fit this use case currently. I also fall back for now to a manual cluster that places in the cloud init config the rancher boot up. The only advantage of that approach is that it works on multiple clouds/datacenters with the same cluster.

This is the easy part, it gets hard when you try to scale down, since terminated workers still remain in rancher in status Kubelet stopped posting node status.

This should be fixed in 2.3. Rancher will respect kubectl get nodes as the state of the cluster and the UI will reflect that.

Hi, Are we already able with 2.3.1 to perform cluster autoscaling on openstack driver?

Hi, Are we already able with 2.3.x to perform cluster autoscaling on vsphere driver?

This seems wrong - the cloud plugins / controllers are supposed to trigger removal of node on scale down.

So progress is: We have taints and removal support. So we're only lacking a custom json field on the node pool to store configuration on and we're ready to go to to adjust the cluster autoscaler component accordingly.

Presumably this will require a slight api change- take node pools from "number of nodes" to "minimum/desired/maximum" like an AWS asg?
Have to admit, was pretty suprised when I realized this didn't already work- figured that was the whole reason for the node pool concept in the first place.

Is there an ETA on when this feature will be implemented in rancher? We are currently evaluating rancher to potentially switch all our clusters to it but it fell short on autoscaling which is necessary for many of our cluster. We can delay switching to rancher if this is going to be released some time soon. Thanks!

Is there any progress of this feature request?
I think autoscaling is an important part of the puzzle that is missing in Rancher.
Most of production environments use this feature, not need to explain why.
it will lift up Rancher usage in the community.

Any progress on this?
I'm currently evaluating this and cluster autoscaling is a hard requirement for production usage.
Can you maybe share some new info @maggieliu ?
It would be highly appreciated.

My company is also looking for an easy solution for auto scaling nodes from within rancher.

I write my custom microservice for rancher api, https://github.com/Negashev/rancher-scale-webhook (docker negash/rancher-scale-webhook)
by CPU reservation and Rancher Alerts by Prometheus metrics with cordon scale down (sorry without documentation)
  containers:
  - env:
    - name: RANCHER_CORDONED_CPU
      value: "7" <= reserved 7% cpu (first hook corden and next hook down)
    - name: RANCHER_NODEPOOL_URL
      value: https://rancher.server.com/v3/nodePools/c-dddas:np-v5dud
    - name: RANCHER_TOKEN
      value: token-s5677:w45ve45e45v
    - name: TOKEN
      value: my-tokec
    image: negash/rancher-scale-webhook

logs of scale service

Alerts in Cluster (with timing , check to uncordon/scale up every 3 minutes, check to cordon/scale down  every 10 minutes)

Alert with kube_pod_container_resource_requests, kube_node_status_capacity_cpu_cores and kube_node_spec_unschedulable

Just use Cluster Autoscaler, it works great and with the new versions of rancher there is no issue of missing nodes.

Just use Cluster Autoscaler, it works great and with the new versions of rancher there is no issue of missing nodes.

But why is rancher than not listed as a supported deployment method in the readme?
https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/README.md#deployment

Because Rancher is not a cloud provider, Cluster Autoscaler works directly with the cloud provider your cluster runs on (AWS, GKE, etc...), Rancher too uses the cloud provider to provision the cluster.

Okay, sorry, that may be a mixup of terminology on my side.
the point is, however, that the cluster autoscaler project has no direct support to run on openstack, as far as I can see? there seems to be some support for magnum, will investigate this further.
Thanks for the information so far!

At this time, the Kubernetes cluster autoscaler works with the cloud providers on Rancher. Rancher 2.3 improved node reconciliation that addressed nodes being left in an orphaned state when scaling down. Support was also added for the horizontal pod autoscaler in the UI along with Prometheus metrics integration. These capabilities should allow users to autoscale on the major community-supported IaaS layers.
Autoscaling Rancher node pools is on our roadmap and we will provide updates here when we have more info to share.

@cloudnautique Is there any documentation regarding setting up cluster autoscaling?

At this time, the Kubernetes cluster autoscaler works with the cloud providers on Rancher. Rancher 2.3 improved node reconciliation that addressed nodes being left in an orphaned state when scaling down. Support was also added for the horizontal pod autoscaler in the UI along with Prometheus metrics integration. These capabilities should allow users to autoscale on the major community-supported IaaS layers.
Autoscaling Rancher node pools is on our roadmap and we will provide updates here when we have more info to share.
@cloudnautique
Would you have any idea of an eta or version that we should expect this feature? If not, would you be able to share any details of how this is best approached from a Rancher point of view as a workaround until then? This would be very interesting! Many thanks!

i made this,
https://github.com/guyta-essence/rna
it can help

Trying to avoid cloud provider route(GKE,AKS,EKS) and go bare metal using cloud infra.  Get more control that way. But, need cluster auto scaler to work at a minimum to at least enable us to add nodes if a new cluster is requested which requires more nodes.  Could this work if we used auto scale groups (AWS), or VM Scale Sets (Azure), as the VM type within Rancher node pool?  Would this enable us to achieve auto scale?

Trying to avoid cloud provider route(GKE,AKS,EKS) and go bare metal using cloud infra. Get more control that way. But, need cluster auto scaler to work at a minimum to at least enable us to add nodes if a new cluster is requested which requires more nodes. Could this work if we used auto scale groups (AWS), or VM Scale Sets (Azure), as the VM type within Rancher node pool? Would this enable us to achieve auto scale?

have a look at my solution https://github.com/guyta-essence/rna

Thanks Guy.  Looks like a good workaround.  It looks like it triggers based
on resource utilization metrics.  Can it also trigger based on a request
from the Kubernetes Auto scaler because a new pod is being created which
needs more CPU?  Also, how do you integrate this within Rancher?
On Tue, Jun 30, 2020 at 1:33 AM Guy Tadmor notifications@github.com wrote:

Trying to avoid cloud provider route(GKE,AKS,EKS) and go bare metal using
cloud infra. Get more control that way. But, need cluster auto scaler to
work at a minimum to at least enable us to add nodes if a new cluster is
requested which requires more nodes. Could this work if we used auto scale
groups (AWS), or VM Scale Sets (Azure), as the VM type within Rancher node
pool? Would this enable us to achieve auto scale?
have a look at my solution https://github.com/guyta-essence/rna
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rancher/rancher/issues/15145#issuecomment-651643847,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AO75HOWKJ23QUE6HIWFBTKDRZGPODANCNFSM4FQQJHIQ
.

@Negashev

I write my custom microservice for rancher api, https://github.com/Negashev/rancher-scale-webhook (docker negash/rancher-scale-webhook)
by CPU reservation and Rancher Alerts by Prometheus metrics with cordon scale down (sorry without documentation)
  containers:
  - env:
    - name: RANCHER_CORDONED_CPU
      value: "7" <= reserved 7% cpu (first hook corden and next hook down)
    - name: RANCHER_NODEPOOL_URL
      value: https://rancher.server.com/v3/nodePools/c-dddas:np-v5dud
    - name: RANCHER_TOKEN
      value: token-s5677:w45ve45e45v
    - name: TOKEN
      value: my-tokec
    image: negash/rancher-scale-webhook

logs of scale service

Alerts in Cluster (with timing , check to uncordon/scale up every 3 minutes, check to cordon/scale down every 10 minutes)

Alert with kube_pod_container_resource_requests, kube_node_status_capacity_cpu_cores and kube_node_spec_unschedulable

Would it be possible for you to provide additional information for setting up in Rancher? This seems like a straight forward solution for use with node pools from node drivers that have the number of nodes in that pool accessible to change from API.

@jonathon2nd
  containers:
  - name: scale
    env:
    - name: RANCHER_CORDONED_CPU
      value: "7" # if <= reserved 7% cpu "first hook corden and next hook down"
    - name: RANCHER_NODEPOOL_URL
      value: https://rancher.server.com/v3/nodePools/c-dddas:np-v5dud # pool url (from api) for scale
    - name: RANCHER_TOKEN
      value: token-s5677:w45ve45e45v
    - name: TOKEN
      value: redacted
    image: negash/rancher-scale-webhook

service for scale with example IP 10.43.43.43
post webhook scale up
curl -XPOST http://10.43.43.43:8080/up/redacted
post  webhook scale down
curl -XPOST http://10.43.43.43:8080/down/redacted
when you deploy webhook service to rancher (with rancher monitoring and two notify with UP and DOWN webhooks configs) you need to config alerts (UP and DOWN) by Prometheus query:
ALERT for my gitlab ci VMs with 8 cpu
UP Greater Than 0.7:
(sum(kube_pod_container_resource_requests{namespace="gitlab-managed-apps",node=~"git-ci-worker.*",resource="cpu"}) or vector(2)) / sum(kube_node_status_capacity_cpu_cores{node=~"git-ci-worker.*"} - (kube_node_spec_unschedulable{node=~"git-ci-worker.*"} * 8))

DOWN Greater Than 2:
(sum(kube_node_status_capacity_cpu_cores{node=~"git-ci-worker.*"})/(sum(kube_pod_container_resource_requests{resource="cpu",namespace="gitlab-managed-apps",node=~"git-ci-worker.*"}) OR vector(8))) OR vector(0)

@Negashev I was able to get this working, thanks!

NOT PRODUCTION READY
Thanks for @luthermonson
By this video
https://info.rancher.com/kubernetes-master-class-apr6-2021
I can install https://github.com/kubernetes/autoscaler

You need in cloud provider on our k8s cluster for node(s).spec.ProviderID - it's important for kubernetes/autoscaler
Add catalog https://github.com/kubernetes/autoscaler to rancher
Add secret to cluster-autoscaler-cloud-config to kube-system

apiVersion: v1
kind: Secret
metadata:
  name: cluster-autoscaler-cloud-config
  namespace: kube-system
type: Opaque
stringData:
  cloud-config: |
    [Global]
    url=https://rancher.com/v3
    access=token-tttttt
    secret=secretsecretsecretsecretsecret
    cluster-id=c-qwerty

Deploy autoscaler app v 9.9.2 from catalog (from step 2) to kube-system (yes you can add pools to autoscalingGroups[])

autoscalingGroups[0].maxSize: 10
autoscalingGroups[0].minSize: 1
autoscalingGroups[0].name: c-qwerty:np-qwerty
cloudProvider: rancher
extraArgs.cloud-config: /config/cloud-config
extraVolumeSecrets.cluster-autoscaler-cloud-config.mountPath: /config
extraVolumeSecrets.cluster-autoscaler-cloud-config.name: cluster-autoscaler-cloud-config
image.repository: luthermonson/autoscaler
image.tag: rancher

Try to help on https://github.com/kubernetes/autoscaler/pull/4041

@Negashev  What does the following lines corresponds to when we are using rancher as the cloud provider
extraArgs.cloud-config: /config/cloud-config extraVolumeSecrets.cluster-autoscaler-cloud-config.mountPath: /config extraVolumeSecrets.cluster-autoscaler-cloud-config.name: cluster-autoscaler-cloud-config

For rke2 (work on rancher 2.6.4)
https://github.com/shpwrck/rancher-clusterapi-autoscaling

https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/rancher

authors: Amos-85 Coopyrightdmin Negashev SvenMW Tonne-TM ajfriesen amy-bachir azelezni carlcauchi casz cloudnautique daxmc99 guyta-essence jepp2078 jonathon2nd jplfp lw8008 mlushpenko nenadzaric pbecotte smetal1 steveabbitt tmedford tomlucasSQL vsabella wzrdtales

repo: rancher/rancher


text:
Adding hosts via private networks leaves host without any public IP registerd

When setting host registration to use the private network the new host is added correctly however the only IP address that gets registered is the private IP of the host. Then when adding a balanced service the load balancer is configured on the private ip and so you can never get to the service.
New hosts should try and be intelligent with their IP reporting. Typically eth0 is the public interface, or there should be a way to specify the IP address of a host.

Note this is mostly a UI issue in that when you create a host using the EC2 api or DO api for example I don't want to have to login to those accounts to work out how to access my containers

This also causes things like viewing container logs and executing console on hosts doesn't work

@haswalt thanks for the feedback. Wi'll look into all the issues you mentioned, but want to start with the last one first: I'm surprised that this causes logs and exec not to work. Do you have behind a elastic load balancer or any other proxy?
Next, we do have a way to allow you to explicit set a host's IP, but it's only available when you add a custom host and execute the docker run ... rancher/agent command on the host yourself. When you do that, you can add -e CATTLE_AGENT_IP=<desired ip>.
Next, I don't have a great answer for your balanced service problem. Will need to investigate it a little more.
Can you share the version of Rancher that are you using? If you inspect the rancher/server container, you'll see an environment called CATTLE_RANCHER_SERVER_IMAGE that has that information.

I'm currently using v0.31.0-rc3.
There is no load balancer or proxy in front of the instances. Hosts talked to the server via the private network. The websocket proxy is also running over the private network as well.
I get no error messages or log output when attempting to connect to the container console or get logs.
If I change the CATTLE_AGENT_IP won't that mean that the host won't communicate over the private network?
In my setup in attempting to get all orchestration traffic to run over the private network (99% works) and only expose the public network to incoming container traffic such as web.

I've just found the issue for the connecting to the console and it is related. Basically because the host gets configured with the private ip the browser then attempts to use the private ip for the web socket connection which it can access. I'd expect some way to allow rancher to handle public traffic and let orchestration between host and server to go over the private network

A couple things don't line up here.  I'll investigate further.  The IP of the host is used only to setup the private network and nothing else.
The console/logs go directly to the server now.  In the past the web browser would connect to the host but that is no longer the case.  You web browser needs to talk to the rancher/server and nothing else.
When we bind a load balancer to the host we actually don't bind it to a specific IP.  It is essentially all IPs.  In the case of EC2 the load balancer will be available on your EIP if you have your security groups setup.  If you create a host through the UI unfortunately the default behavior of Docker Machine is to not open any ports except those needed by Docker.

@ibuildthecloud So here is some more information:
I added the hosts manually and I started the agent with this command:
docker run -d --privileged -e CATTLE_AGENT_IP=46.101.4.70 -v /var/run/docker.sock:/var/run/docker.sock rancher/agent:v0.7.11 http://10.131.252.223/v1/scripts/3329F2900677B4EC9733:1438534800000:nMBfjQpEeEIWsYSWoL1YLhPMQmo

So you can see that the CATTLE_AGENT_IP is set to the public IP of host and the private IP address is used to connect tot he server.
If I try to view container logs in the browser for a container running on this host I see the following in the browser:
Socket connect 3 to ws://10.131.252.223:9000/v1/stats/9e9e74bc3e2411a4b848f5f6cba20ecd041745a186b11b696ede2ec817f95f19...

Of course that fails as the private IP can't be accessed over the WAN.

Currently use:
Component	Version
Rancher	v0.32.0
Cattle	v0.75.0
User Interface	v0.40.0
Rancher Compose	beta/latest

@haswalt Did you install rancher using our simple single-node setup or do you have a multi-node setup? "Node" in this case refers to instances of rancher/server.
Also, I see that in your docker run, the connection URL is http://10.131.252.223/v1, with no port and in the socket connect error, it is ws://10.131.252.223:9000/v1/, with port 9000. So, what do you have running on port 9000 and where did you configuring that?
I'm going to take a guess and say that you followed this multinode setup:
http://docs.rancher.com/rancher/installing-rancher/installing-server/multi-nodes/
and set ...-e CATTLE_HOST_API_PROXY_HOST="10.131.252.223:9000" ... is that right?

@cjellick Your guess is correct, and yes the CATTLE_HOST_API_PROXY_HOST is set with the port number. Everything works as expected that i can see except for the viewing of logs and stats for hosts and containers due to the proxy connecting issue above

@haswalt The IP you configure for the websocket proxy needs to be accessible from your browser and from the hosts. The hosts make outbound connections to it and browsers connect directly to it as well.
So, CATTLE_HOST_API_PROXY_HOST for rancher/server would need to have the public IP of the server running the websocket proxy and the websocket proxy's -listen-address=<ip:port> param would need to be 0.0.0.0:9000.

@cjellick Thanks for the tip. Maybe worth adding some hinst about these environment settings and how they should be configured to make it clearer for others trying the same setup as me

We've added more docs to make it clearer. https://github.com/rancher/rancher.github.io/pull/79

authors: cjellick deniseschannon haswalt ibuildthecloud


text:
Restrict selectorLink from being set for external Services and ability to add service links to external services.

Server version - Build from master = Oct 7
Steps to reproduce the problem:
Created a External service S1 with - selector_link as "foo=bar".
Created a service S2 with label = "foo" and value as "bar.
External service gets linked with S2.
Create service S3 with service link to S1.
From containers of S3 , there is no way to resolve containers of S2.
Since this is not supported , expected behavior should be for API to not allow externalServices being created with external Services field set.
On a similar note, we should also restrict the ability to add service links to External Services.

Tested with latest build from master
We do not have the ability to add  selectorLink  for external Services. Also add/set/remove service links are not permitted actions on external services anymore.


text:
Standard user can't deploy the gatekeeper app.

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

Create a cluster.
Create one standard user and make it cluster owner for the cluster created.
Through API  https://rancher-server/v1/management.cattle.io.clusters/c-xxxx/apps try to deploy the gatekeeper app

Result:
API returns 404.
When API request is made with admin token, it returns 201 and deploys the app.
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): master-2486-head- cf6d0c979
Installation option (single install/HA): Single

Related issue for admin user - https://github.com/rancher/rancher/issues/26186
The same issue is also encountered for standard user when trying to enable OPA gatekeeper app.
Request URL: https://<ip>/v1/management.cattle.io.clusters/c-xfzxp/apps/p-tgvm6
Request Method: POST
Status Code: 405 Method Not Allowed

Tested with Rancher Server version `371ec137f``
As standard user , deploy a cluster.
Launch Dashboard.
Enable "OPA Gatekeeper".
Able to enable "OPA Gatekeeper" successfully.

Verified on Rancher server master-2523-head- 371ec137f
API:

Enable OPA Gatekeeper with standard user.
Enable OPA Gatekeeper with admin user.

Dashboard

As a standard user deployed a cluster.
Launched Dashboard - Encountered https://github.com/rancher/dashboard/issues/393
Enable 'OPA Gatekeeper'
Create a constraint for repo whitelisting.
Verified the violation.
Verified all of the above with admin user too.

Encountered the refresh issues while verifying above functionality https://github.com/rancher/dashboard/issues/371

authors: khushboo-rancher sangeethah


text:
Error relating to "kubeclt apply failed" presented for around 5 minutes during cluster provisioning

Version: master-head(00ff15976)
Steps:

Create a DO cluster in master-head
Provisioning error is displayed as below for around 5 minutes.

It recovers after 5 minutes

This happened to me today
Rancher version master-head (08/12/2020) d19f179c4
I was using DO driver to provision a cluster. Usually after deploying Rancher and provisioning a cluster shortly after I get this error occasionally

Tested with master-head(master-76c26fb0f9)
Deployed few node driver and custom clusters.
The error as mentioned above was not observed during provisioning.

authors: izaac soumyalj


text:
Run Conformance Testing

Need to run the conformance test on:
Rancher => 1.18
RKE1 => 1.18
Rancher => 1.17
And submit the result to: https://github.com/cncf/k8s-conformance

https://github.com/cncf/k8s-conformance/pull/1110
https://github.com/cncf/k8s-conformance/pull/1111
https://github.com/cncf/k8s-conformance/pull/1112

All PRs have been merged.
RKE v1.18
Rancher RKE v1.17, v1.18 are all certified

authors: bmdepesa maggieliu


text:
Running "kubectl rollout status deployment xxx --timeout 3s" does not automatically timeout

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

Under the Default project, create a workload named Test, set it to the Deployment type, and run it in the default namespace;
Edit the Test workload to change the image to a name that does not exist;
Switch to the cluster layer and click the launch Kubectl button;
Enter the kubectl rollout status deployment test --timeout 1s  command and run;

Result:
The command will remain stuck and will not automatically timeout.

After testing, the local cluster is able to respond to the timeout parameter normally

Other details that may be helpful:
Environment information

Rancher version :
rancher/rancher:v2.3.8

Installation option :
HA

Cluster information

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

Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", BuildDate:"2020-08-26T21:54:15Z", GoVersion:"go1.15", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-15T16:51:04Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

The test passed on v2.4.8


text:
[Logging] ImgPullErr when Private registry is used in Airgap with downstream clusters

What kind of request is this:
bug
Steps to reproduce:

Airgap downstream clusters container images from Charts fail with ImgPullErr
This happens with v2 charts. in Airgap setup

Result:

rancher-logging and other charts fail to deploy.

Failed to pull image "rancher/banzaicloud-logging-operator:3.6.0": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Other details that may be helpful:
local k3s cluster is working
Environment information

Rancher version: v2.5.0-alpha4
Installation option: HA single Rancher install

If this is happening with all charts and not in local cluster, then its not logging specific. Is this docker install or HA ? May be related to https://github.com/rancher/rancher/issues/28923

@izaac can we get some more information on this specific one.

If you are installing on local and on downstream, given a specific image like logging-operator, what is the full image path the deployment is attempting to pull on both of them
If you restart the downstream agent and uninstall, then install, does it fix the problem ?
Does this occur on more charts than just logging ? Sounds like yes, but only downstream.

https://github.com/rancher/charts/pull/671

Rancher version: v2.5.0-alpha5 (09/22/2020) HA k8s Airgap with RKE custom downstream cluster.
Custom cluster has private registry set. Monitoring chart was deployed without issues.
ImagePullBackOff: Back-off pulling image "rancher/banzaicloud-logging-operator:3.6.0"
ErrImagePull: rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

https://github.com/rancher/charts/pull/691

Rancher version v2.5.0-rc1
I see all the images getting pulled from the private registry configured in the Airgap setup and the cluster configuration.
k get all -n cattle-logging-system -o wide
NAME                                                              READY   STATUS      RESTARTS   AGE     IP           NODE              NOMINATED NODE   READINESS GATES
pod/rancher-logging-b4478c579-xlrnb                               1/1     Running     0          10m     10.42.2.10   ip-172-31-9-106   <none>           <none>
pod/rancher-logging-fluentbit-9wd25                               1/1     Running     0          10m     10.42.1.14   ip-172-31-1-243   <none>           <none>
pod/rancher-logging-fluentbit-gjzh2                               1/1     Running     0          10m     10.42.0.16   ip-172-31-3-230   <none>           <none>
pod/rancher-logging-fluentbit-kgj9s                               1/1     Running     0          10m     10.42.2.16   ip-172-31-9-106   <none>           <none>
pod/rancher-logging-fluentd-0                                     2/2     Running     0          10m     10.42.0.13   ip-172-31-3-230   <none>           <none>
pod/rancher-logging-fluentd-configcheck-423fc442                  0/1     Completed   0          6m52s   10.42.1.15   ip-172-31-1-243   <none>           <none>
pod/rancher-logging-rke-containers-fluentbit-49rrx                1/1     Running     0          10m     10.42.0.15   ip-172-31-3-230   <none>           <none>
pod/rancher-logging-rke-containers-fluentbit-sh9tk                1/1     Running     0          10m     10.42.1.13   ip-172-31-1-243   <none>           <none>
pod/rancher-logging-rke-containers-fluentbit-xrmhg                1/1     Running     0          10m     10.42.2.15   ip-172-31-9-106   <none>           <none>
pod/rancher-logging-rke-containers-fluentd-0                      2/2     Running     0          10m     10.42.2.13   ip-172-31-9-106   <none>           <none>
pod/rancher-logging-rke-containers-fluentd-configcheck-423fc442   0/1     Completed   0          6m52s   10.42.1.17   ip-172-31-1-243   <none>           <none>
pod/rancher-logging-rke-fluentbit-bzdtz                           1/1     Running     0          10m     10.42.1.12   ip-172-31-1-243   <none>           <none>
pod/rancher-logging-rke-fluentbit-ggnb9                           1/1     Running     0          10m     10.42.0.14   ip-172-31-3-230   <none>           <none>
pod/rancher-logging-rke-fluentbit-pwgrf                           1/1     Running     0          10m     10.42.2.14   ip-172-31-9-106   <none>           <none>
pod/rancher-logging-rke-fluentd-0                                 2/2     Running     0          10m     10.42.1.11   ip-172-31-1-243   <none>           <none>
pod/rancher-logging-rke-fluentd-configcheck-423fc442              0/1     Completed   0          6m52s   10.42.1.16   ip-172-31-1-243   <none>           <none>

NAME                                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)               AGE   SELECTOR
service/rancher-logging                          ClusterIP   None            <none>        8080/TCP              10m   app.kubernetes.io/instance=rancher-logging,app.kubernetes.io/name=rancher-logging
service/rancher-logging-fluentd                  ClusterIP   10.43.76.12     <none>        24240/TCP,24240/UDP   10m   app.kubernetes.io/component=fluentd,app.kubernetes.io/managed-by=rancher-logging,app.kubernetes.io/name=fluentd
service/rancher-logging-rke-containers-fluentd   ClusterIP   10.43.172.90    <none>        24240/TCP,24240/UDP   10m   app.kubernetes.io/component=fluentd,app.kubernetes.io/managed-by=rancher-logging-rke-containers,app.kubernetes.io/name=fluentd
service/rancher-logging-rke-fluentd              ClusterIP   10.43.104.188   <none>        24240/TCP,24240/UDP   10m   app.kubernetes.io/component=fluentd,app.kubernetes.io/managed-by=rancher-logging-rke,app.kubernetes.io/name=fluentd

NAME                                                      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE   CONTAINERS   IMAGES                                                                               SELECTOR
daemonset.apps/rancher-logging-fluentbit                  3         3         3       3            3           <none>          10m   fluent-bit   ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/fluent-fluent-bit:1.5.4   app.kubernetes.io/managed-by=rancher-logging,app.kubernetes.io/name=fluentbit
daemonset.apps/rancher-logging-rke-containers-fluentbit   3         3         3       3            3           <none>          10m   fluent-bit   ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/fluent-fluent-bit:1.5.4   app.kubernetes.io/managed-by=rancher-logging-rke-containers,app.kubernetes.io/name=fluentbit
daemonset.apps/rancher-logging-rke-fluentbit              3         3         3       3            3           <none>          10m   fluent-bit   ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/fluent-fluent-bit:1.5.4   app.kubernetes.io/managed-by=rancher-logging-rke,app.kubernetes.io/name=fluentbit

NAME                              READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS        IMAGES                                                                                SELECTOR
deployment.apps/rancher-logging   1/1     1            1           10m   rancher-logging   ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/banzaicloud-logging-operator:3.6.0   app.kubernetes.io/instance=rancher-logging,app.kubernetes.io/name=rancher-logging

NAME                                        DESIRED   CURRENT   READY   AGE   CONTAINERS        IMAGES                                                                                SELECTOR
replicaset.apps/rancher-logging-b4478c579   1         1         1       10m   rancher-logging   ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/banzaicloud-logging-operator:3.6.0   app.kubernetes.io/instance=rancher-logging,app.kubernetes.io/name=rancher-logging,pod-template-hash=b4478c579

NAME                                                      READY   AGE   CONTAINERS                IMAGES
statefulset.apps/rancher-logging-fluentd                  1/1     10m   fluentd,config-reloader   ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/banzaicloud-fluentd:v1.11.2-alpine-2,ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/jimmidyson-configmap-reload:v0.2.2
statefulset.apps/rancher-logging-rke-containers-fluentd   1/1     10m   fluentd,config-reloader   ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/banzaicloud-fluentd:v1.11.2-alpine-2,ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/jimmidyson-configmap-reload:v0.2.2
statefulset.apps/rancher-logging-rke-fluentd              1/1     10m   fluentd,config-reloader   ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/banzaicloud-fluentd:v1.11.2-alpine-2,ec2-x-x-x-x.us-east-2.compute.amazonaws.com/rancher/jimmidyson-configmap-reload:v0.2.2

authors: cbron izaac paynejacob


text:
Downstream cluster toggles between Active and Unavailable states for sometime after a rancher server upgrade

Rancher Server Setup

Rancher version: 2.5.11 to 2.6.3-rc4
Installation option (Docker install/Helm Chart): docker install

Information about the Cluster

Kubernetes version: RKE1 DO cluster of all 4k8s versions (4 clusters)

Describe the bug
Downstream cluster toggles between Active and Unavailable state for sometime after a rancher server upgrade
To Reproduce

On 2.5.11, deploy 4 downstream clusters
upgrade rancher to 2.6.3-rc4
The cluster toggles between Active and Unavailable states for sometime (~30 secs - 1min) before coming back up Active

Note:

This is a change in behavior from prev rancher versions.
Earlier it used to switch to Unavailable one time before coming back up Active
This new change seems like a bad UX experience for the users. (But it will eventually turn back up Active)

@sowmyav27 Is the Unavailable state because of cluster agent is redeploying? This should show up in the UI or in the conditions under view in yaml of the cluster. I think this sounds very similar to https://github.com/rancher/rancher/issues/35640.

Available to test after https://drone-publish.rancher.io/rancher/rancher/6988 merges.

On an upgrade from 2.6.2 to 2.6-head commit id: 77392a

Cluster stay in Active state during cluster agent upgrade also
Had one rke1 node driver cluster downstream


text:
message=cluster status version is not available yet.  for Rancher 2.6.3

I am using Rancher 2.6.3 to deploy setup in AWS. ap-south-1
used helm : 2.5.1
used kubernetes_version : v1.21.7-rancher1-1
used cluster monitoring version is : 0.3.1 / 0.3.2
Got the below error for both monitoring versions :
module.rke_custom_cluster.null_resource.wait_for_rancher2 (local-exec): Executing: ["/bin/sh" "-c" "sleep 90"]
module.rke_template.rancher2_cluster_template.RKE_Template: Creating...
module.rke_template.rancher2_cluster_template.RKE_Template: Creation complete after 5s [id=cattle-global-data:ct-lxdnc]
module.rke_custom_cluster.null_resource.wait_for_rancher2: Still creating... [10s elapsed]
module.rke_custom_cluster.null_resource.wait_for_rancher2: Still creating... [20s elapsed]
module.rke_custom_cluster.null_resource.wait_for_rancher2: Still creating... [30s elapsed]
module.rke_custom_cluster.null_resource.wait_for_rancher2: Still creating... [40s elapsed]
module.rke_custom_cluster.null_resource.wait_for_rancher2: Still creating... [50s elapsed]
module.rke_custom_cluster.null_resource.wait_for_rancher2: Still creating... [1m0s elapsed]
module.rke_custom_cluster.null_resource.wait_for_rancher2: Still creating... [1m10s elapsed]
module.rke_custom_cluster.null_resource.wait_for_rancher2: Still creating... [1m20s elapsed]
module.rke_custom_cluster.null_resource.wait_for_rancher2: Still creating... [1m30s elapsed]
module.rke_custom_cluster.null_resource.wait_for_rancher2: Creation complete after 1m30s [id=8163581672400586779]
module.rke_custom_cluster.rancher2_cluster.rancher2-custom-cluster: Creating...

Error: Bad response statusCode [422]. Status [422 Unprocessable Entity]. Body: [baseType=error, code=InvalidBodyContent, message=cluster [c-2rk69] status version is not available yet. Cannot validate kube version for template [system-library-rancher-monitoring-0.3.2]] from [https://ec2-15-207-72-116.ap-south-1.compute.amazonaws.com/v3/clusters/c-2rk69?action=enableMonitoring]

  on .terraform/modules/rke_custom_cluster/rancher2_custom_cluster.tf line 20, in resource "rancher2_cluster" "rancher2-custom-cluster":
  20: resource "rancher2_cluster" "rancher2-custom-cluster" {

0.3.1 :
Error: Bad response statusCode [422]. Status [422 Unprocessable Entity]. Body: [baseType=error, code=InvalidBodyContent, message=cluster [c-2rk69] status version is not available yet. Cannot validate kube version for template [system-library-rancher-monitoring-0.3.1]]
Got below error If i use the lower version of cluster monitoring : 0.1.0 and 0.1.4 :
Error: Bad response statusCode [422]. Status [422 Unprocessable Entity]. Body: [baseType=error, code=InvalidBodyContent, message=rancher max version exceeded] from [https://ec2-13-235-242-49.ap-south-1.compute.amazonaws.com/v3/clusters/c-q5r7l?action=enableMonitoring]

Deploy rancher setup with => Rancher 2.6.3 - Rocky Linux 8.x
Updated required versions which is suitable suits the rancher 2.6.3 :
https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-6-3/


text:
highlight for service alias target drop-down is covering part of - button

Version - v1.0.1
Steps to Reproduce:

Add Service Alias
Move mouse over Select a service drop-down

Results: highlight is partially covering the - button.  Really noticeable in dark theme but it's also in the light theme.

Expected:  Should only highlight drop-down itself

https://github.com/rancher/ui/pull/708

Version - master 6/9
Verified fixed

authors: lvuch tfiduccia


text:
Table 'rancher.setting' doesn't exist

Rancher Version:v1.0.1 and latest

Docker Version:Docker version 1.11.1, build 5604cbe

OS and where are the hosts located? (cloud, bare metal, etc): Ubuntu 14.04 on Rackspace

Setup Details: (single node vs. single node, internal DB vs. external DB)*: single node external database

Environment Type: (Cattle/Kubernetes/Swarm/Mesos): Haven't gotten this far

Steps to Reproduce: Just starting using the follow docker command. Password and host stared out:
sudo docker run -d --restart=always -p 8080:8080 -e CATTLE_DB_CATTLE_MYSQL_HOST=%%%.rackspaceclouddb.com -e CATTLE_DB_CATTLE_MYSQL_PORT=3306 -e CATTLE_DB_CATTLE_MYSQL_NAME=rancher -e CATTLE_DB_CATTLE_USERNAME=%%% -e CATTLE_DB_CATTLE_PASSWORD=%%% rancher/server:v1.0.1

Results: I get this in the logs
2016-05-13 02:13:50,298 ERROR [:] [] [] [] [igurationSource] [c.n.config.AbstractPollingScheduler ] Error getting result from polling source java.sql.SQLSyntaxErrorException: Table 'rancher.setting' doesn't exist
at org.mariadb.jdbc.internal.util.ExceptionMapper.get(ExceptionMapper.java:125) ~[mariadb-java-client-1.3.4.jar:na]
at org.mariadb.jdbc.internal.util.ExceptionMapper.throwException(ExceptionMapper.java:69) ~[mariadb-java-client-1.3.4.jar:na]
at org.mariadb.jdbc.MariaDbStatement.executeQueryEpilog(MariaDbStatement.java:261) ~[mariadb-java-client-1.3.4.jar:na]
at org.mariadb.jdbc.MariaDbStatement.execute(MariaDbStatement.java:290) ~[mariadb-java-client-1.3.4.jar:na]
at org.mariadb.jdbc.MariaDbStatement.executeQuery(MariaDbStatement.java:448) ~[mariadb-java-client-1.3.4.jar:na]
at org.mariadb.jdbc.MariaDbClientPreparedStatement.executeQuery(MariaDbClientPreparedStatement.java:119) ~[mariadb-java-client-1.3.4.jar:na]
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) ~[commons-dbcp-1.4.jar:1.4]
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) ~[commons-dbcp-1.4.jar:1.4]
at com.netflix.config.sources.JDBCConfigurationSource.load(JDBCConfigurationSource.java:107) ~[archaius-core-0.5.14.jar:na]
at com.netflix.config.sources.JDBCConfigurationSource.poll(JDBCConfigurationSource.java:88) ~[archaius-core-0.5.14.jar:na]
at io.cattle.platform.archaius.sources.LazyJDBCSource.poll(LazyJDBCSource.java:31) ~[cattle-framework-archaius-0.5.0-SNAPSHOT.jar:na]
at com.netflix.config.AbstractPollingScheduler$1.run(AbstractPollingScheduler.java:163) ~[archaius-core-0.5.14.jar:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_95]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) [na:1.7.0_95]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [na:1.7.0_95]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.7.0_95]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_95]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_95]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_95]
Caused by: org.mariadb.jdbc.internal.util.dao.QueryException: Table 'rancher.setting' doesn't exist
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.getResult(AbstractQueryProtocol.java:475) ~[mariadb-java-client-1.3.4.jar:na]
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.result(AbstractQueryProtocol.java:396) ~[mariadb-java-client-1.3.4.jar:na]
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.executeQuery(AbstractQueryProtocol.java:378) ~[mariadb-java-client-1.3.4.jar:na]
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.executeQuery(AbstractQueryProtocol.java:334) ~[mariadb-java-client-1.3.4.jar:na]
at org.mariadb.jdbc.MariaDbSta

Expected: For it to start up and make the tables

I did run docker exec -t -i containerid /bin/bash and connect successfully to the mariadb it is pointing too so it isn't a network issue.

@jtwebman Does the DB you connected to have any data in it? Are you able to write to those tables?

@Rucknar There is nothing in the database and I was able to create a table with that user.
MariaDB [rancher]> CREATE TABLE testing (id INT, data VARCHAR(100));
Query OK, 0 rows affected (0.02 sec)
MariaDB [rancher]> SHOW TABLES;
+-----------------------+
| Tables_in_rancher     |
+-----------------------+
| DATABASECHANGELOGLOCK |
| testing               |
+-----------------------+
2 rows in set (0.00 sec)

Ok I see the issue was something went wrong and the DATABASECHANGELOGLOCK got in a bad state. Once I dropped this table and restarted docker stable worked no issues. If anyone else runs into this issue make sure to clear the whole database of tables.

authors: Rucknar jtwebman


text:
Host label affinity scheduling rule is not functional.

Rancher server version - v1.2.0-pre4-rc1
Steps to reproduce the problem:
Add a label (hello1=value1) to one of the hosts.
Add a service with scheduling rule - "host must have a host label hello1=value1"
service is stuck in "activating" state for ever and has error -
(Failed to allocate instance [container:1i55]: Bad instance [container:1i55] in state [error]: Scheduling failed: needs host with label hello1: value1)
Host has labels set:
"labels": { "io.rancher.host.agent_image": "rancher/agent:v1.1.0-rc1", "io.rancher.host.docker_version": "1.12", "io.rancher.host.linux_kernel_version": "4.4", "hello1": "value1" },
On the service  following scehduling labels is set-
"labels": { "hello1": "value1", "io.rancher.scheduler.affinity:host_label": "hello1=value1" },

I'm also seeing this, but only when specifying more than one label.

I see this in pre4 and only with 1 label.

Didnt do an explicit code fix, but the tidal wave of changes over the last few days appear to  have fixed this on master.

@tfiduccia I'm assigning over to @sangeethah for verification but if you want to verify on master that your steps to repro are fixed too, go for it.

This issue still repros with latest master build.

We narrowed it down to only occurring when there is an active docker machine driver. It is caused by the logic we have to combine machine and host into a single resource. @ibuildthecloud will address. Assigning over.

Tested with latest build form master.
Host label affinity scheduling rule works as expected.

Same issue rancher v1.4.1. Seeing the below error. How can I troubleshoot this?
(Failed to allocate instance [container:1i97697]: Bad instance [container:1i97697] in state [error]: Allocation failed: needs host with label az: us-west-2a)

Docker compose has
      io.rancher.scheduler.affinity:host_label: az=us-west-2a

Rancher hosts shows

1j33     instance.internal    active    24           <IP ADDR>    az=us-west-2a,instance_id=i-ID,instance_type=r4.large,nginx_lb=true,traefik_lb=true

Not resolved in Rancher 1.6. The functionality doesn't work.

@stobias123 @bsidermob Can you check if you are hitting https://github.com/rancher/rancher/issues/10271. If not, please file a new issue with all information and a reproducible situation so we can take a look.

authors: Dids bsidermob cjellick sangeethah stobias123 superseb tfiduccia


text:
Editing  Lb and Editing/Deleting existing certs  does not result in the certs being deleted in haproxy config.

Rancher Versions: v1.5.1
Steps to reproduce the problem:
Scenario1:
Create LB with HTTS listener having "Default Cert" set to "cert1".
Able to reach LB using cert1.
Edit LB and set "Default Cert" set to "cert2".
Able to reach LB using cert2.
But cert1 continues to be present in /etc/haproxy/certs/current (along with cert2) and we are able to use cert1 to reach LB.
Expected Behavior:
cert1 should be removed from /etc/haproxy/certs/current
Scenario2:
Create LB with HTTS listener having "Default Cert" set to "cert1" and "Alternate Cert" set to "cert2".
Able to reach LB using cert1 and cert2.
Edit LB and  delete "cert2" from "Alternate Cert" list.
Able to reach LB using cert1.
Able to reach LB using cert2 as well.
In this case , cert2 continues to be present in /etc/haproxy/certs/current .
Expected Behavior:
cert2 should be removed from /etc/haproxy/certs/current
In both the above case , if any further changes are made to LB then the deleted/edited certs are reflected correctly in lb config. Not able to reach LB using the deleted certs.

Tested with prachidamle/lb-service-haproxy:v0.1. This issue is not reproducible anymore.


text:
Rancher Server errors out after being idle for a while

Rancher Versions:
Server: 1.5.3
healthcheck:
ipsec:
network-services:
scheduler:
kubernetes (if applicable):
Docker Version:
1.13.1-cs3
OS and where are the hosts located? (cloud, bare metal, etc):
Ubuntu 16.04.1, on my laptop running VMware workstation
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single node Rancher server, 2 hosts. Rancher server node serving as one host
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:
Setup Rancher server, add two hosts, start some services and containers, left it running for 19 hours
Results:
Rancher server went down. (Because this is a laptop-based setup, there was obviously intermittent
network connection issues. But host IPs never changed.) Exceptions in server log observed.
server.zip

Did the Rancher server IP change?

Please let us know in a comment if you can still reproduce the issue, and we'll reopen it

authors: ibuildthecloud loganhz sheng-liang


text:
[2.9] Symlink docker machine driver binaries

The docker machine drivers for linode and harvester are located in two directories: /opt/drivers/management-state/bin and /usr/share/rancher/ui/assets/. The changes replace the latter with a symlink to the former.
The impact of duplicating those binaries is twofold:

Increased container image size.
Double counting of CVE instances by CVE scanners.

After the changes it was confirmed that the files are still accessible via <rancher-url>/assets/<driver-name> and that CVE scanners are no longer double counting CVEs.

Note: I pinged internally some folks from Hostbusters to get a second review.

authors: macedogm pjbgf


text:
Add new image rancher/mirrored-longhornio-openshift-origin-oauth-proxy

Issue:

https://github.com/rancher/rancher/issues/44861
https://github.com/rancher/rancher/issues/44862
Problem

Add new image rancher/mirrored-longhornio-openshift-origin-oauth-proxy
Solution

Add new image rancher/mirrored-longhornio-openshift-origin-oauth-proxy
Testing

Longhorn QA will perform the test to install/install/update the Rancher chart
Engineering Testing
Manual Testing

Longhorn QA will perform the test to install/install/update the Rancher chart
Automated Testing

Test types added/modified:

None

If "None" - Reason:  I think no need to have automation test case

Summary:
QA Testing Considerations

Regressions Considerations

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

None

@HarrisonWAffel This PR is blocking our Longhorn Rancher chart release. Could you help to merge? I see that the CI is currently failing but not sure if it is related to this PR. Could you help?

@PhanLe1010 I've restarted the build and will monitor it to make sure it passes

Thank you @HarrisonWAffel

@PhanLe1010 Will this image only be used in 2.9, or will it also be used in other release lines? This change will need to be included in each release line that will utilize the new image - this PR can be back ported after its merged if that is the case

Thanks @HarrisonWAffel for the reminder. This image will also be used in Rancher 2.8 and 2.7.
Is there an automation bot that can do backport or we need to create backport PRs manually?

Unfortunately no, not at the moment. The easiest way I've found to do this is to cherry pick changes from 2.9 into 2.8, or 2.7. But if time is a limiting factor on your end manually raising now might be a better idea, I will approve them and make sure they pass CI

Unfortunately no, not at the moment. The easiest way I've found to do this is to cherry pick changes from 2.9 into 2.8, or 2.7. But if time is a limiting factor on your end manually raising now might be a better idea, I will approve them and make sure they pass CI

@HarrisonWAffel Backport PRs are created:

v2.7: https://github.com/rancher/rancher/pull/45125
v2.8: https://github.com/rancher/rancher/pull/45124

This PR still failed. Could you help? @HarrisonWAffel

@PhanLe1010 I've restarted it, seems to be a bit flakey today


text:
Autoscaling doesn't collect metric between different revisions correctly

Rio version: v0.2.0
Steps to reproduce:
rio run -p 8080/http --name demo monachus/rancher-demo:yellow
rio scale default/demo=1-5
rio stage --image=monachus/rancher-demo:pink default/demo:v1
rio weight --rollout-interval 2 default/demo:v1=25
rio promote --rollout-interval 2 default/demo:v1

Create two revisions, each one can be scaled from 1 to 5. Send traffic to v0. Promoting v1 revision. Traffic should all be sent from v0 to v1. Noticed that autoscaler doesn't collect the correct info and don't scale v1 correspondingly.

Appears to be a regression when refactoring knative/serving v0.6.1 and envoy metric scraper.

Fixed in v0.3.0-rc2

repo: rancher/rio


text:
First version of percent gauge

{{percent-gauge value=50 title="Pods" subtitle="210 of 440 used" ticks=ticks}}

Looks good, do you want to work on the cluster dashboard page?
3 gauges for cpu, memory, and pods (not storage, we don't have data):

Read from /v3-machines (filtered by clusterId)
requested on each machine is how much of that resource is "used", allocatable is the total allowed.  So if requested.cpu = 500m and allocatable.cpu = 940m, show 53%.
Add up all the requested and allocatables for each machine and divide to get the average for the cluster.  Separately save the smallest and largest percentage of any individual machine to show the tick marks.
While you're looping through machines, keep track of how many there are and how many are in active state for the next section.

On the right side, read from componentStatuses on the cluster and show 4 lines:

etcd (all componentStatuses with an id starting with etcd- have a condition of type=Healthy and status=True)
Controller (the componentStatus with id=controller-manager has healthy/true)
Scheduler (id="scheduler" ...)
Nodes (all the nodes you saw in the graph part are active)

At the bottom, if any of the conditions are not healthy, show a banner saying which thing is bad.  For nodes, show a banner for each node what is not active.

Sure. I will do it on Tuesday once I get a customer project done.

@vincent99 Do you mean /v3/clusters/${cluserId}/schemas/node ? There is an allocatable field in node schema. But there is no requested field there. So I am using some random value for the gauges.

/v3/machines entries should have allocable and requested:

@vincent99 done.

@vincent99 updated.

repo: rancher/ui


text:
Bump k8s to 1.31 for Wrangler

Related to issue #46832

Go with PR #475  instead

repo: rancher/wrangler


text:
short-lived parametrized command containers

Is there any support for containers which run parametrized commands?
Here's one of my use-cases: composer/composer
I need to mount it to a volume and then, from time to time, manually execute it with different parameters. I have an option to create several containers with different hardcoded commands. What I want, instead, is to be able to "pull" it and use in short-lived mode: docker run --rm …
In the ideal world, I would be able to pre-create several commands (bound to volume) based on this container for easy access in Rancher-ui

@ibuildthecloud is this something that could be done?

authors: deniseschannon indeyets

repo: rancherio/rancher


text:
Clicking "Cancel" or "X" in any form results in a bringing the user back to host page

Anytime you click Cancel or the "X" icon to close the form, you will always be brought back to the main host page, not the page you were originally at.
Steps:

Click on a container within a host to bring up the container view page.
Click on the edit button to bring up a form
Click "Cancel"
The UI will refresh to the main host page, not the container detail page.

Actually, this also happens after you save a form as well.

Fixed in #28 to go back to the previous route (if there was one) and released in v0.8.0 today

repo: rancherio/ui


text:
Add the "suggested password" back into log in page

Add back "suggested password" back into the first time login page.

date - 11/18
Verified fixed

repo: rancherlabs/dashboard


text:
Implement true heartbeat from the forked JVM

A "true" heartbeat would provide several answers to problems we're currently facing:

it's not known where the "deadlocked" JVM actually is (stack traces),
it's not known whether it's a resource (no cpu usage) or active (spinloop) deadlock, sending back the stack traces a few time could answer this (as well as maybe generic CPU load),
it's not known whether the forked process is still alive at all (should heartbeat messages stop arriving, we can try to terminate the forked process and end with a build error).

This should provide some help in diagnosing issues like GH-233 too, hopefully.

repo: randomizedtesting/randomizedtesting


text:
Server Crash on Storage Drawer Controller Break

Issue description:
When an external storage is connected to a Storage Drawers Drawer controller, and the draw controller block is broken a server crash occurs.
What happens:
Server Crashes
What you expected to happen:
Not having the server crash
Steps to reproduce:

Connect an external storage to a Storage Drawers drawer controller.
Break The Drawer Controller
...

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

Minecraft: 1.10.2
Forge: 12.18.3.2185
Refined Storage:  1.2.14

Does this issue occur on a server? [yes/no]
yes
If a (crash)log is relevant for this issue, link it here:
https://gist.github.com/aaronmallen/433b9ce71db185ee565fb23f3e7ef008

I have this same issue on my server running FTB Direwolf20 1.2.2 without anything being broken. In any case, is there any chance I could get a backport of the fix to the version running in that pack?

My fix was applied to the 1.10 branch, it's in the latest RS version published today.

@raoulvdberge The modpack I am using has version 1.2.14. I can't updated it because I don't have control over the clients mod versions. Is there any chance I could get backport of the fix to version 1.2.14 so my players can use drawers with Refined Storage until the modpack decides to update (which has been slow since the pack was published)?

This bug was fixed in version 1.2.15. If you don't update to 1.2.15, you can't get the fix.

Obviously, I cannot magically modify your 1.2.14 installation to get the bug fixed there. You have to update.

damn @raoulvdberge that was fast!

authors: aaronmallen john01dav raoulvdberge

repo: raoulvdberge/refinedstorage

license: mit


text:
Improve performance of Euclidean distance transform

This PR gives a further 2-4x speedup to the 2D and 3D distance transform functions by creating dedicated elementwise CUDA kernels for the pre- and post-processing steps. These include, for example, packing and upacking the 3D coordinates into a single integer. This resolves various "TODO" comments that were in the source, but I don't think we have an issue open for this.
Aside from the performance benefit there is also a substantial reduction in memory usage for the default case of return_distance=True, return_indices=False as in this case the explicit arrays of indices never need to be created.
Benchmarks
Implementation from release 22.08.01

shape
return dist.
return ind.
SciPy
ITK
cuCIM
accel. (CuPy vs SciPy)
accel. (CuPy vs ITK)

256, 256
False
True
0.00379
----
0.00081
4.66
----

256, 256
True
False
0.00428
0.00383
0.00102
4.21
3.76

256, 256
True
True
0.00429
----
0.00107
4.02
----

512, 512
False
True
0.01724
----
0.00091
18.97
----

512, 512
True
False
0.01866
0.00788
0.00104
17.94
7.58

512, 512
True
True
0.01876
----
0.00107
17.48
----

2048, 2048
False
True
0.35053
----
0.00256
137.03
----

2048, 2048
True
False
0.39468
0.08220
0.00288
137.02
28.54

2048, 2048
True
True
0.39356
----
0.00296
133.04
----

4096, 4096
False
True
1.57430
----
0.00736
213.85
----

4096, 4096
True
False
1.79513
0.54968
0.00858
209.34
64.10

4096, 4096
True
True
1.81570
----
0.00889
204.25
----

32, 32, 32
False
True
0.00319
----
0.00069
4.62
----

32, 32, 32
True
False
0.00356
0.00481
0.00096
3.71
5.01

32, 32, 32
True
True
0.00360
----
0.00103
3.49
----

128, 128, 128
False
True
0.27901
----
0.00131
213.20
----

128, 128, 128
True
False
0.31013
0.04504
0.00156
199.32
28.94

128, 128, 128
True
True
0.31289
----
0.00163
192.07
----

256, 256, 256
False
True
3.02435
----
0.00696
434.25
----

256, 256, 256
True
False
3.34077
0.33528
0.00855
390.57
39.20

256, 256, 256
True
True
3.32920
----
0.00915
363.89
----

384, 384, 384
False
True
10.68973
----
0.02284
468.07
----

384, 384, 384
True
False
11.73340
1.16172
0.02809
417.65
41.35

384, 384, 384
True
True
11.68002
----
0.03007
388.40
----

Proposed Implementation

shape
return dist.
return ind.
SciPy
ITK
cuCIM
accel. (CuPy vs SciPy)
accel. (CuPy vs ITK)

256, 256
False
True
0.00385
N/A
0.00021
18.49
N/A

256, 256
True
False
0.00433
0.00370
0.00021
20.84
17.83

256, 256
True
True
0.00436
N/A
0.00022
19.55
N/A

512, 512
False
True
0.01724
N/A
0.00030
58.44
N/A

512, 512
True
False
0.01893
0.00790
0.00029
66.42
27.73

512, 512
True
True
0.01867
N/A
0.00030
62.65
N/A

2048, 2048
False
True
0.33893
N/A
0.00154
220.25
N/A

2048, 2048
True
False
0.40912
0.08219
0.00154
266.11
53.46

2048, 2048
True
True
0.39056
N/A
0.00162
241.76
N/A

4096, 4096
False
True
1.58069
N/A
0.00418
377.92
N/A

4096, 4096
True
False
1.81860
0.55152
0.00418
435.36
132.03

4096, 4096
True
True
1.80671
N/A
0.00448
402.85
N/A

32, 32, 32
False
True
0.00319
N/A
0.00017
19.05
N/A

32, 32, 32
True
False
0.00359
0.00514
0.00011
33.25
47.68

32, 32, 32
True
True
0.00355
N/A
0.00019
18.37
N/A

128, 128, 128
False
True
0.27217
N/A
0.00059
458.70
N/A

128, 128, 128
True
False
0.31409
0.03384
0.00050
633.12
68.21

128, 128, 128
True
True
0.31207
N/A
0.00066
474.26
N/A

256, 256, 256
False
True
3.01718
N/A
0.00304
993.26
N/A

256, 256, 256
True
False
3.32660
0.28979
0.00235
1418.07
123.53

256, 256, 256
True
True
3.31874
N/A
0.00352
942.49
N/A

384, 384, 384
False
True
10.67328
N/A
0.01000
1067.34
N/A

384, 384, 384
True
False
11.69219
1.11274
0.00771
1517.46
144.42

384, 384, 384
True
True
11.76073
N/A
0.01161
1013.03
N/A

@gpucibot merge

repo: rapidsai/cucim


text:
Triage /thirdparty and /org folders

Do the folders /thirdparty and /org serve a purpose anymore? Or can we remove them from the repo?

This looks like dead code, but confirming with two others before removing

Confirmed by @kkraus14 and @dantegd this is dead code, will remove in merge

repo: rapidsai/pygdf


text:
Example find_node.rs panics for some reasons

I'm randomly poking around the example find_nodes.rs. It will produce a proper output of nodes found before throwing out some panic information.
the backtrace displayed is here in Ubuntu Pastebin(expires in a week). The program will panic arbitrary times(which means it probably won't panic) with pretty much the same backtrace.
Totally don't know what happened since I'm still a freshman.

Hi,
Thanks for the report. Are you running find_nodes directly with cargo run --example find_nodes or something else?
Based on the trace, a mutex is returning the WouldBlock Err, which means that something else has the Mutex. find_nodes and the other examples (and tests) all run in tokio's current_thread mode, which only uses a single thread. So it's not expected to see a WouldBlock from the mutex.
I need to revise the mutex (use lock() instead of try_lock()) before the code will be ready for multi-threading.
Copying the backtrace from Ubuntu pastebin in case it is needed after it expires:
thread 'tokio-runtime-worker' panicked at 'thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: "WouldBlock"', called `Result::unwrap()` on an `Err` value: "WouldBlock"/home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/rustydht-lib-3.0.0/src/dht/dht.rs', :/home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/rustydht-lib-3.0.0/src/dht/dht.rs780::78050:
50stack backtrace:

   0: rust_begin_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14
   2: core::result::unwrap_failed
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/result.rs:1616:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/result.rs:1298:23
   4: rustydht_lib::dht::dht::DHT::ping_internal::{{closure}}::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/rustydht-lib-3.0.0/src/dht/dht.rs:780:33
   5: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/future/mod.rs:80:19
   6: rustydht_lib::shutdown::ShutdownReceiver::spawn_with_shutdown::{{closure}}::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/macros/select.rs:505:49
   7: <tokio::future::poll_fn::PollFn<F> as core::future::future::Future>::poll
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/future/poll_fn.rs:38:9
   8: rustydht_lib::shutdown::ShutdownReceiver::spawn_with_shutdown::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/rustydht-lib-3.0.0/src/shutdown.rs:38:13
   9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/future/mod.rs:80:19
  10: <core::pin::Pin<P> as core::future::future::Future>::poll
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/future/future.rs:119:9
  11: tokio::runtime::task::core::CoreStage<T>::poll::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/core.rs:161:17
  12: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/loom/std/unsafe_cell.rs:14:9
  13: tokio::runtime::task::core::CoreStage<T>::poll
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/core.rs:151:13
  14: tokio::runtime::task::harness::poll_future::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/harness.rs:461:19
  15: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panic/unwind_safe.rs:271:9
  16: std::panicking::try::do_call
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:403:40
  17: __rust_try
  18: std::panicking::try
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:367:19
  19: std::panic::catch_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panic.rs:133:14
  20: tokio::runtime::task::harness::poll_future
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/harness.rs:449:18
  21: tokio::runtime::task::harness::Harness<T,S>::poll_inner
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/harness.rs:98:27
  22: tokio::runtime::task::harness::Harness<T,S>::poll
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/harness.rs:53:15
  23: tokio::runtime::task::raw::poll
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/raw.rs:113:5
  24: tokio::runtime::task::raw::RawTask::poll
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/raw.rs:70:18
  25: tokio::runtime::task::LocalNotified<S>::run
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/mod.rs:343:9
  26: tokio::runtime::thread_pool::worker::Context::run_task::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/thread_pool/worker.rs:420:13
  27: tokio::coop::with_budget::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/coop.rs:102:9
  28: std::thread::local::LocalKey<T>::try_with
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/thread/local.rs:399:16
  29: std::thread::local::LocalKey<T>::with
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/thread/local.rs:375:9
  30: tokio::coop::with_budget
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/coop.rs:95:5
  31: tokio::coop::budget
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/coop.rs:72:5
  32: tokio::runtime::thread_pool::worker::Context::run_task
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/thread_pool/worker.rs:419:9
  33: tokio::runtime::thread_pool::worker::Context::run
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/thread_pool/worker.rs:386:24
  34: tokio::runtime::thread_pool::worker::run::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/thread_pool/worker.rs:371:17
  35: tokio::macros::scoped_tls::ScopedKey<T>::set
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/macros/scoped_tls.rs:61:9
  36: tokio::runtime::thread_pool::worker::run
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/thread_pool/worker.rs:368:5
  37: tokio::runtime::thread_pool::worker::Launch::launch::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/thread_pool/worker.rs:347:45
  38: <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/blocking/task.rs:42:21
  39: tokio::runtime::task::core::CoreStage<T>::poll::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/core.rs:161:17
  40: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/loom/std/unsafe_cell.rs:14:9
  41: tokio::runtime::task::core::CoreStage<T>::poll
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/core.rs:151:13
  42: tokio::runtime::task::harness::poll_future::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/harness.rs:461:19
  43: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panic/unwind_safe.rs:271:9
  44: std::panicking::try::do_call
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:403:40
  45: __rust_try
  46: std::panicking::try
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:367:19
  47: std::panic::catch_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panic.rs:133:14
  48: tokio::runtime::task::harness::poll_future
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/harness.rs:449:18
  49: tokio::runtime::task::harness::Harness<T,S>::poll_inner
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/harness.rs:98:27
  50: tokio::runtime::task::harness::Harness<T,S>::poll
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/harness.rs:53:15
  51: tokio::runtime::task::raw::poll
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/raw.rs:113:5
  52: tokio::runtime::task::raw::RawTask::poll
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/raw.rs:70:18
  53: tokio::runtime::task::UnownedTask<S>::run
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/task/mod.rs:379:9
  54: tokio::runtime::blocking::pool::Inner::run
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/blocking/pool.rs:264:17
  55: tokio::runtime::blocking::pool::Spawner::spawn_thread::{{closure}}
             at /home/drhuang/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.15.0/src/runtime/blocking/pool.rs:244:17
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Give the multithread branch a try: https://github.com/raptorswing/rustydht-lib/tree/multithread

I copied the code into a main function of my own to test it's functionality. It's a pretty simple one just like this
#[tokio::main]
async fn main(){ /*code in the example, nothing else*/ }

So that's probably caused by multi-threading. I simply just don't want to clone the repo XD

Ok - that makes sense and I'm able to reproduce the issue.
If you don't want to clone the multithread branch to try that out, you can instead just change your tokio macro to #[tokio::main(flavor = "current_thread")] and it should work fine.

Uh, one more thing. Isn't it that there is only one task running? Who else want to get the lock? Or why it want to get the lock it already has?
Not quite understand the behavior here.

The code does use multiple tokio tasks. And tokio tasks must implement Send. So basically, even if using tokio's current_thread runtime, tasks have to be written such that they can run multithreaded. I didn't see an easy way to make it work without a mutex. I'd be happy to be proven wrong! Probably there's a way to do it with message passing. I'm still fairly new to Rust and tokio.
In any case the 3.0.1 version changes the locking code to behave with either tokio runtime.

authors: drHuangMHT raptorswing

repo: raptorswing/rustydht-lib

license: MIT


text:
Scraping different post

Hello everyone.
Using the script, pretty cool and easy to use, thanks.
I've been trying to scrap the media with the location data, and it works fine. But what if I want to scrap media+location from different posts? Like posting all the url in a txt file and scraping all the data from this file (one url post in every line) for example.
Using this line for a maximum of 5 from "anyuser"
instagram-scraper anyuser -u username -p password --media-metadata --include-location --maximum 5

Hey! Did you have any luck as to how to download the media? I am in a similar situation - was able to identify media accurately but I cannot figure out how to download.

No luck. I gave up

i have same problem.. any solution?

Hey @abinda - all media is automatically downloaded in your python installation. I forgot the exact path, but I can confirm it works.

authors: abinda botronico jefferycsauer

repo: rarcega/instagram-scraper

license: unlicense


text:
feat: swapped enumerable maps for normal maps

Changes

In the staking registry, we swapped out the enumerable maps for normal maps and eliminated the off chain aggregate functions to save on gas costs

resolved in https://github.com/rareprotocol/core/pull/27

repo: rareprotocol/core


text:
Inference

Hi, thank you for making the code available.
As I understand it your function "window_masking" randomly mask the patches for the training step. But how should I do when I want to infer an image? In the window_masking_ method I see that there are multi sparse_keep tensors should I use them?
Thanks!

Hi Geoffroy, Thanks for raising the issue. I have updated the inference folder with the file named evaluation_brats21 which contains the code to infer the model. Here you can see how I have used the window_masking_ method. I will try to document the code properly so that there will not be any confusion.
regards,
Rashmi


text:
Sealed secrets validation

Details
Describe the solution you'd like:
Sealed secrets must be encrypted with the appropriate public key and information to be decrypted in the cluster. These can cause issues when not valid or have been misconfigured, testing should be done to ensure these are not invalidated due to the before mentioned reasons.
To accomplish this there is a kubeseal --validate command that will --dry-run a decryption against the running sealed secret controller to ensure it is able to decrypt appropriately, if the resources is not valid it will prompt the following error output error: unable to decrypt sealed secret

It May not be actionable without a connection to the running cluster - this may need to be outside the bands of CI and instead be a script that is executed from the client-side.

Accomplished this by running github self-hosted runners in-cluster to be able to run validate anytime a file change occurs on a secret.