text:
fix: when all replicas of a deployment are on one node, restart the deployment instead of evicting it

Fixes   1674
Description
When all replicas of a Deployment are on the same node, for example, a deployment has 2 pods on this node, and the 2 pods are evicted when the node is terminated. From the time the 2 pods are evicted to the time the 2 pods are created and run successfully on the new node, the deployment has no pods to provide services.
This also happens when a Deployment has only one replica.
During Evicting, a judgment will be made here. If all replicas of the Deployment are on this node, or the Deployment has only one replica, restarting the Deployment is more elegant than evicting. This operation will first create a pod on the new node, wait for the new pod to run successfully, and then terminate the old pod, which will reduce service interruption time.
How was this change tested?

make presubmit

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

I like this idea

One of the drawbacks is:
This generates a lot of replicasets, and if you want to roll back the specific version by replicasets, you may not be able to do it.

Pull Request Test Coverage Report for Build 10958761744
Details

47 of 96 (48.96%)  changed or added relevant lines in 1 file are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.3%) to 80.468%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/controllers/node/termination/terminator/terminator.go
47
96
48.96%

Files with Coverage Reduction
New Missed Lines
%

pkg/controllers/disruption/consolidation.go
4
87.25%

Totals

Change from base Build 10931444492:
-0.3%

Covered Lines:
8466

Relevant Lines:
10521

💛  - Coveralls

/ok-to-test

I'm also wondering if this is better suited for a standardized upstream termination flow, rather than implementing this behavior on Karpenter. Effectively we'll be doing a lot more checks, and querying pods/deployments across the cluster for every pod we're terminating, but only doing something different in a smaller subset of cases, where all pods in the deployment live on the cluster. This is nice to let the deployment controller handle up rollouts, but i'm not sure if the juice is worth the squeeze here.
If you feel confident about the change here and the drawbacks, can you write up an RFC detailing the trade-offs so I can better understand?

This situation should be more common in non-production environments, such as test environments and pre-release environments, which are usually functional verifications. Most services are single-copy. If the service interruption time can be minimized when the node is terminated, the R&D experience will be better.
Currently, there seems to be no better way to solve this problem except restarting the deployment. If consider making it a feature and turning it off by default?
Our company is currently encountering this problem, and other companies should also encounter the same problem.
I will try to write an RFC, and we will discuss the advantages and disadvantages, as well as the feasibility.

I'm preparing a cluster for dev/staging and facing this same issue. We have deployments with replicas: 1 and if the only pod gets evicted = downtime for service. I am not an expert and maybe what I am about to say is dumb.
If Karpenter should not alter deployments/replicasets, maybe an alternative is to use pod-disruption-budget and have Karpenter just create an annotation on the node for that case: "I want to disrupt this node but I can't"
That would allow an external controller to do:

Taint the node
Find deployments responsible for the node pods
Restart such deployments

They would not be scheduled to the same node, if the new pods are Ready, the old ones get deleted, PDB is respected and Karpenter would be able to disrupt it the next check.
I guess that would have minimal changes for this project. It could be something implemented by the user from a manifest in karpenter documentation, referencing another github project.

authors: Cristobal-M andyblog coveralls jwcesign njtran yxxhero

repo: kubernetes-sigs/karpenter


text:
Links to API reference from Concept pages

What would you like to be cleaned:
Links to the API reference from the concept pages
Why is this needed:
Improve discoverability
Follow up to #1249

/kind documentation
/assign stuton

One link from "Installation" to the generated https://kueue.sigs.k8s.io/docs/reference/kueue-config.v1beta1/#Configuration can also be helpful.

source: gharchive/issue

authors: alculquicondor trasc

repo: kubernetes-sigs/kueue

license_type: permissive

license_source: github-api


text:
Ensure test cases are independent

In an effort to get a binary that "works", we wrote some tests where a test case depends on the state left by previous test cases.
This is problematic for debugging problems and it tends to lead to a lot of test changes when there is a behavior change or you want to insert a case in the middle of the existing ones.
Places that I'm aware of:

[ ] TestCacheCapacityOperations in https://github.com/kubernetes-sigs/kueue/blob/main/pkg/capacity/capacity_test.go
[ ] TestCacheWorkloadOperations in https://github.com/kubernetes-sigs/kueue/blob/main/pkg/capacity/capacity_test.go
[ ] Scheduler suite https://github.com/kubernetes-sigs/kueue/blob/main/test/integration/scheduler/scheduler_test.go

And there are similar situations in the following, but it's more like a single complex test case in each:

[ ] TestSnapshot in https://github.com/kubernetes-sigs/kueue/blob/main/pkg/capacity/snapshot_test.go
[ ] TestFIFOQueue in https://github.com/kubernetes-sigs/kueue/blob/main/pkg/queue/queue_test.go

/priority backlog

/help
/good-first-issue

Let me work on this issue!
/assign

Seems like TestCacheCapacityOperations does not exist anyomre?

Looks like the issue with TestCacheCapacityOperations (TestCacheClusterQueueOperations) was already resolved in https://github.com/kubernetes-sigs/kueue/pull/133 🙂

I found the problem with the scheduler integration tests was resolved in https://github.com/kubernetes-sigs/kueue/pull/90

/reopen
/assign

authors: ahg-g alculquicondor shuheiktgw tenzen-y


text:
Utilize jobframework setups

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
I utilized setup functions for the jobframeworks so that the platform developers can avoid to copy those functions to separate in-house controllers.
Which issue(s) this PR fixes:

Part-of #1601
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Expose utilization functions to setup jobframework reconcilers and webhooks

/lgtm
The remaining comment from me https://github.com/kubernetes-sigs/kueue/pull/1630/#discussion_r1462008437 isn't blocking.
/assign @alculquicondor

/hold
As the unit tests fail

/lgtm cancel

/assign @alculquicondor

/hold cancel
@alculquicondor I rebased this PR. Please take another look.

The above Ci error occurred due to a connection error with the go proxy server.

../../../pkg/mod/github.com/onsi/ginkgo/v2@v2.15.0/ginkgo/labels/labels_command.go:15:2: golang.org/x/tools@v0.16.1: read "https:/proxy.golang.org/@v/v0.16.1.zip": stream error: stream ID 23; INTERNAL_ERROR; received from peer
make: *** [Makefile:322: ginkgo] Error 1

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_kueue/1630/pull-kueue-test-e2e-main-1-29/1750246773613400064

@alculquicondor I addressed all comments. PTAL, thanks.

source: gharchive/pull-request

authors: mimowo tenzen-y


text:
VC: check two-way informer data before reconcile

Check two-way informer data before reconcile, if it is consistent, do nothing.
Or there is an enormous pressure to super master apiserver when starting syncer.

I will take it

/assign @zhuangqh

/close

authors: Fei-Guo zhuangqh

repo: kubernetes-sigs/multi-tenancy

license_source: bigquery


text:
[VC] replace GOBIN with GOPATH/bin

As user may not set $GOBIN, make manifests may fail. This PR replaces $GOBIN with $GOPATH/bin in the Makefile.

/lgtm
/approve


text:
SecurityProfilesOperatorDaemon stuck in creating state

What happened:
SPOD erroring while updating initial status and stuck in creating phase.
I0718 03:04:24.560946       1 spod_controller.go:244] spod-config "msg"="Adding an initial status to the SPOD Instance" "namespace"="security-profiles-operator" "profile"="spod" E0718 03:04:24.567048       1 controller.go:329]  "msg"="Reconciler error" "error"="updating spod initial status: SecurityProfilesOperatorDaemon.security-profiles-operator.x-k8s.io \"spod\" is invalid: status.conditions.message: Required value" "SecurityProfilesOperatorDaemon"={"name":"spod","namespace":"security-profiles-operator"} "controller"="spod-config" "controllerGroup"="security-profiles-operator.x-k8s.io" "controllerKind"="SecurityProfilesOperatorDaemon" "name"="spod" "namespace"="security-profiles-operator" "reconcileID"="de95986b-910f-4a68-b865-5d245c9e2847" I0718 03:04:24.560946       1 spod_controller.go:244] spod-config "msg"="Adding an initial status to the SPOD Instance" "namespace"="security-profiles-operator" "profile"="spod" E0718 03:04:24.567048       1 controller.go:329]  "msg"="Reconciler error" "error"="updating spod initial status: SecurityProfilesOperatorDaemon.security-profiles-operator.x-k8s.io \"spod\" is invalid: status.conditions.message: Required value" "SecurityProfilesOperatorDaemon"={"name":"spod","namespace":"security-profiles-operator"} "controller"="spod-config" "controllerGroup"="security-profiles-operator.x-k8s.io" "controllerKind"="SecurityProfilesOperatorDaemon" "name"="spod" "namespace"="security-profiles-operator" "reconcileID"="de95986b-910f-4a68-b865-5d245c9e2847"
What you expected to happen:
SPOD should be runningwithout errors and able to perform the seccomp profilebinding
How to reproduce it (as minimally and precisely as possible):

Install OLM:
kubectl create -f https://raw.githubusercontent.com/operator-framework/operator-lifecycle-manager/master/deploy/upstream/quickstart/crds.yaml
kubectl create -f https://raw.githubusercontent.com/operator-framework/operator-lifecycle-manager/master/deploy/upstream/quickstart/olm.yaml
Install SPO:
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/security-profiles-operator/main/examples/olm/operatorhub-io.yaml
Create a basic seccomprofile and profilebinding
apiVersion: security-profiles-operator.x-k8s.io/v1beta1 kind: SeccompProfile metadata: namespace: sec-squad name: profile1 spec: defaultAction: SCMP_ACT_LOG disabled: false

apiVersion: security-profiles-operator.x-k8s.io/v1alpha1 kind: ProfileBinding metadata:   name: test-binding spec:   profileRef:     kind: SeccompProfile     name: profile1   image: nginx-unprivileged:latest
Anything else we need to know?:
SPOD object configuration:
`apiVersion: v1
items:

apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
kind: SecurityProfilesOperatorDaemon
metadata:
creationTimestamp: "2023-07-18T02:42:45Z"
generation: 1
labels:
app: security-profiles-operator
name: spod
namespace: security-profiles-operator
resourceVersion: "17347962"
uid: f3da3117-c217-4a74-9e3d-c35be9286e5f
spec:
hostProcVolumePath: /proc
priorityClassName: system-node-critical
selinuxOptions:
allowedSystemProfiles:
- container
selinuxTypeTag: spc_t
staticWebhookConfig: false
tolerations:

effect: NoSchedule
key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
status:
conditions:
lastTransitionTime: "2023-07-18T02:42:48Z"
reason: Creating
status: "False"
type: Ready
state: CREATING
kind: List
metadata:
resourceVersion: ""`

Environment:

Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Others:
SPO version: 0.8.0
Kubernetes version: 1.23
k8s cluster type: azure and GKE

Hm, have you cert manager installed in your cluster?


text:
selinux: Fix selinuxd policy for RHEL-8/CentoOS-8/RHCOS

What type of PR is this?
/kind regression

What this PR does / why we need it:
While our update of selinuxd's policy worked fine (see CI), it broke
selinuxd's usage on OCP.
This patch brings back the needed changes for selinuxd to work fine
again on RHEL-8 based systems.
Which issue(s) this PR fixes:
Fixes #699

Does this PR have test?
No, but we should have CentOS-8 based tests in CI I guess.

Special notes for your reviewer:
@JAORMX what do you think about just updating the policy quickly for now and then having a separate Fedora-latest and Centos-8? For OCP4 we could select the Centos-8 based one as well as default to it, whoever is crazy/brave enough to deploy Fedora in their cluster would have to kustomize their deployment themselves.
Does this PR introduce a user-facing change?

NONE

Codecov Report

Merging #707 (ce74ef0) into main (e979472) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #707   +/-   ##
=======================================
  Coverage   39.36%   39.36%
=======================================
  Files          41       41
  Lines        3028     3028
=======================================
  Hits         1192     1192
  Misses       1783     1783
  Partials       53       53

Seems to me like these changes will break our fedora tests

huh, I thought this would have broken on Fedora. I guess the older policy is still applicable?

@jhrozek ah, seems you need to rebase

huh, I thought this would have broken on Fedora. I guess the older policy is still applicable?

This PR only adds to the Fedora policy, so far they are not mutually exclusive.

@jhrozek got it; that makes sense. Still gotta rebase though, your PR is missing the AppArmor bits of the rendered manifests.

On Mon, Nov 29, 2021 at 04:35:32AM -0800, Juan Osorio Robles wrote:

@jhrozek got it; that makes sense. Still gotta rebase though, your PR is missing the AppArmor bits of the rendered manifests.

Oops, done.

/test pull-security-profiles-operator-verify

/retest
/lgtm

authors: JAORMX codecov-commenter jhrozek


text:
Update API with some stubs that match the sketch

Update the API with some stubs to match the sketch.
Some cleanup related to testing the CRDs using kind and kubebuilder.
Minor updates to the documentation.

cc: @robscott

Rob -- looks like you need to be added to the org.

repo: kubernetes-sigs/service-apis


text:
master branch: make 2 failure - looping with crictl is required for container runtime: exec: "crictl": executable file not found in %PATH%

Cloning repo
# git clone https://github.com/kubernetes-sigs/sig-windows-dev-tools.git
Cloning into 'sig-windows-dev-tools'...
remote: Enumerating objects: 1264, done.
remote: Counting objects: 100% (597/597), done.
remote: Compressing objects: 100% (367/367), done.
remote: Total 1264 (delta 313), reused 418 (delta 197), pack-reused 667
Receiving objects: 100% (1264/1264), 90.41 MiB | 12.87 MiB/s, done.
Resolving deltas: 100% (650/650), done.
# cd sig-windows-dev-tools/

Cleaning environment
# vagrant destroy --force
cni:
antrea
==> winw1: VM not created. Moving on...
==> controlplane: VM not created. Moving on...

Using make 2
#~/sig-windows-dev-tools# make 2

*********** vagrant up first run done ~~~~ ENTERING WINDOWS BRINGUP LOOP ***
until `vagrant status | grep winw1 | grep -q "running"` ; do vagrant up winw1 || echo failed_win_up ; done
cni:
antrea
Bringing machine 'winw1' up with 'virtualbox' provider...
==> winw1: Importing base box 'FriedrichWilken/Windows_2019-sig-win-dev-tools'...
==> winw1: Matching MAC address for NAT networking...
==> winw1: Checking if box 'FriedrichWilken/Windows_2019-sig-win-dev-tools' version '1.04' is up to date...
==> winw1: Setting the name of the VM: sig-windows-dev-tools_winw1_1642178570697_50689
==> winw1: Fixed port collision for 3389 => 3389. Now on port 2208.
==> winw1: Fixed port collision for 5985 => 55985. Now on port 2209.
==> winw1: Fixed port collision for 5986 => 55986. Now on port 2210.
==> winw1: Fixed port collision for 22 => 2222. Now on port 2211.
==> winw1: Clearing any previously set network interfaces...
==> winw1: Preparing network interfaces based on configuration...
    winw1: Adapter 1: nat
    winw1: Adapter 2: hostonly
==> winw1: Forwarding ports...
    winw1: 3389 (guest) => 2208 (host) (adapter 1)
    winw1: 5985 (guest) => 2209 (host) (adapter 1)
    winw1: 5986 (guest) => 2210 (host) (adapter 1)
    winw1: 22 (guest) => 2211 (host) (adapter 1)
==> winw1: Running 'pre-boot' VM customizations...
==> winw1: Booting VM...
==> winw1: Waiting for machine to boot. This may take a few minutes...
    winw1: WinRM address: 127.0.0.1:2209
    winw1: WinRM username: vagrant
    winw1: WinRM execution_time_limit: PT2H
    winw1: WinRM transport: negotiate
==> winw1: Machine booted and ready!
==> winw1: Checking for guest additions in VM...
==> winw1: Setting hostname...
==> winw1: Waiting for machine to reboot...
==> winw1: Configuring and enabling network interfaces...
==> winw1: Mounting shared folders...
    winw1: C:/forked => /root/sig-windows-dev-tools/forked
    winw1: C:/sync/shared => /root/sig-windows-dev-tools/sync/shared
    winw1: C:/sync/windows => /root/sig-windows-dev-tools/sync/windows
==> winw1: Running provisioner: shell...
    winw1: Running: sync/shared/kubejoin.ps1 as C:\tmp\vagrant-shell.ps1
    winw1: [preflight] Running pre-flight checks
    winw1: [preflight] WARNING: Couldn't create the interface used for talking to the container runtime: crictl is required for container runtime: exec: "crictl": executable file not found in %PATH%
    winw1: error execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID "qirlpf"
    winw1: To see the stack trace of this error execute with --v=5 or higher

The error comes from winw1: error execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID "qirlpf", in fact there were multiple machines running with the same ip in the host, cleaning up and using only one work back.
/close
Slack thread:
https://kubernetes.slack.com/archives/C0SJ4AFB7/p1642269661023800

authors: dougsland knabben

repo: kubernetes-sigs/sig-windows-dev-tools


text:
Sync with k8s.io/kubernetes/staging

Sync with k8s.io/kubernetest at 17375fc59fff39135af63bd1750bb07c36ef873b, and k8s.io/apimachinery at d90aa2c8531f13b0ca734845934c10dcb6a56ca7
Updated the CHANGELOG accordingly. Please let me know if I missed any important changes.
Fix https://github.com/kubernetes/client-go/issues/123.
@deads2k @DirectXMan12 @sttts @lavalamp

This change is

Thanks

file list looks right.

@lavalamp our most of INSTALL.md instructs people using v2.0.0, so this pull doesn't affect INSTALL.md
I manually verified go get still works (though still has the known issues). I also manually verified if I pin to the latest commit of client-go in glide.yaml, glide up -v still works.

thank you!
On Fri, Feb 24, 2017 at 1:27 PM, Chao Xu notifications@github.com wrote:

@lavalamp https://github.com/lavalamp our most of INSTALL.md instructs
people using v2.0.0, so this pull doesn't affect INSTALL.md
I manually verified go get still works (though still has the known
issues). I also manually verified if I pin to the latest commit of
client-go in glide.yaml, glide up -v still works.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/pull/129#issuecomment-282409032,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglja5fqyXfTY3hUXigg_t7gGz2EJ5ks5rf0tHgaJpZM4MKeGM
.

repo: kubernetes/client-go


text:
README.md: fix broken links to examples in & out of cluster

Seems like this file isn't in the main Kubernetes repo, so here's a PR to fix its broken link.

This change is

FYI - just signed CLA.

Thanks @hblanks.

authors: caesarxuchao hblanks k8s-reviewable


text:
[rescheduler] Implemented main control loop

ref https://github.com/kubernetes/kubernetes/issues/29023
cc @davidopp @wojtek-t

Thanks @davidopp for the review. Addressed your comments.

LGTM
I would not suggest squashing the commits.

authors: davidopp piosz

repo: kubernetes/contrib


text:
Improve readability of client outputs

Currently our client outputs are just dumps of JSON responses from the service. We really want something much more beautiful for our users. For example, GCP Deployment Manager shows something like this for a deployment create:
$ gcloud deployment-manager deployments create d --config experimental/bmelville/ha-service/example.yaml
Waiting for create operation-1447888523552-524d8d11ee501-4c0b42a2-daf5e9dc...done.
Create operation operation-1447888523552-524d8d11ee501-4c0b42a2-daf5e9dc completed successfully.
NAME                         TYPE                             STATE      ERRORS
d-lb-fr                      compute.v1.forwardingRule        COMPLETED  -
d-lb-hc                      compute.v1.httpHealthCheck       COMPLETED  -
d-lb-tp                      compute.v1.targetPool            COMPLETED  -
d-service-us-central1-f-as   compute.v1.autoscaler            COMPLETED  -
d-service-us-central1-f-igm  compute.v1.instanceGroupManager  COMPLETED  -
d-service-us-central1-f-it   compute.v1.instanceTemplate      COMPLETED  -
It also shows errors appropriately.

+1. I was about to file an issue on dm deploy output being unusable.

Adding this issue to MVP as a fit and finish item. Most if not all of the commands have clean output, but someone needs to take a pass and make sure they look good.

authors: bmelville jackgr zmerlynn

repo: kubernetes/deployment-manager


text:
Add friendly message when fetch chart

None

Thanks for your submission @FengyunPan. I think adding more friendly output to the helm fetch command is great! If you have some time, I noted a few questions about the output I'd love to get your thoughts on before we merge. Thank you.

Because this is technically a feature, and because it could cause bugs with peoples scripts, I am moving this to 2.5.0.

@michelleN Can you take another look at this one?

Applied "Breaking" because it changes a method on the public API.

@FengyunPan Could you add an ExpandPath (or ExpandWithPath) function that returns (string, error) instead of changing the existing Expand function?
The public parts in chartutil are not supposed to change their signatures until Helm 3 so that users do not have to worry about backward compatibility breaks when they use this library. I think your solution is better than what is there, but we don't want existing applications to break. So our workaround has been to add new functions instead of changing existing ones.
Thank you for the PR.

@technosophos Thank for your review, that's right, I will update it soon.

This change is

authors: FengyunPan k8s-reviewable michelleN technosophos

repo: kubernetes/helm


text:
Ingress static IP

LoadBalancer have a loadBalancerIP field which is a must for any public website with a domain name. However Ingress just barely talks about LoadBalancer without stating how to have an Ingress behing a static IP. That's IMO critical knowledge.

Looking more into it, it seems that Ingress are directly exposed to the internet but there is no loadBalancerIP field in the spec. How are people supposed to use a DNS pointing to an Ingress if the IP cannot be made static and might change? It sounds really unsafe.

Sorry missed the prerequisits

@wernight hey, I am trying to figure out the same exact question you have. I want to use the features of an Ingress, however, If I can't tell it to use my static IP (like the loadBalancerIP field) what's the point?
What did you discover?

See my Kubernetes article as I describe there everything in. Basically you're probably mixing Ingress, Ingress Controller, and LoadBalancer. 3 different things.


text:
kubelet tls bootstrapping: fix role names

Fixes a mistake committed in https://github.com/kubernetes/kubernetes.github.io/pull/5660
cc @liggitt @luxas

This change is

/lgtm

authors: ericchiang liggitt


text:
Enable health-checker

How can I enable health-checker binary in my node-problem-detector? There is no mention of how to add it to the node-problem-detector.yaml file in the readme. Thank you.

/assign @wangzhen127

@wangzhen127 Can you please tell me how to use the health checker binary? This is what my exec command looks like now -
exec /node-problem-detector --v=99 --logtostderr --config.system-log-monitor=config/kernel-monitor.json,config/docker-monitor.json,config/docker-monitor-filelog.json,config/kernel-monitor-filelog.json,config/systemd-monitor.json --config.system-stats-monitor=config/system-stats-monitor.json --config.custom-plugin-monitor=config/custom-plugin-monitor.json,config/network-problem-monitor.json,config/kernel-monitor-counter.json,config/systemd-monitor-counter.json,config/docker-monitor-counter.json --port=20256 --prometheus-port=20257 >>/var/log/node-problem-detector.log 2>&1

Figured this out, I was trying with the wrong version. It needs 0.8.3 or newer.

repo: kubernetes/node-problem-detector


text:
Properly close channel when monitors exit.

This is a follow up of https://github.com/kubernetes/node-problem-detector/pull/339.
Will rebase after https://github.com/kubernetes/node-problem-detector/pull/339 is merged.
This PR:

Handles channel close for log counter, or else we may get nil log entry and cause a panic;
Handles channel close for kmsg parser, or else we may have another busy loop;
Handles channel close for custom plugin monitor, this is less an issue because the plugin will never close its channel, but let's add this for completion;
Closes channels returned to the problem detector, so that the goroutine in the problem detector can exit if the corresponding problem daemon exits.

1 and 2 are a more important bug fix that we may want to cherry-pick, 3 and 4 are not that important.
Signed-off-by: Lantao Liu lantaol@google.com

/lgtm
/hold

@wangzhen127 rebased.

/lgtm
/hold cancel


text:
Introduce flags for restart count checks

It is no longer used anywhere, so it should be safe (see
clusterloader2/docs/experiments.md). The list of containes was
formulated based on recent gce-5000 and kubemark-5000 test runs.

/ok-to-test
/lgtm
/approve

/lgtm
/approve

/ok-to-test

authors: mborsz mm4tt pierewoj

repo: kubernetes/perf-tests


text:
Localise toml configuration file in i18n to Hindi

This is a Feature Request
What would you like to be added
Creating https://github.com/kubernetes/website/tree/master/i18n/hi.toml
Why is this needed
Add Hindi language option.
Comments
Working on PR
This issue is closed by #14071

/language hi

/kind feature
/priority backlog

/remove-lifecycle stale

authors: avidLearnerInProgress sftim

repo: kubernetes/website


text:
Left menu doesn't work in firefox mobile

https://kubernetes.io/docs/home/
Both firefox are affected: fennec & fenix.
Pressing the left hamburger button just outlines it:

I think the longer-term work to switch to the Docsy theme might help fix that. Anyway:
/kind bug

Is it stalled?

Is it stalled?

Fixed - we're using Docsy now and there is no left menu.

/close


text:
netlify redirects: branch 1.13

This is a Bug Report
/kind bug
This PR is under the #19624 umbrella :open_umbrella:
This PR lists redirects found in the 1.13 branch.
Problem:
Netlify plans to update how they interpret redirect rules.
Netlify suggests the following entries may be affected by the new rules:
/api-ref/ ... https://github.com/kubernetes/kubernetes/milestones/ 301 ...
/concepts/containers/container-lifecycle-hooks/ ... /docs/concepts/containers/container-lifecycle-hooks/ 301 ...
/docs/ ... /docs/home/ 301 ...
/blog/2018/03/kubernetes-1.10-stabilizing-storage-security-networking/ ... /blog/2018/03/27/kubernetes-1.10-stabilizing-storage-security-networking/ 301 ...
/docs/admin/ ... /docs/concepts/cluster-administration/cluster-administration-overview/ 301 ...
/docs/admin/add-ons/ ... /docs/concepts/cluster-administration/addons/ 301 ...
/docs/admin/addons/ ... /docs/concepts/cluster-administration/addons/ 301 ...
/docs/admin/apparmor/ ... /docs/tutorials/clusters/apparmor/ 301 ...
/docs/admin/audit/ ... /docs/tasks/debug-application-cluster/audit/ 301 ...
/docs/admin/authorization/rbac.md ... /docs/admin/authorization/rbac/ 301 ...
/docs/admin/cluster-components/ ... /docs/concepts/overview/components/ 301 ...
/docs/admin/cluster-management/ ... /docs/tasks/administer-cluster/cluster-management/ 301 ...
/docs/admin/cluster-troubleshooting/ ... /docs/tasks/debug-application-cluster/debug-cluster/ 301 ...
/docs/admin/daemons/ ... /docs/concepts/workloads/controllers/daemonset/ 301 ...
/docs/admin/disruptions/ ... /docs/concepts/workloads/pods/disruptions/ 301 ...
/docs/admin/dns/ ... /docs/concepts/services-networking/dns-pod-service/ 301 ...
/docs/admin/etcd/ ... /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301 ...
/docs/admin/etcd_upgrade/ ... /docs/tasks/administer-cluster/configure-upgrade-etcd/ 301 ...
/docs/admin/extensible-admission-controllers.md ... /docs/admin/extensible-admission-controllers/ 301 ...
/docs/admin/federation/kubefed/ ... /docs/tasks/federation/set-up-cluster-federation-kubefed/ 301 ...
/docs/admin/federation/kubefed.md ... /docs/tasks/federation/set-up-cluster-federation-kubefed/ 301 ...
/docs/admin/garbage-collection/ ... /docs/concepts/cluster-administration/kubelet-garbage-collection/ 301 ...
/docs/admin/ha-master-gce/ ... /docs/tasks/administer-cluster/highly-available-master/ 301 ...
/docs/admin/ha-master-gce.md/ ... /docs/tasks/administer-cluster/highly-available-master/ 301 ...
/docs/admin/high-availability/ ... /docs/admin/high-availability/building/ 301 ...
/docs/admin/kubeadm-upgrade-1-7/ ... /docs/tasks/administer-cluster/upgrade-downgrade/kubeadm-upgrade-1-7/ 301 ...
/docs/admin/kubelet-authentication-authorization/ ... /docs/reference/command-line-tools-reference/kubelet-authentication-authorization/ 301 ...
/docs/admin/kubelet-tls-bootstrapping/ ... /docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/ 301 ...
/docs/admin/limitrange/ ... /docs/tasks/administer-cluster/cpu-memory-limit/ 301 ...
/docs/admin/limitrange/Limits/ ... /docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage/ 301 ...
/docs/admin/master-node-communication/ ... /docs/concepts/architecture/master-node-communication/ 301 ...
/docs/admin/multi-cluster/ ... /docs/concepts/cluster-administration/federation/ 301 ...
/docs/admin/multiple-schedulers/ ... /docs/tasks/administer-cluster/configure-multiple-schedulers/ 301 ...
/docs/admin/namespaces/ ... /docs/tasks/administer-cluster/namespaces/ 301 ...
/docs/admin/namespaces/walkthrough/ ... /docs/tasks/administer-cluster/namespaces-walkthrough/ 301 ...
/docs/admin/network-plugins/ ... /docs/concepts/cluster-administration/network-plugins/ 301 ...
/docs/admin/networking/ ... /docs/concepts/cluster-administration/networking/ 301 ...
/docs/admin/node/ ... /docs/concepts/architecture/nodes/ 301 ...
/docs/admin/node-allocatable/ ... /docs/tasks/administer-cluster/reserve-compute-resources/ 301 ...
/docs/admin/node-allocatable.md ... /docs/tasks/administer-cluster/reserve-compute-resources/ 301 ...
/docs/admin/node-conformance.md ... /docs/admin/node-conformance/ 301 ...
/docs/admin/node-problem/ ... /docs/tasks/debug-application-cluster/monitor-node-health/ 301 ...
/docs/admin/out-of-resource/ ... /docs/tasks/administer-cluster/out-of-resource/ 301 ...
/docs/admin/rescheduler/ ... /docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/ 301 ...
/docs/admin/resourcequota/limitstorageconsumption/ ... /docs/tasks/administer-cluster/limit-storage-consumption/ 301 ...
/docs/admin/resourcequota/walkthrough/ ... /docs/tasks/administer-cluster/quota-api-object/ 301 ...
/docs/admin/static-pods/ ... /docs/tasks/administer-cluster/static-pod/ 301 ...
/docs/admin/sysctls/ ... /docs/tasks/administer-cluster/sysctl-cluster/ 301 ...
/docs/admin/resource-quota/ ... /docs/concepts/policy/resource-quotas/ 301 ...
/docs/admin/upgrade-1-6/ ... /docs/tasks/administer-cluster/upgrade-downgrade/upgrade-1-6/ 301 ...
/docs/api/ ... /docs/concepts/overview/kubernetes-api/ 301 ...
Proposed Solution:
Review the entries in /static/_redirects and update based upon the Netlify recommendations:
https://community.netlify.com/t/changed-behavior-in-redirects/10084.
Page to Update:
/static/_redirects

/priority important-soon

/assign

Closing as 1.18 is released.
/close


text:
ja: Make docs/concepts/workloads/pods/pod-lifecycle.md follow v1.17 of the original text

This is a Feature Request

What would you like to be added
Update docs/concepts/workloads/pods/pod-lifecycle.md to follow v1.17 of the original (Englist) text.
Why is this needed
content/ja/docs/concepts/workloads/pods/pod-lifecycle.md is outdated.
Comments
/language ja
/good-first-issue
File to update
https://github.com/kubernetes/website/blob/dev-1.17-ja.2/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md
Original
https://github.com/kubernetes/website/blob/release-1.17/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
diff between translated and v1.17
https://gist.github.com/1744b9412ec32059cc669495fae4e178
Note
Currently, we use dev-1.17-ja.2 branch. Please open a PR targeting the branch.
ref
How To Contribute
翻訳スタイルガイド
If you have a question, feel free to ask us at slack.k8s.io #kubernetes-docs-ja channel.

/assign

/close

authors: hiyokotaisa oke-py


text:
Wrong Link for Exemptions.

Problem:
The link for Exemptions in Enforce Pod Security Standards by Configuring the Built-in Admission Controller is wrong and does not give any information about exemptions.  The link used for it is: https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#exemptions but there is no information or content of Exemptions in Enforce Pod Security Standards by Configuring the Built-in Admission Controller.  The actual information for Exemptions is here in the Pod Security Admission.
Proposed Solution:
We will have to use this link: https://kubernetes.io/docs/concepts/security/pod-security-admission/#exemptions for Exemptions instead of https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#exemptions.
Page to Update:
https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/

/sig security
/sig auth

If it seems good then I'm up for it.
/assign

Fixed it here: #29707


text:
审计

webhook的审计后端的认证如何实现呢？

/language zh
related page - https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/#webhook-backend

/kind support

https://kubernetes.io/zh-cn/docs/tasks/debug/debug-cluster/audit/#webhook-backend
/close

authors: Hypoxicfire mengjiao-liu tengqm utkarsh-singh1


text:
Install and Set Up kubectl on Windows

Kubectl is not working on windows
### Tasks

Page related to the issue: https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/

/language en
/sig docs

Hi @skchinna7, could you please provide some details on the problem you are facing?

Yeah sure when I run the application it's not installing or any window popup is not showing like it installing something like that

/retitle Advice on “Install and Set Up kubectl on Windows”
/kind support

GitHub is not the right place for support requests.
For further help, you could ask on Server Fault.
You can also post your question on the Kubernetes Slack or the Discuss Kubernetes forum.

Yes @thisisharrsh, you are right we can discuss in Slack channel for this!

@skchinna7 Please refer to this comment for raising a support issue. Broadly speaking, issues here are related to the content of the website, its technical accuracy, or any suggestions around improvement of the UX.
/close

It's still not working


text:
[zh] 更新 部分文档中语句语法问题

[zh] 更新 部分文档中语句语法问题

None of the revisions makes sense to me.
/close

authors: tengqm wettper


text:
Replace redirect links of labels-annotations-taints

/docs/reference/kubernetes-api/labels-annotations-taints/ is redirected to /docs/reference/labels-annotations-taints/.
This PR replaces redirect links of labels-annotations-taints with the direct links.

/approve

authors: YuikoTakada tengqm


text:
Remove the duplicate content from access-cluster.md

Ref: #27547
Removing the duplicate section from https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/
and adding the link to https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-services/ in place of that.

Hi @tengqm ,
PTAL.

/lgtm

Hi @sftim @bradtopol @daminisatya, could you please take a look.

@kbhawkey, applied the changes you have suggested,,please have a look

/lgtm
/approve

authors: jimangel tengqm vaibhav2107


text:
Branch sync main & dev-1.30

Regular bi-weekly sync of main and dev-1.30.

/approve

authors: celestehorgan drewhagen


text:
kubeadm: add note about a bug in the PublicKeysECDSA FG

The PublicKeysECDSA has been poorly tested and supported and apparently it had a bug where keys in kubeconfig files were using RSA even if the FG was true.
Add note about that in the FG section of the kubeadm init doc.

i don't think this should be in the dev-1.31 branch as it's not exactly adding new behavior?
/sig cluster-lifecycle
/kind bug
/cc @pacoxu @carlory
/assign @sftim

/hold
We avoid statements about the future and that includes most promises about future releases.
If we make an exception here, let's be clear about why.

/lgtm

authors: neolit123 pacoxu sftim


text:
fix: update cloud variables to pro

Pull request description
Update the name of the environment variables to PRO from CLOUD
Checklist (choose whats happened)

[ ] breaking change! (describe)
[ ] tested locally
[ ] tested on cluster
[ ] added new dependencies
[ ] updated the docs
[ ] added a test

Breaking changes

Changes

Fixes

Hey @vLia, can we merge this?

Yes @ypoplavs

authors: vLia ypoplavs

repo: kubeshop/helm-charts

license: MIT


text:
Can not proceed or break the pipeline created by others

Versions used
KubeSphere: v3.2.1-rc.2
How To Reproduce
Steps to reproduce the behavior:
1、Create pipeline use the following Jenkinsfile with account 'A'
pipeline {
    agent any
    stages {
        stage('Example') {
            input {
                message "Should we continue?"
                ok "Yes, we should."
                submitter "alice,bob"
                parameters {
                    string(name: 'PERSON', defaultValue: 'Mr Jenkins', description: 'Who should I say hello to?')
                }
            }
            steps {
                echo "Hello, ${PERSON}, nice to meet you."
            }
        }
    }
}

2、Run the pipeline created in step 1 with account 'admin'
3、Proceed or break the pipeline in 'Record details' page
Actual behavior
user admin can not  proceed or break the pipeline
https://user-images.githubusercontent.com/68640256/145140855-77c59d94-2787-44d4-abb8-f3d92cb2df6b.mov
/kind bug
/cc @kubesphere/sig-devops
/priority high

/assign
/milestone v3.2

@wenxin-01 , thank you for reaching out here! I've already reproduced this problem and am trying to figure out it.

repo: kubesphere/ks-devops


text:
[Feature] Support retries in workflow step

Is your feature request related to a problem? Please describe.

For a failed step, we can add retries to let the users control the max retry times like:
steps:
   - name: a
      retry:
         times: 5
         interval: 30s

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Has this problem been solved? If not and @fourierr doesn't have the time to do it, maybe I can take on this work.

Hi, @YTGhost
The issue is not solved yet, you can checkout the code here: https://github.com/kubevela/workflow

authors: FogDong YTGhost

repo: kubevela/kubevela


text:
Cannot install new version of vela with kubevela.net

When attempting to install KubeVela version 1.9.11 on a Kubernetes cluster running using the vela CLI tool, the installation process fails due to an issue with retrieving and loading the Helm chart. The specific error encountered indicates a problem with the Helm chart file's gzip header.
To Reproduce
Pull kubevela:
curl -fsSl https://kubevela.net/script/install.sh | bash'
Run the following command to install KubeVela:
sh
vela install --version 1.9.11
KubeVela Version
v1.9.11
Cluster information
1.24.0
Additional context
Installing KubeVela Core ...
Error: loadding the helm chart of kubeVela control plane failure, error retrieving Helm Chart at https://charts.kubevela.net/core/vela-core-1.9.11.tgz: gzip: invalid header

Can you help this? @barnettZQG

Kubevela.io is up now. Try again and see if it works

Working for me

Recovered.

authors: FogDong ealogar jmarchel7bulls kishorkn


text:
When I use kubevirt (v0.35.0) and kube-ovn together, virt-controller does not work properly. But the v0.32.0 version can work normally

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:
/kind bug

What happened:
goroutine 449 [running]:
kubevirt.io/kubevirt/vendor/k8s.io/apimachinery/pkg/util/runtime.logPanic(0x1ac9ac0, 0x32229f0)
vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:74 +0xa3
kubevirt.io/kubevirt/vendor/k8s.io/apimachinery/pkg/util/runtime.HandleCrash(0x0, 0x0, 0x0)
vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:48 +0x82
panic(0x1ac9ac0, 0x32229f0)
GOROOT/src/runtime/panic.go:679 +0x1b2
kubevirt.io/kubevirt/pkg/virt-controller/watch/snapshot.(*VMSnapshotController).getVolumeStorageClassForVolume(0xc001b4a5a0, 0xc001f533a9, 0x7, 0xc000963998, 0x0, 0x3, 0xc0009636d0, 0x2)
pkg/virt-controller/watch/snapshot/snapshot.go:686 +0x61a
kubevirt.io/kubevirt/pkg/virt-controller/watch/snapshot.(*VMSnapshotController).getVolumeSnapshotStatus(0xc001b4a5a0, 0xc0030ef040, 0xc000963998, 0x0, 0x0, 0x0, 0x0, 0x0)
pkg/virt-controller/watch/snapshot/snapshot.go:656 +0x81
kubevirt.io/kubevirt/pkg/virt-controller/watch/snapshot.(*VMSnapshotController).updateVolumeSnapshotStatuses(0xc001b4a5a0, 0xc002a6da00, 0x13, 0x1ce9ac0)
pkg/virt-controller/watch/snapshot/snapshot.go:640 +0x496
kubevirt.io/kubevirt/pkg/virt-controller/watch/snapshot.(*VMSnapshotController).processVMSnapshotStatusWorkItem.func1(0xc00333f980, 0x13, 0xf, 0x0, 0x2)
pkg/virt-controller/watch/snapshot/snapshot_base.go:302 +0x248
kubevirt.io/kubevirt/pkg/virt-controller/watch/snapshot.processWorkItem.func1(0x22a07c0, 0xc000924540, 0xc003379e18, 0x1a33380, 0xc003342ad0, 0x0, 0x0)
pkg/virt-controller/watch/snapshot/util.go:108 +0x274
kubevirt.io/kubevirt/pkg/virt-controller/watch/snapshot.processWorkItem(0x22a07c0, 0xc000924540, 0xc003379e18, 0x0)
pkg/virt-controller/watch/snapshot/util.go:122 +0x72
kubevirt.io/kubevirt/pkg/virt-controller/watch/snapshot.(*VMSnapshotController).processVMSnapshotStatusWorkItem(0xc001b4a5a0, 0xc0021b5920)
pkg/virt-controller/watch/snapshot/snapshot_base.go:288 +0x61
kubevirt.io/kubevirt/pkg/virt-controller/watch/snapshot.(*VMSnapshotController).vmSnapshotStatusWorker(0xc001b4a5a0)
pkg/virt-controller/watch/snapshot/snapshot_base.go:211 +0x2b
kubevirt.io/kubevirt/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1(0xc003342de0)
vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:152 +0x5e
kubevirt.io/kubevirt/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil(0xc003342de0, 0x3b9aca00, 0x0, 0x1, 0xc0029425a0)
vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:153 +0xf8
kubevirt.io/kubevirt/vendor/k8s.io/apimachinery/pkg/util/wait.Until(0xc003342de0, 0x3b9aca00, 0xc0029425a0)
vendor/k8s.io/apimachinery/pkg/util/wait/wait.go:88 +0x4d
created by kubevirt.io/kubevirt/pkg/virt-controller/watch/snapshot.(*VMSnapshotController).Run
pkg/virt-controller/watch/snapshot/snapshot_base.go:182 +0x8fa
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x18bfdaa]
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

KubeVirt version (use virtctl version):
Client Version: version.Info{GitVersion:"v0.35.0", GitCommit:"b77b858ac9345ae6858cf409e1833f4548ec2809", GitTreeState:"clean", BuildDate:"2020-11-09T13:38:36Z", GoVersion:"go1.13.14", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{GitVersion:"{gitVersion}", GitCommit:"{gitCommit}", GitTreeState:"{gitTreeState}", BuildDate:"{buildDate}", GoVersion:"go1.13.14", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes version (use kubectl version):
[root@k8s-node-2 ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:50:19Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", BuildDate:"2020-08-26T14:23:04Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

VM or VMI specifications:

Cloud provider or hardware configuration:

OS (e.g. from /etc/os-release):

Kernel (e.g. uname -a):
Linux k8s-node-1 4.18.0-193.19.1.el8_2.x86_64 #1 SMP Mon Sep 14 14:37:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Install tools:

Others:

@ikukaku looking at what you provide, I think that this has something to do with snapshotting. Either we have a bug in that new controller or the cluster is configured in a way which we did not expect. I don't think that it is related  to networking. @mhenriks would you mind having a look?
/assign @mhenriks

/kind bug

This should have been fixed with https://github.com/kubevirt/kubevirt/pull/4462.

@ikukaku it should be part of the latest developer builds. Would be greast if you could give it a try: https://kubevirt.io/user-guide/#/installation/installation?id=installing-the-daily-developer-builds.

authors: ikukaku rmohr tomob

repo: kubevirt/kubevirt


text:
[release-1.0] infra: Bump Go to 1.19.12

What this PR does / why we need it:
Bump go 1.19.12
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #10213
Special notes for your reviewer:
Release note:
NONE

@brianmcarey , this is the bump for release-1.0.
If you can create an image for this one as well, I'll appreciate it. Thanks!

@brianmcarey , this is the bump for release-1.0. If you can create an image for this one as well, I'll appreciate it. Thanks!

@EdDev here is the image built from release-1.0 with your changes: quay.io/kubevirt/builder:2308030851-9ae62631c

@EdDev here is the image built from release-1.0 with your changes: quay.io/kubevirt/builder:2308030851-9ae62631c

Thank you!
Updated.

/approve

authors: EdDev brianmcarey enp0s3


text:
tests: drop deprecated NewRandomVMWithEphemeralDisk

Drop the deprecated function NewRandomVMWithEphemeralDisk in favor of simple libvmi calls.
NONE

/sig code-quality

/approve

/hold
@dankenigsberg libvmi has just been moved so I think a couple of updates are required here before the lanes will pass.
https://github.com/kubevirt/kubevirt/commit/9c3a52d67c6782cd48ae0702df5493f5023a04cc

/hold
@dankenigsberg libvmi has just been moved so I think a couple of updates are required here before the lanes will pass.
9c3a52d

It should be good now.
/unhold

authors: EdDev brianmcarey dankenigsberg enp0s3


text:
Fix flaky test: pausing_test: Set timeout for console connection to 30 secs

What this PR does / why we need it:
Sets timeout for console connection to 30 secs, as it its frequently running into timeout:
https://storage.googleapis.com/kubevirt-prow/reports/flakefinder/kubevirt/kubevirt/flakefinder-2019-11-26-168h.html
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

/test pull-kubevirt-e2e-k8s-multus-1.13.3

/test pull-kubevirt-e2e-k8s-1.14.6
/test pull-kubevirt-e2e-k8s-1.15.1-ceph
/test pull-kubevirt-e2e-k8s-genie-1.11.1

/test continuous-integration/travis-ci/pr

@rmohr I think we can merge this one. Although travis seems to not have reported, the build has suceeded.

/lgtm

/approve

/retest

authors: dhiller rmohr vatsalparekh


text:
[virt-operator] load new certificates earlier

What this PR does / why we need it:
Instead of waiting for the mounted secret to propagate a certificate,
immediately take the secret from the secret store and load the
certificate as soon as it is available. This would be in general the
preferred method for all our components if we would want to allow
accessing secrets, which we don't. However virt-operator, as the only
component with access to secrets can just do that.
This resolves issues where virt-operator webhooks on KubeVirt resources
would deny mutations until the new certificate is available. The
file-based appraoch can take up to minutes, the watcher based approach
reflects changes almost immediately.
This improvement was not necessarry until #4599 but is necessary now.
Our CI system fails pretty often on that: https://search.ci.kubevirt.io/?search=kubevirt-validate-update&maxAge=48h&context=1&type=bug%2Bjunit&name=&maxMatches=5&maxBytes=20971520&groupBy=job
The experienced failures due to temporary blocked updates look like this:
Message: "failed calling webhook \"kubevirt-update-validator.kubevirt.io\": Post https://kubevirt-operator-webhook.kubevirt.svc:443/kubevirt-validate-update?timeout=30s: x509: certificate signed by unknown authority (possibly because of \"crypto/rsa: verification error\" while trying to verify candidate authority certificate \"kubevirt.io\")",

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #4649 and fixes #4698
Special notes for your reviewer:
Release note:
Fix an issue where it may not be able to update the KubeVirt CR after creation for up to minutes due to certificate propagation delays

/cc @ashleyschuett
/cc @davidvossel

/cc @ashleyschuett
/cc @davidvossel

Weirdly enough exactly when fixing the operator update test, it fails on another temporary issue:
    GET https://api.github.com/repos/kubevirt/kubevirt/releases?per_page=10000: 502 Server Error []

/retest

Weirdly enough exactly when fixing the operator update test, it fails on another temporary issue:
    GET https://api.github.com/repos/kubevirt/kubevirt/releases?per_page=10000: 502 Server Error []

/retest

@rmohr one question, although it takes some time for a mounted secret to project into the pod, I though that we have a overlap and certificates are rotated a little before deadline so they old one that still is mounted at pods are still valid, this is not the case for kubevirt ?

@rmohr one question, although it takes some time for a mounted secret to project into the pod, I though that we have a overlap and certificates are rotated a little before deadline so they old one that still is mounted at pods are still valid, this is not the case for kubevirt ?

@rmohr one question, although it takes some time for a mounted secret to project into the pod, I though that we have a overlap and certificates are rotated a little before deadline so they old one that still is mounted at pods are still valid, this is not the case for kubevirt ?

Yes, that is the case. But the test does the following:

uninstall kubevirt (deletes certificates too)
install the previous kubevirt release
update to the current release

With a new operator webhook (update on KubeVirt resources) which got added, during the fresh install step (2) we have now a period of time where the webhook is already registered but the certificates were not propagated by the kubelet. During that period it is was prior to this PR not possible to update the KubeVirt CR.

@rmohr one question, although it takes some time for a mounted secret to project into the pod, I though that we have a overlap and certificates are rotated a little before deadline so they old one that still is mounted at pods are still valid, this is not the case for kubevirt ?

Yes, that is the case. But the test does the following:

uninstall kubevirt (deletes certificates too)
install the previous kubevirt release
update to the current release

With a new operator webhook (update on KubeVirt resources) which got added, during the fresh install step (2) we have now a period of time where the webhook is already registered but the certificates were not propagated by the kubelet. During that period it is was prior to this PR not possible to update the KubeVirt CR.

@davidvossel our tests can still hang in a weird state when we have tags which do not yet have a release attached:
            "message": "Failed to pull image \"index.docker.io/kubevirt/virt-operator:v0.37.0\": rpc error: code = Unknown desc = Error response from daemon: manifest for kubevirt/virt-operator:v0.37.0 not found: manifest unknown: manifest unknown",

Ran into an image pull backoff due to this in https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/4838/pull-kubevirt-e2e-k8s-1.17/1351273079254290432.

@davidvossel our tests can still hang in a weird state when we have tags which do not yet have a release attached:
            "message": "Failed to pull image \"index.docker.io/kubevirt/virt-operator:v0.37.0\": rpc error: code = Unknown desc = Error response from daemon: manifest for kubevirt/virt-operator:v0.37.0 not found: manifest unknown: manifest unknown",

Ran into an image pull backoff due to this in https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/4838/pull-kubevirt-e2e-k8s-1.17/1351273079254290432.

This one https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/4838/pull-kubevirt-e2e-k8s-1.18/1351214071818489856 seems to have an issue with calico. For reference.

This one https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/4838/pull-kubevirt-e2e-k8s-1.18/1351214071818489856 seems to have an issue with calico. For reference.

/retest

/retest

@rmohr another solution would be to not mark operator ready until the kubelet is not propagating the keys, but I suppose reading directly from the secret is just remove the latency.

@rmohr another solution would be to not mark operator ready until the kubelet is not propagating the keys, but I suppose reading directly from the secret is just remove the latency.

@rmohr another solution would be to not mark operator's pod as ready until the kubelet does not propagate the tls cert/key, in case we se problems reading it directly from secret.

Yes that was back then my initial thought, however that pulled other issues in (can't remember right now, would have to check). Latency should be gone now yes.

@rmohr another solution would be to not mark operator's pod as ready until the kubelet does not propagate the tls cert/key, in case we se problems reading it directly from secret.

Yes that was back then my initial thought, however that pulled other issues in (can't remember right now, would have to check). Latency should be gone now yes.

/retest

/retest

Ready for review again. All failures currently happening are not related to the part this fixes and this error is gone now. Willl investigate the other issues in follow ups.

Ready for review again. All failures currently happening are not related to the part this fixes and this error is gone now. Willl investigate the other issues in follow ups.

is there any reason why we need to consider people who want to manage their own operator certs? will they still be able to do that using this method?

Some people use kubevirt still without the operator. Some code got merged which allows to provide custom certificates in these components, but there is nothing consistent yet which would allow in general with the operator to use custom certs.

is there any reason why we need to consider people who want to manage their own operator certs? will they still be able to do that using this method?

Some people use kubevirt still without the operator. Some code got merged which allows to provide custom certificates in these components, but there is nothing consistent yet which would allow in general with the operator to use custom certs.

/retest
fail on unrelated places: https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/4838/pull-kubevirt-e2e-k8s-1.17/1351832391307497473, keeping for reference and investigating anyway.

/retest
fail on unrelated places: https://prow.apps.ovirt.org/view/gcs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/4838/pull-kubevirt-e2e-k8s-1.17/1351832391307497473, keeping for reference and investigating anyway.

+1 from me for manual merge

+1 from me for manual merge

/cherrypick release-0.37

/cherrypick release-0.37

/cherrypick release-0.36

/cherrypick release-0.36

authors: davidvossel qinqon rmohr


text:
[WIP] Mark storage tests with owner:sig-storage

Signed-off-by: Bartosz Rybacki brybacki@redhat.com

What this PR does / why we need it:
Mark storage tests with owner:sig-storage. Next all storage tests can be run on a new - separate test lane.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
This PR is open in draft so we can together decide if the test selection is ok. The PR also needs another commit with changes in the test scripts in automation/ directory, before it's ready to merger.
Release note:

NONE

@mhenriks @awels What do you think about the ownership of the tests in kubevirt/tests/storage_test.go.
Is it storage or maybe more a compute/vm thing?

/lgtm
/approve

/cc @nunnatsa should I change something when this PR gets merged: https://github.com/kubevirt/kubevirt/pull/5222

/test pull-kubevirt-check-tests-for-flakes
error was ERROR: An error occurred during the fetch of repository 'fedora_sriov_lane':

/hold needs more info and probably coordination with #5222

/cc @nunnatsa should I change something when this PR gets merged: #5222

It will be easier to manage lanes from the project-infra repository and to merge PRs there, instead of developing in two repos. But this is not mandatory.

/hold cancel
we can merge this without waiting #5222, so we can already have the correct owners for tests and possibility to run in a new lane

/test pull-kubevirt-e2e-k8s-1.19-sig-storage

/test pull-kubevirt-e2e-k8s-1.19-sig-storage

/test pull-kubevirt-e2e-k8s-1.19-sig-storage

/test pull-kubevirt-e2e-k8s-1.19-sig-storage

/retest

/lgtm

/test pull-kubevirt-e2e-k8s-1.19

/test pull-kubevirt-e2e-k8s-1.18

Both pull-kubevirt-e2e-k8s-1.19 and pull-kubevirt-e2e-k8s-1.18 lanes failing with this message:
failed to get image info: failed to invoke qemu-img: exit status 2: 'fatal error: runtime: cannot allocate memory

/test pull-kubevirt-e2e-k8s-1.18

authors: brybacki mhenriks nunnatsa phoracek


text:
vm-cycle: use exponential backoff when pause due to IO error

What this PR does / why we need it:
Currently, once a VM is Paused due to IO error, the VM status is flipping between Paused and Running multiple times per second. This because the virt-handler tries to restart the VM, and if the IOError is not resolved, the latter will be paused again.
In order to limit the impact to the apiserver, when a domain IOError occurs, an increasingly exponential backoff will be applied before retrying to start the VM again.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2029391
Special notes for your reviewer:
Release note:

Use an increasingly exponential backoff before retrying to start the VM, when an I/O error occurs.

/test-all

/cc @xpivarc
/cc @jean-edouard
Can you have a look? Thanks

@lzang FYI.

Thinking out loud, should we implement this in virt-launcher?

I think that probably we should handle it in the virt-handler and avoid refusing things that come from the handler at launcher level.

What if there is another operation that can proceed(un-plug of the error disk) that could succeed but we back off in virt-hadnler?

This is an hard question. Generally speaking: we are not avoiding updates but just delaying, so eventually it will be unpaused again. Otherwise, the vmi can be unpaused manually. I am open to suggestions :) Thanks
@xpivarc

Thinking out loud, should we implement this in virt-launcher?

I think that probably we should handle it in the virt-handler and avoid refusing things that come from the handler at launcher level.

+1 on this as virt-handler should be the brain and is the one who sends the unpause command too.

What if there is another operation that can proceed(un-plug of the error disk) that could succeed but we back off in virt-hadnler?

This is an hard question. Generally speaking: we are not avoiding updates but just delaying, so eventually it will be unpaused again. Otherwise, the vmi can be unpaused manually. I am open to suggestions :) Thanks @xpivarc

When I tested this, the vmi cannot be unpaused manually as it is not manually paused at the first place, but user can stop the vm and do the update instead. We may potentially identify the hot unplug case and make an exception there too. Other changes when the vm is paused probably doesn't matter?

authors: fossedihelm lzang rmohr


text:
Revisit Policy status, policy mode status and conditions and refactor the policy subreconciler

Status
At the time of writing, the policy status is composed by [PolicyModeStatus](https://github.com/kubewarden/kubewarden-controller/blob/a331d8d2d4ccd26396935fd9333118c85185280a/api/policies/v1/policy.go#L31) and [PolicyStatusEnum](https://github.com/kubewarden/kubewarden-controller/blob/a331d8d2d4ccd26396935fd9333118c85185280a/api/policies/v1/policy.go#L11). Unfortunately this adds complexity in the reconciliation loop and it could be ambiguous for the user.
Instead, we could merge PolicyModeStatus with PolicyStatusEnum having two different final active states PolicyStatusActiveMonitor and PolicyStatusActiveProtect.
Condition
Also, we could revisit the PolicyConditionType. We could either remove them or refactor them to be more explicit. See: https://maelvls.dev/kubernetes-conditions/
Reconciler
The policy subreconciler reconciliation loop could be simplified using the new statuses/conditions.

we could remove the reconcilePolicy and refactor the setPolicyStatus methods, as the first could be part of the reconcile method and the second one does not set the policy status, but it changes the policy mode status instead. The status change is also spread in the reconcilePolicy and reconcile methods.
investigate why we need to store the reconcileErr and return it after the status update.

This is related to: #743, #616

Also we need to investigate this error
2024-07-19T15:03:43+02:00     ERROR   Reconciler error        {"controller": "policyserver", "controllerGroup": "policies.kubewarden.io", "controllerKind": "PolicyServer", "PolicyServer": {"name":"policy-server-u0y4ypm0"}, "namespace": "", "name": "policy-server-u0y4ypm0", "reconcileID": "44def5e9-383a-4e85-9ed3-770d384c7ac2", "error": "update policy server status error: Operation cannot be fulfilled on policyservers.policies.kubewarden.io \"policy-server-u0y4ypm0\": the object has been modified; please apply your changes to the latest version and try again"}
  sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
        /home/lain/.asdf/installs/golang/1.22.3/packages/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.4/pkg/internal/controller/controller.go:324
  sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
        /home/lain/.asdf/installs/golang/1.22.3/packages/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.4/pkg/internal/controller/controller.go:261
  sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
        /home/lain/.asdf/installs/golang/1.22.3/packages/pkg/mod/sigs.k8s.io/controller-runtime@v0.18.4/pkg/internal/controller/controller.go:222

which might be related.

repo: kubewarden/kubewarden-controller


text:
Make kwctl inspect pull policies if they are remote and not pulled yet

If kwctl inspect is executed against a remote policy: registry://, http:// or https://, the policy should be pulled if it is not in the store instead of erroring out that the policy does not exist.

Closing as discussed, behavior is similar to crictl inspecti.

repo: kubewarden/kwctl


text:
Incorrect CLI message when Manager is NOT running

What happened:
kk install kakfa --instance foo reports
Error: failed to resolve package CRDs for operator: kakfa: getting kakfa in index file: no operator found for: kakfa
which isn't true
What you expected to happen:
The manager isn't running and I'm sure the CLI had an error... but it isn't this one.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

Kubernetes version (use kubectl version):
Kudo version (use kubectl kudo version):  current
Operator:
operatorVersion:
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

hmmm... perhaps GCE is having an issue.   This may not be an issue...

repo: kudobuilder/kudo


text:
目次が欲しい

ｖ３の命令一覧は、ずっとスクロールしないと目的の項目に辿り着けないのが不便で、ｖ１の命令一覧のような、目次が欲しい所です。（#15 は、それで作ってみようとしていて気が付きました）
現在の「v3.1.18に対応」とゆう形でなら私にもすぐ作成出来そうなのですが、マニュアルに目次のページを追加してみてもよいでしょうか？
しかし、今後も命令が増えたり、プラグインが増えたりということを考えると、命令一覧と同時に目次も自動生成される方が良いのでは無いかと思ったりして。

ありがとうございます。
目次なんですが、PHPで自動で生成しているんです。
data/nako3commands.db
のSQLiteのDBを基に生成しています。
konawiki3のプラグインが以下です。
https://github.com/kujirahand/konawiki3/blob/master/kona3engine/plugins/nako3doc.inc.php
なお、script/cmd2db.nako3
これで、上記nako3commands.dbを生成しているのです。
それでも、全部なでしこ３で自動生成できると良いかもですね。
バージョンアップごとに、スクリプト実行すれば良いだけなので。
何か良い方法がありますか？

@snowdrops89 さん、ありがとうございます。
下記のプログラム、マニュアルページに埋め込んでも良いですか？？？
https://nadesi.com/v3/storage/id.php?453
https://nadesi.com/v3/storage/id.php?451

あっ、ありがとうございます！！
試しにちょっと作ってみただけなのですが、こんなので良かったでしょうか？
ちなみにデータの部分は、ｖ１で命令一覧のページをHTTPデータ取得して作っただけなので、プラグインが追加になったりした場合は作り直さねばならぬのですｗｗｗ

ちょっと修正をして、スマホとかでもいい感じに（？）見れるようにしてみました☆
このデータの部分だけでも、phpででも、命令一覧を生成するときに、ついでに生成できたらよきな感じなんですけれどね（素人考え）
項目へのリンク先がいるので、command.txtからじゃダメなんですよねー。

@snowdrops89 さん、ありがとうございます。
とりあえず、nako3storageの書き込みをそのままブログ部品として貼り付けてみました。
なんか、各種コマンド情報が得られるAPIを作ると、JSON形式でページリンクとか取り出せて楽しいかもですね。
考えてみます。

ありがとうございます！！
とってもべんりになりました♪♪♪


text:
Integrate with Travis-CI and added some unit-test

Added Jest dependency.
Added UserDataPersistance class unit-test.
Added build status badge in README.md
Added multiple env in babel.config.js

Look great!!

authors: suraneti totiz

repo: kulapio/libra-wallet-poc


text:
ts-jest fails to import .ts modules from outside project root

Issue

ts-jest throws an error whenever a test utilizes a module from outside the project root.
ReferenceError: Unknown plugin "transform-es2015-modules-commonjs" specified in "base" at 0, attempted toresolve relative to "/home/colin/localdev/ts-jest-error/common"

      at node_modules/babel-core/lib/transformation/file/options/option-manager.js:180:17
          at Array.map (<anonymous>)

Expected behavior

TS files should be correctly imported even from outside the project.

Link to a minimal repo that reproduces this issue

https://github.com/colinskow/ts-jest-transform-error
cd main && npm install && npm test

I was able to reproduce this issue but I'm not sure if this is a bug in ts-jest.
What's happening is that when ts-jest tries to process common/index.ts, it can't find the dependencies because the context for the execution is set to the common directory.
Here are a few quick workarounds:

Create a symlink to the main/node_modules directory in either a common parent directory or in the common directory
Install the dev dependencies in either a common parent directory or in the common directory

Is  this a viable option for you?

I would expect ts-jest to behave exactly as a project that is compiled with TSC and tests run on the JS version. The tests run fine when I run build and run JS.
Should the execution context not be the cwd the command is run from instead of the directory of each file?
In my case "common" is shared by several projects, and I prefer to use the node_modules of whatever project I am building at the time. I could use symlinks as a temporary workaround but it is not ideal.

I would expect ts-jest to behave exactly as a project that is compiled with TSC and tests run on the JS version

I would too. It's just that I'm not sure what's causing this. ts-jest doesn't do anything explicitly to modify the default tsc behavior.

The tests run fine when I build and run the generated JS.

It would be very helpful if you could have this version as a branch on the linked repo. Would that be possible?

In my case "common" is shared by several projects, and I prefer to use the node_modules of whatever project I am building at the time.

I understand this use case as I do it too! I just do it the reverse way - I create symlink to the common directory in each of my project that uses it.

I updated the repo on the same branch so you can run npm run build && npm test to test the ts and JavaScript build at the same time. JS passes, TS fails.
I did some research and figured out this is a known bug in Babel which has been fixed, but since it is a breaking change will be available in Babel 7. The choices are to upgrade to babel-core@7.0.0-beta.3 now or wait for the stable release.

Interestingly enough, babel 7 has built-in typescript support which might make ts-jest obsolete. Let's keep this open and see what happens.

By the way, is there a specific reason that ts-jest uses Babel instead of vanilla TSC? Or was that a decision made within Jest?

We use both. Babel is not used to transpile type-script but as a postprocessing step, to handle some import stuff and e.g. hoist "jest.mock" calls.

Hi: I also meet this issue today and finally find that set "allowSyntheticDefaultImports": false, solved it for me.

@lyy011lyy Works for me too.
I also had to set moduleDirectories in my jest config to something like this:
"moduleDirectories": [
	"node_modules",
	"main/node_modules"
],

@LogansUA I think your issue is not related to this. Problem is probably with importing from .d.ts files, because it works when you rename it to index.ts

@josduj Should I create new issue? Or maybe you can suggest some way to fix it?

@colinskow updating jest and ts-jest (nmp i jest ts-jest) in your minimal repo does fix the issue

@huafu npm i jest ts-jest

authors: GeeWee LogansUA colinskow huafu josduj kulshekhar lyy011lyy shinriyo

repo: kulshekhar/ts-jest


text:
script <called from

error
script <called from
......
public/config.js content
window.ampfAppConfig = {
oboServicePath: 'some path'
}
axios.ts
const axiosOBOInstance = axios.create({
46 |   // @ts-ignore
47 |   adapter: cacheAdapterEnhancer(axios.defaults.adapter, {
48 |     defaultCache,
49 |   }),
50 |   baseURL: appConfig.getRequired('oboServicePath'),
Error at appConfig.getRequired as  window.ampfAppConfig is undefined....

Jest doesn't load any of your HTML files. I think you'll need to rethink your testing setup, or at the very least provide a minimum reproducible repo.


text:
chore(docs): Move all the docs links to use env vars

This PR continues on from https://github.com/kumahq/kuma-gui/pull/466, which I pulled back not to include the commit here, so the initial commit messages may read a little strange unless you know the context.
This PR replaces all instances of static docs URLs with static env vars. Importantly, env vars are vars that never change without having to install a new version of Kuma, in which case you'll want to refresh your page.
I went a little further here than in the previous PR but not too far by splitting the useEnv utility/composable to use an Env service and then a very simple service container just to get us this far. The service container is likely to be switched out at some point to use something that can auto build our services for us. Important thing for me is how we use this thing, we can change how it works later.
Extra Notes:

I changed the default version here to use 1.7.0 instead of 0.0.0 to get less snapshot churn in this PR.
Added KUMA_CHAT_URL
I changed a few PRODUCT_NAMEs while I was here (just the ones I came across whilst making this change). Interestingly, depending on where you are in the code we seem to use different methods of getting this value. Sometimes we'd use @/constants (which is just referring to import.meta.env.VITE_NAMESPACE) and sometimes computing the value from tagline from the store, which as far as I understand is exactly the same thing. There are still some PRODUCT_NAME/tagline things in the codebase and probably a few other things that can now use useEnv/env but that can be for future PRs.
All docs links now have UTMs
This cleaned up some nulls in the snapshots (just thinking out loud, I wonder if theres an easy way to test for nulls in the snapshots, might make them a little more useful 🤔 )
Added some very minimal tests for semver and useEnv
I probably would like to change KUMA_NAME to KUMA_PRODUCT_NAME at some point, but not hugely important

@kleinfreund @lahabana is there anything else at the moment needed here for another review?

@johncowen I’ve completed my review for this PR as per https://github.com/kumahq/kuma-gui/pull/507#pullrequestreview-1219287192. Please resolve (or address where you see fit) the remaining open threads as I’m not sure whether you consider them handled. If you want I can do another pass of reviewing the functionality to be working. Let me know.

If you are happy that its working (putting the approach to one side), I just need an approval to merge

authors: johncowen kleinfreund

repo: kumahq/kuma-gui


text:
Fix the failed test of matmul

func @matmul() {
  %A = alloc() : memref<64x64xf32>
  %B = alloc() : memref<64x64xf32>
  %C = alloc() : memref<64x64xf32>

  affine.for %i = 0 to 64 {
    affine.for %j = 0 to 64 {
      affine.for %k = 0 to 64 {
        %0 = affine.load %A[%i, %k] : memref<64x64xf32>
        %1 = affine.load %B[%k, %j] : memref<64x64xf32>
        %2 = mulf %0, %1 : f32
        %3 = affine.load %C[%i, %j] : memref<64x64xf32>
        %4 = addf %2, %3 : f32
        affine.store %4, %C[%i, %j] : memref<64x64xf32>
      }
    }
  }

  return
}

Fixed by #30

repo: kumasento/polymer


text:
Add support for OpenStack Pike (5.0)

We currently have this solution working for Ocata (4.0), but need to support Pike (5.0)

Key changes:
add 5.0 to pip calls in initialize.yml
change to 5.0 container targets in debian-network.sh

repo: kumulustech/kolla-bash


text:
[Bug]: Preview 'Eye Button' is not showing up

Give a brief about the bug ✍
If I hover over any project tile, the eye button to preview the game does not appear instead the alternate text Eye appears.
Attaching the Screenshot of the same:

What is the expected behavior? 🤔
When hovering over the projects, the Preview button should appear in place of the alternate text!
Provide step by step information reproduce the bug 📄

Hover over any project tile.
The eye button to preview the game does not appear instead the text Eye appears.

Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @kartikjoshi267 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

repo: kunjgit/GameZone


text:
Simon_Game_Challenge[Enhancement]:

Do you want to have the enhancement of existing game ? 😀 Describe yourself..
It should be in only one page because the starting button is very small in it, so it is not visible.
Describe the solution you'd like
add  height : 100vh;
increase Start button size
Select program in which you are contributing
No response
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @Ancha2003 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

I would like to work on this issues.

/assign

i would like to work upon this issue..so can you please assign me because i had made this game already so i guess i would be best fit for solving this issue
Thank you @kunjgit

I would like to work on this issues.so please assign me.

Hey @Ancha2003 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


text:
PR Description 📜
New Game: Helicopter Game added
Fixes #4454

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[ ] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @sau-mili ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

@ishita-43 please check..

Thank you  @sau-mili , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀

authors: kunjgit sau-mili


text:
add the typing-test game

PR Description 📜
Please include summary related to the issue you have fixed and describe your PR in brief over here by specifying the issue number on which you were working below
Fixes # 4914
I added the new game named Typing_Test which tests the speed of the person by giving random paragraph and timer set to 60sec and it tell the wpm and cpm and also mistakes

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @sanayamahajan-23 ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Please resolve merge conflicts

Resolved the conflicts @ishita-43

Resync your readme.md file with the latest changes and then add your game entry in there

resynced the readme.md and added entry @ishita-43

@kunjgit please merge the pr my score is at stake since only two days are left until gssoc ends

Thank you  @sanayamahajan-23 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


text:
fix: on.push.tags is not being triggered

I will push some test tags to debug the issue.

Great, it worked! :)

To avoid confusion, I deleted the Actions logs and tags used for debugging.

repo: kurosakishigure/katharsis


text:
Add tags in crates.to

Please add tags to crates.io so that people can find this awesome crate.
Below are useful tags.
[#sqlite][#postgres ][#orm ][#async ][#mysql]

Thank you for the kind words. Updated in ddb57ac.

repo: kurtbuilds/ormlite


text:
feat: added wait to run_sh task.

Description:

Is this change user facing?
YES/NO

References (if applicable):

Also fixed the wait for exec recipe ( this is an example with ready conditions)
Sample Code:
recipe = ExecRecipe(
        command = ["sh", "-c", "sleep 50s"]
    )
    old_pattern = plan.add_service(
        name = "old-pattern",
        config = ServiceConfig(
            image = "ethpandaops/ethereum-genesis-generator:1.0.14",
            entrypoint = ["tail", "-f", "/dev/null"],
            ready_conditions=ReadyCondition(recipe=recipe, field="code", assertion="==", target_value="0", timeout="25s")
        )
    )

Output:

repo: kurtosis-tech/kurtosis


text:
Area fixup

Functional changes:

onMouseUp works correctly now
onMouseDown now has access to the click count (e.g. for double clicks)
the modifier and extKey parameters of the key events get translated from a number into string(s)
missing cast in transform=scale

Otherwise:

using enums instead of magic numbers
calling free methods

Nice work. Thanks!


text:
Add "after-comment" to "at-rule-empty-line-before" ignore list?

https://stylelint.io/user-guide/rules/at-rule-empty-line-before/#after-comment

Thanks! It makes sense. I added this in v2.1.0.

authors: kutsan wimhendrikx

repo: kutsan/stylelint-config-clean-order


text:
recognition of other types of pictures.   распознавание других видов картинок.

Hello!
Tell me please, is it planned to introduce in addition additional functions rucaptcha?
such as?
Detailed information here:
https://rucaptcha.com/api-rucaptcha#solving_clickcaptcha
It describes other types of pictures!
Do you plan to introduce them for recognition in the appendix?
Thanks in advance for the answer!
Здравствуйте!
скажите пожалуйста,планируется ли ввести в дополнение дополнительные функции rucaptcha?
такие как?
подробная информация сдесь:
https://rucaptcha.com/api-rucaptcha#solving_clickcaptcha
Там описаны другие виды картинок!
Планируети ли вы их ввести для распознавания в дополнении?
Заранее спасибо за ответ!

Нет, в ближайшее время добавление поддержки других видов капч не планируется.

license: mit


text:
Added 'multiple' options

I added an option to annotation only one object in an image.

@arudenko Thanks!

authors: arudenko kyamagu

repo: kyamagu/bbox-annotator


text:
Support for Python 3.11

Just wanted to follow up on this, it would be helpful if you could provide some clarification on this matter
@kylebgorman

The dockerfile setup we have now doesn't seem to pull in Python 3.11 so that may be some additional work in the future.

Just wanted to clarify on this point.
When I was trying to generate wheel files using the Dockerfile, I was able to get Python 3.11 pulled (cp311) and the above message that I shared earlier in #64 stating that it's working fine in Python 3.11 also was by making use of this wheel file.

Originally posted by @gayu-thri in https://github.com/kylebgorman/pynini/issues/64#issuecomment-1491418129

I don’t think I saw Python 3.11 wheels on my system but it’s possible I missed something. Is it likely we got different outputs from the same dockerfile?
…
On Wed, Apr 5, 2023 at 1:34 AM Gayathri Ethiraj @.> wrote: Just wanted to follow up on this, it would be helpful if you could provide me with clarification on this matter @kylebgorman https://github.com/kylebgorman The dockerfile setup we have now doesn't seem to pull in Python 3.11 so that may be some additional work in the future. Just wanted to clarify on this point. When I was trying to generate wheel files using the Dockerfile, I was able to get Python 3.11 pulled (cp311) and the above message that I shared earlier stating that it's working fine in Python 3.11 also was by making use of this wheel file. [image: image] https://user-images.githubusercontent.com/39553592/229047449-674b7603-1d90-4757-8a8a-23622c850f9e.png — Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABG4OOKO7QZUBO7T5LNPLLW7UOCBANCNFSM6AAAAAAUSU45UQ . You are receiving this because you were mentioned.Message ID: @.>

I also just tried pulling the current version of Dockerfile (with some minor changes you've introduced) and generate the wheels again to confirm this, I am still able to get Python 3.11 cp wheel files generated.

Link for the generated wheel file for Python 3.11 here
https://drive.google.com/file/d/1TmIhuKOfSpXQ5euNsBB3tGV8XUHDa_9V/view?usp=share_link

Okay, fine, uploaded, thanks for that. In the future though I don't know if I will do this sort of thing again: that is, if when I make a Pynini release the highest Python version is 3.X, I won't be adding 3.$(X + 1) support after the fact unless there is a very long lag between Pynini releases.

It works now on Python 3.11. Thank you for the taking the time to address the issues.

In the future though I don't know if I will do this sort of thing again: that is, if when I make a Pynini release the highest Python version is 3.X, I won't be adding 3.$(X + 1) support after the fact unless there is a very long lag between Pynini releases.

Yes, I understand.

authors: gayu-thri kylebgorman

repo: kylebgorman/pynini


text:
dependency on wasmtime-go makes alpine containers fail to build

Version
1.15.0
What happened?
I just updated my code to use sqlc 1.15.0, and now my docker containers won't build.  The root issue seems to be https://github.com/bytecodealliance/wasmtime-go/issues/21.
I was surprised by this, and I thought others might bump into it as well.  I can migrate off of Alpine but others might not be so lucky.
Relevant log output
go install github.com/kyleconroy/sqlc/cmd/sqlc
go: downloading github.com/kyleconroy/sqlc v1.15.0
go: downloading github.com/bytecodealliance/wasmtime-go v0.39.0
go: downloading github.com/jinzhu/inflection v1.0.0
go: downloading github.com/pingcap/tidb/parser v0.0.0-20220725134311-c80026e61f00
go: downloading github.com/pganalyze/pg_query_go/v2 v2.1.2
go: downloading github.com/antlr/antlr4/runtime/Go/antlr v0.0.0-20220626175859-9abda183db8e
go: downloading github.com/pingcap/errors v0.11.5-0.20210425183316-da1aaba5fb63
go: downloading github.com/cznic/mathutil v0.0.0-20181122101859-297441e03548
go: downloading github.com/pingcap/log v0.0.0-20210906054005-afc726e70354
go: downloading gopkg.in/natefinch/lumberjack.v2 v2.0.0
go: downloading github.com/remyoudompheng/bigfft v0.0.0-20200410134404-eec4a21b6bb0
go: downloading github.com/benbjohnson/clock v1.1.0
# github.com/bytecodealliance/wasmtime-go
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: .tools/pkg/mod/github.com/bytecodealliance/wasmtime-go@v0.39.0/build/linux-x86_64/libwasmtime.a(std-69edc9ac8de4d39c.std.2a45fe64-cgu.0.rcgu.o): in function `std::sys::unix::os::glibc_version':
/rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/std/src/sys/unix/os.rs:659: undefined reference to `gnu_get_libc_version'
/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: .tools/pkg/mod/github.com/bytecodealliance/wasmtime-go@v0.39.0/build/linux-x86_64/libwasmtime.a(std-69edc9ac8de4d39c.std.2a45fe64-cgu.0.rcgu.o): in function `std::sys::unix::net::on_resolver_failure':
/rustc/e092d0b6b43f2de967af0887873151bb1c0b18d3/library/std/src/sys/unix/net.rs:522: undefined reference to `__res_init'
collect2: error: ld returned 1 exit status

Database schema
No response
SQL queries
No response
Configuration
No response
Playground URL
No response
What operating system are you using?
Linux
What database engines are you using?
PostgreSQL
What type of code are you generating?
Go

Oh crud.  I discovered just a minute ago that this was covered in https://github.com/kyleconroy/sqlc/issues/753
The solution, if you are here, is to add -tags=nowasm to your go install invocation.

repo: kyleconroy/sqlc


text:
Option to show only beacons within a certain distance

Not sure how this would combine with other visibility settings

I was thinking of adding this, I'll have to explore some ideas here

For now just to get this in place, I may need to do the following:

User clicks on max beacon distance setting
Switches to a new screen where they can enter the distance + select the unit that they are providing the distance in (respects distance unit settings)
Clicks done, brings them back to the setting list

I know that breaks the user experience of the settings page, but it is difficult to deal with different units in the settings screen - I'll eventually revisit and create a custom dialog where they can set all this stuff.


text:
Recommended debugging techniques

I was wondering how you approach debugging Curassow (with lldb), since it forks off worker processes at the beginning and lldb doesn't support automatic following of forks.
I found a very tedious way:

run your server in terminal window 1
in another window launch lldb for your binary
run attach WORKER_PID, which is visible when the server starts
continue as usual in the lldb instance, allowing to inspect the incoming requests in the debugger

This will obviously get untenable as a codebase grows, so I'm wondering what your thoughts on this are.

I try to limit debugging via Curassow, I'd usually try and write a test that has the same behaviour and attach lldb to the test runner.
As for problems in your application, you can just hit the Nest callback directly, I was planning to write some convenience testing functions to make that easier.

If you could just add two lines on how one can do that in the readme I'd consider that enough for what I was going for here :)

You can use make run-tests to build the test runner, which can be run with ./run-tests. So to attach that to lldb:
$ make run-tests
$ lldb ./run-tests
(lldb) r
Process 50884 launched: './run-tests' (x86_64)
-> HTTPParser
  -> can parse a HTTP request body
  -> reads the message body when Content-Length is present
  -> throws an error when the client uses bad HTTP syntax
  -> throws an error when the client uses a bad HTTP version
  -> throws an error when the client disconnects before sending an HTTP request
  -> throws an error when the client disconnects before sending the entire message body

6 passes and 0 failures
Process 50884 exited with status = 0 (0x00000000)

Yeah that's pretty much what I'm doing, thanks!

Are you trying to debug an issue with Curassow specifically or your application? If there is a bug with Curassow please open an issue and I can take a look. If it's with your application, I'd suggest removing Curassow from the mix completely and testing your application directly [example].

No bug in Currasow, I was just debugging my server running on it. Ok thanks

repo: kylef/Curassow


text:
Add widget that display joined array entries

Description
Changes proposed in this pull request:

Add widget that display joined array entries

Related issue(s)

I'd also suggest including a more meaningful example screenshot - with actual words instead of single letters.

/retest

/retest

authors: akucharska qbalukom

repo: kyma-project/busola


text:
Update Go Version

Description
Fixes CVE-2022-27664

/retest

repo: kyma-project/hydroform


text:
Release 1.9 version bump

Description
Changes proposed in this pull request:

Release 1.9.0

Pre-Merge Checklist

[ ] As a PR reviewer, verify code coverage and evaluate if it is acceptable.

Related issues

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant mluk-sap

repo: kyma-project/istio


text:
Disable Duplicated Tests

Description
It looks like tag database_integration from test_with_database_network make target is not used anywhere, which results in duplicated invocation of tests that are also invoked in previous targets.
Changes proposed in this pull request:

Remove unnecessary tests invocation.

Related issue(s)

Useless PR...

repo: kyma-project/kyma-environment-broker


text:
Revert "Remove UseSmallerMachineTypes feature flag (#882)"

This reverts commit 53acbd73d6d9768bb3263e37a578f7b1b03ecdbc.

Description
We need to postpone the removal.
Changes proposed in this pull request:
Related issue(s)

/kind enhancement


text:
🛑 senoshaidodelasmanos.love is down

In 87b99e8, senoshaidodelasmanos.love (https://senoshaidodelasmanos.love) was down:

HTTP code: 0
Response time: 0 ms

Resolved: senoshaidodelasmanos.love is back up in 5ccc793 after 1 hour, 33 minutes.

repo: kyryl-bogach/upptime