text:
Add backoff to watcher reconnection

Currently watcher will always keep a reconnection attempt in-flight when polled (and there is no active connection already). That's a bit excessive, and pretty unkind to the apiserver.
This isn't too bad for watcher itself since you can add a delay on the consumer side instead, but we should at least add something for Controller...

https://canary.discord.com/channels/500028886025895936/685161813675212899/861276713295675424

Pasting comments here for people off discord:

pavelp: Out of pure curiosity, I noticed kube calls K8S API with high frequency when it's not available (e.g. local cluster down). Is this the usual frequency excercised by kuibe-rs to call REST API watches ? Is there any recommended ? I was fiddling with K8S API this weekend and did some throttling  - I only ask twice a second maximum.
https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes

teozkr: that said.. there are still some missing pieces (for example: exponential backoff, backoff for kube watchers, and so on)

Do we think the solution here is to try to bake an exponential backoff watcher or the the step_trampolined (inner state machinery of watcher) fn?
(btw one way I have gotten around on this in the controller-rs example is to try to get the CRD first before trying to watch it - as that causes the same error - but that only works for controllers who forgot to add the CRD)

I think it would make sense to just have watcher (and applier/Controller in turn) take an arbitrary Backoff from the user.

If that's the case then I think we should consider creating builders for watcher to pass it in (#276), it's already a bit strange to have to disambiguate the import paths runtime::watcher (module) vs runtime::watcher() (fn) or runtime::watcher::watcher (fn)

rewording a bit; the watcher import problem is a separate issue, could be fixed by renaming the watcher module to watch,
I do still think there's room for a Watcher<K>, there are a couple of other naming problems here that i would like to improve separately (module name + flatten helpers/naming (maybe something akin to #296)). I'll open an issue separately.

To be honest, I don't really see the problem with the import, Rust has been smart enough to do the right thing in all the cases I've tried.

Rustdoc needs explicit disambiguation when linking to either module or the fn.
And although that's more of a problem for us, people still have to do a double-take here on the name being re-used in imports:
Generally i just think we should organise it in the way that is less confusing:
-use runtime::reflector, reflector::Store};
+use runtime::cache::{reflector, Store};

That makes sense to me.

Coming back to this after thinking more about it in https://github.com/kube-rs/kube-rs/pull/698
If we put a backoff into watcher, propagated it into step and slowed down progression on errors, then this would fix this particular issue (being kind to the api server when it's having trouble), but there are other issues that are hard errors here which cannot be fixed by retrying:
if RBAC is wrong, then no amount of retrying should occur - we need to bubble this up from the watcher.
I can't think of any other non-ephemeral issues that can cause a watcher retry loop to happen, but if there are we should also catch them.
So, what we should probably try to do:

catch the RBAC permission issue (that will cause a retry loop within watcher)
have watcher take a mandatory backoff that controls non-critical error retries
create a builder for watcher  that creates a sensible default backoff #276
document the error cases that are actually bubbled up from watcher to the user

The last point here because most users thing watcher/reflector always returns true and just uses ? without thinking (and i've personally never seen it crash the app). So if we suddenly add a common case here, we should document it.

I can't think of any other non-ephemeral issues that can cause a watcher retry loop to happen, but if there are we should also catch them.

I'm not so sure that we can make a hard distinction here. For example:

RBAC errors may be caused by misconfiguration (permanent) or a redeploy that reorganizes RBAC roles but ultimately gives the same permissions in the end (ephemeral)
404 errors may be caused by a K8s version mismatch or missing CRD (permanent) or a new CRD that hasn't been picked up by the API server yet (ephemeral)
Connection errors may be caused by firewall misconfiguration (permanent) or the load balancer not having picked up on the new cluster state yet (ephemeral)

And so on, and so forth. Ultimately, we need to percolate the problem up to the administrator and let them handle the problem.
And even if it is a human-caused misconfiguration error, it'd still be useful to retry since we probably won't get notified once the issue is resolved.

True. These configuration errors can happen, and it's nice if we can just keep retrying through it. But it's also important for us to provide that first signal that something has gone wrong upstream (like in the load balancer policy example - if we silently try to retry for that, then we'll never get correct percolation).
I checked watcher with some custom rbac to limit my watch and list permissions inside to verify and the following errors are not retried and are bubbled up to the stream consumer:

ErrorResponse 403 (missing/insufficient rbac)
ErrorResponse 404 (missing/invalid api kind)

So these would be up to users to handle atm.
Pre-backoff; I think this is good. If the user want's to be resilient towards upstream configuration errors (rather than crash and slowly go into CrashLoopBackOff), then they should be explicit about that and percolate signals in other ways (most clusters have notification systems when pods go into crashloop after all so it's a pretty safe default).
But this means that means the RBAC retry we get from configmapgen_controller (if we delete the configmapgenerators.nullable.se crd) is because the controller discards the watcher's errors. So we are currently inconsistent in our strategy.
If we inject backoffs into watcher then it probably also needs some sort of default threshold for how long the watcher (and ultimately the using Controller) is allowed to exist in a non-functioning state, because otherwise we run the risk of the default behaviour not percolating signals upstream at all.

authors: clux teozkr

repo: kube-rs/kube-rs


text:
fix:the dataprocessing image cannot be build.

What type of PR is this?
What this PR does / why we need it
the dataprocessing image cannot be build.
Which issue(s) this PR fixes
Special notes for your reviewer

Please modify this file in the current pr to trigger the image build test. Thank you.
https://github.com/kubeagi/arcadia/blob/d5053b18f8cf42d6543005fc8fdf266dc1d7be66/.github/workflows/data_processing_image_build_test.yml#L7 should change to 'pypi/data-processing/**'

source: gharchive/pull-request

authors: Abirdcfly wangxinbiao

repo: kubeagi/arcadia

license_type: permissive

license_source: github-api


text:
remove kustomize binary from the repo

I think this was in there by mistake so removing the same via this patch.
Purpose of PR?:
there was a binary present in the repo and this patch removes the same.
Does this PR introduce a breaking change?
If the changes in this PR are manually verified, list down the scenarios covered::
Additional information for reviewer? :
Mention if this PR is part of any design or a continuation of previous PRs
Checklist:

[ ] Bug fix. Fixes #
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] PR Title follows the convention of  <type>(<scope>): <subject>
[ ] Commit has unit tests
[ ] Commit has integration tests

@kranurag7 let's rebase this with main

I have one more PR to merge, will rebase and merge

repo: kubearmor/KubeArmor


text:
AKS admission webhook "mongodb.validators.kubedb.com" denied the request: invalid ResourceStorage request

I am trying to use kubedb for my azure kubernetes cluster (AKS)
system details
Cloud provider :-  Azure
K8s version :- 1.12.5
Kubedb version:- 0.11.0
steps  taken to configure kubedb
follow steps available at https://kubedb.com/docs/0.11.0/setup/install/
installed kubedb-operator and kubedb-catalog
helm install appscode/kubedb --name kubedb-operator --version 0.11.0 --namespace kube-system --set enableAnalytics=false --set rbac.create=true
helm install appscode/kubedb-catalog --name kubedb-catalog --version 0.11.0 --namespace kube-system --set enableAnalytics=false --set rbac.create=true
trying to install mongodb as a chart
apiVersion: kubedb.com/v1alpha1
kind: MongoDB
metadata:
  name: skeleton-mongodb
spec:
  version: 4.1.7
  replicas: {{ .Values.mongoDbReplicaCount }}
  replicaSet:
    name: rs0
  storage:
    storageClassName: default
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: {{ .Values.mongoDbStorageCapacity }}

values.yaml
replica-count: 1
acr: myacr
tag: my-tag
env: test
domain: example.com
mongoDbReplicaCount: 2
mongoDbStorageClass: "default"
mongo-db-storage-capacity: 10Gi

when executing helm for this got following error

Error: release skeleton failed: admission webhook "mongodb.validators.kubedb.com" denied the request: invalid ResourceStorage request

Note the error message: storageClassName: default. Sounds like you don't have a Storageclass called default.
Try kubectl get storageclasses and use a valid name.

result of about command is

i tried running mongodb kubedb object on different cluster it works fine with kubectl
when i try to integrate in existing helm chart it gives me problem. i tried providing explicit value for storageClassName as well instead of  but it does not work

Can you share the log of kubedb operator? Also, what version of kubedb operator are you using?

Actually I found the error:
https://github.com/kubedb/apimachinery/blob/master/pkg/validator/validate.go#L36
You need to specify storage amount you want.
    resources:
      requests:
        storage: 1Gi

@polganesh You don't have mongoDbStorageCapacity entry in your values.yaml file. Instead, you have mongo-db-storage-capacity: 10Gi.
Either use storage: {{ .Values.mongo-db-storage-capacity }} in MongoDB crd or rename mongo-db-storage-capacity to mongoDbStorageCapacity in your values.yaml file.

Hi ,
I tried all the possibilities.
following are the latest.
apiVersion: kubedb.com/v1alpha1
kind: MongoDB
metadata:
  name: skeleton-mongodb
spec:
  version: 4.1.7
  replicas: {{ .Values.mongoDbReplicaCount }}
  replicaSet:
    name: rs0
  storage:
    storageClassName: {{ .Values.mongoDbStorageClass }}
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: {{ .Values.mongoDbStorageCapacity }}

mongoDbReplicaCount: 2
mongoDbStorageClass: "default"
mongoDbStorageCapacity: 10Gi

logs from operator
I0327 06:14:50.436407       1 xray.go:232] testing ValidatingWebhook using an object with GVR = kubedb.com/v1alpha1, Resource=redises
I0327 06:14:59.741147       1 apiservice.go:58] Patching APIService v1alpha1.validators.kubedb.com with {"metadata":{"annotations":{"admission-webhook.appscode.com/active":"true","admission-webhook.appscode.com/status":""}}}.
still, I am getting the same error
helm upgrade skeleton helm-charts/skeleton --install

Can you show us the command you used to install the chart?

In order to install chart which contains mongodb I used following command . This command is for upgrade . Even if I try to use install command I am getting similar error
helm upgrade skeleton helm-charts/skeleton --install

one more observation
when i am executing simple kubectl apply things work well.
consider following k8s file mongo-replica-sets.yaml
apiVersion: kubedb.com/v1alpha1
kind: MongoDB
metadata:
  name: mgo-replicaset
 # namespace: demo
spec:
  version: 4.1.7
  replicas: 5
  replicaSet:
    name: rs0
  storage:
    storageClassName: "default"
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi

i am new to k8s operators i am not sure what is implication of providing --enable-validating-webhook=false as far as we are providing correct values

@polganesh can you confirm you chart template is rendering appropriately? Show output of following command.
helm template <your-chart-name> -x templates/<your-mongo-db-tempate-file> -f <your values.yaml file>

following is the output of this command

helm template command is used to render chart locally. you have to specify your mongo-db-template.yaml file after -x flag.
Btw, can you show output of followings:
helm get manifest skeleton
helm get values skeleton

I found the issue. it is a problem with my values.yaml.
when I provided correct values it works for me with helm charts

can you please close this issue now?

thanks for your inputs @hossainemruz

source: gharchive/issue

authors: hossainemruz polganesh tamalsaha

repo: kubedb/project


text:
Evaluation and Inference of Incremental Learning to Support Heterogeneous Chips

What would you like to be added/modified:
Evaluation and inference in incremental learning can be heterogeneous, and possibly training.
Why is this needed:
Heterogeneous deployment scenarios exist in the actual environment. For example, the evaluation is performed on the NPUA chip and the inference is performed on the NPUB chip.

Since the Evaluation is designed to simulate the Inference phase and choose a better-performing model, Why not unify the deployment of the two scenarios?

authors: JoeyHwong-gk cgafool

repo: kubeedge/sedna


text:
Default to current namespace instead of "Kubeflow" or None

Works better in a multi-user setting.
CC @zabbasi

@karthikv2k Any suggestion on how we might tackle this?
Should we do something like

Have fairing look for POD_NAMESPACE environment variable
Have JupyterNotebook set POD_NAMESPACE env variable on the pod?

Has been fixed in https://github.com/kubeflow/fairing/pull/318?

authors: jinchihe jlewi karthikv2k

repo: kubeflow/fairing

license_source: bigquery


text:
Tfjob template config map.

Tfjob template provides a namespaced configmap where users can provide
default images, mounts, environments, init containers, and other pod
spec resources for the tfjob to be created from the notebook
This addresses some of the issues mentioned in #28

This change is

@r2d4 @wbuchwalter @jlewi Can one of you mark this ok-to-test? I fixed all the unit tests in this PR.

/ok-to-test
If you send me a PR adding yourself to
https://github.com/kubeflow/internal-acls/blob/master/github-orgs/kubeflow/org.yaml
I will send you an invite to the GitHub org so you can trigger tests.
@ashahab Did you consider using an admission controller to supply default values for TFJobs?

@jlewi I created the PR for adding me to kubeflow: https://github.com/kubeflow/internal-acls/pull/38
I haven't thought of admission controllers for defaults. I think these defaults for us would be per-namespace(corresponding to a particular ML org/team) and often would be managed by engineers not familiar with k8s, and therefore configmap is an easy way to configure.

@ashahab This problem of letting administrators define suitable defaults for different types of resources (e.g. TFJob / TFServing etc...) has come up before e.g. kubeflow/kubeflow#732.
I think AdmisionControllers can provide a more flexible pattern for doing this.
As an admin you can define one or more admission controllers. These controllers provide a hook that will modify the resource before it is actually created in the APIServer. This makes it easy for admins to inject common config like environment variables, mounts, etc...
I think this can be done selectively; i.e. you can configure an admission controller to only work on certain namespaces or objects with certain labels / annotations
An advantage of an admission controller is its not tied to how a user submits the resource. So it wouldn't be fairing specific. It could apply to jobs created outside of fairing.
So could we generalize this PR into something that could be used as a web hook admission controller and make it easy for admins to define common config?

How would we configure the admission controller? We'll need something easily confgurable like the PodPreset controller provides PodPresets

@ashahab I think it could be configured pretty much like what you have here; i.e. using a config map to provide the web hook the default values to set.

You can always find me on slack if you want to have a higher bandwidth conversation.
It would be good to get @r2d4's thoughts but I think he's out.

I am closing this as its been abandoned since late last year. Please reopen if needed.

authors: abhi-g ashahab jlewi


text:
TF2OpenAPI Dockerfile + CloudBuild trigger

What this PR does / why we need it: Add TF2OpenAPI Dockerfile + CloudBuild trigger
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:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Release note:

This change is

/cc @ellis-bigelow
/cc @jiwang576

/lgtm
/approve
This will run whenever we push a tag (i.e. if  we cut a 0.1.1)

repo: kubeflow/kfserving


text:
Introduce torch.compile to all PyTorch examples

As the previous discussion https://github.com/kubeflow/training-operator/pull/2024#discussion_r1521943323, I would suggest to introduce torch.compile in PyTorch examples, following the migration of PyTorch to v2 (#2024).
I think it should be guaranteed to work torch.compile, which is the main feature of PyTorch v2 and able to speed up computation and memory access, on PyTorch operator.
However, as @tenzen-y mentioned at https://github.com/kubeflow/training-operator/pull/2024#discussion_r1521683099, there is a concern about supported GPUs (or I think also CUDA versions).
Please let me know your opinions!

/remove-lifecycle stale

/remove-lifecycle stale

/reopen

repo: kubeflow/training-operator


text:
Ingress is in the istio-system namespace

Fix incorrect namespace for command "kubeflow" -> "istio-system"

This change is

/ok-to-test
/assign

/lgtm
/approve

authors: frankzhao sarahmaddox

repo: kubeflow/website


text:
Feature Question: use url with plain text | function-content-type: url+text

Is this a BUG REPORT or FEATURE REQUEST?: FEATURE REQUEST
What happened:
When I try to use function-content-type: url+text, the prepare container crash with error code 7.
I try to exec those command manual with docker run --rm kubeless/unzip curl 'https://github.com/helloget.py?raw=true' -L --silent --output /tmp/func.fromurl && cp /tmp/func.fromurl /helloget.py but it said cp: could not create file '/kubeless/helloget.py': dir not found.
Does kubeless support url with plain text for function-content-type?
What you expected to happen:
Prepare container exit with code 0.
(I think the problem is it didn't create dir)
How to reproduce it (as minimally and precisely as possible):
Try this config
apiVersion: kubeless.io/v1beta1
kind: Function
metadata:
  name: examplefunc
spec:
  runtime: python3.7
  timeout: "60"
  handler: helloget.foo
  function: https://github.com/kubeless/kubeless/blob/master/examples/python/helloget.py?raw=true
  function-content-type: url+text

Anything else we need to know?:
None :)
Environment:

Kubernetes version (use 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.4", GitCommit:"d360454c9bcd1634cf4cc52d1867af5491dc9c5f", GitTreeState:"clean", BuildDate:"2020-11-11T13:09:17Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}

Kubeless version (use kubeless version): v1.0.7-dirty
Cloud provider or physical cluster:  Physical cluster

Any help will be appreciated! :)
Thanks!

Hi,
If your function is pointing to a text file, you don't need to specify   function-content-type: url+text, simply   function-content-type: url will make the trick.
Also, remember that you can use the kubeless binary to generate function YAMLs so you avoid these kind of issues (using the flags --dryrun and -o yaml):
▶ kubeless function deploy get-python-url-deps3 --runtime python3.7 --handler helloget.foo --from-file https://github.com/kubeless/kubeless/blob/master/examples/python/helloget.py\?raw\=true --dryrun -o yaml
apiVersion: kubeless.io/v1beta1
kind: Function
metadata:
  creationTimestamp: null
  labels:
    created-by: kubeless
    function: get-python-url-deps3
  name: get-python-url-deps3
  namespace: default
spec:
  checksum: sha256:d251999dcbfdeccec385606fd0aec385b214cfc74ede8b6c9e47af71728f6e9a
  deps: ""
  function: https://github.com/kubeless/kubeless/blob/master/examples/python/helloget.py?raw=true
  function-content-type: url
  handler: helloget.foo
  timeout: "180"

Hi,
If your function is pointing to a text file, you don't need to specify  function-content-type: url+text, simply  function-content-type: url will make the trick.
Also, remember that you can use the kubeless binary to generate function YAMLs so you avoid these kind of issues (using the flags --dryrun and -o yaml):
▶ kubeless function deploy get-python-url-deps3 --runtime python3.7 --handler helloget.foo --from-file https://github.com/kubeless/kubeless/blob/master/examples/python/helloget.py\?raw\=true --dryrun -o yaml
apiVersion: kubeless.io/v1beta1
kind: Function
metadata:
  creationTimestamp: null
  labels:
    created-by: kubeless
    function: get-python-url-deps3
  name: get-python-url-deps3
  namespace: default
spec:
  checksum: sha256:d251999dcbfdeccec385606fd0aec385b214cfc74ede8b6c9e47af71728f6e9a
  deps: ""
  function: https://github.com/kubeless/kubeless/blob/master/examples/python/helloget.py?raw=true
  function-content-type: url
  handler: helloget.foo
  timeout: "180"

Thanks for reply!
When I try that I got

with config
apiVersion: kubeless.io/v1beta1
kind: Function
metadata:
  creationTimestamp: null
  labels:
    created-by: kubeless
    function: get-python-url-deps3
  name: get-python-url-deps3
spec:
  runtime: python3.7
  function: https://github.com/kubeless/kubeless/blob/master/examples/python/helloget.py?raw=true
  function-content-type: url
  handler: helloget.foo
  timeout: "180"

I think the reason that container failed is command cp will not auto create dir /kubeless.

I think that is my network's fault. Sorry for that.
Thanks for all people who contribute in this project and help me! :)

It seem like #1167 doesn't include in the latest release. When will the next version release?
I am looking forward to the feature "support tar compress"! :)
Thanks for hard working!

I have to put some time apart to do a release but in the meantime, you can use the latest image built by the CI. You can use editing the kubeless deployment:
kubectl edit deployment -n kubeless kubeless-controller-manager

And replace the image for the function-controller:
-        image: kubeless/function-controller:v1.0.7
+        image: kubeless/function-controller@sha256:d00b2c3e91f2ff2eff3cea611a4cc5858165118a836898cbfd1571b96bff089f

repo: kubeless/kubeless


text:
Implement support for cluster level resources

Closes #41

Codecov Report

Merging #42 (df89f66) into master (f320011) will decrease coverage by 0.55%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #42      +/-   ##
==========================================
- Coverage   77.34%   76.79%   -0.56%
==========================================
  Files           8        8
  Lines         415      418       +3
==========================================
  Hits          321      321
- Misses         60       63       +3
  Partials       34       34

Impacted Files
Coverage Δ

core/dragnetwebhook.go
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

Codecov Report

Merging #42 (df89f66) into master (f320011) will decrease coverage by 0.55%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #42      +/-   ##
==========================================
- Coverage   77.34%   76.79%   -0.56%
==========================================
  Files           8        8
  Lines         415      418       +3
==========================================
  Hits          321      321
- Misses         60       63       +3
  Partials       34       34

Impacted Files
Coverage Δ

core/dragnetwebhook.go
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

authors: codecov-io vassilvk

repo: kubemod/kubemod


text:
Revert "upgrade ovs-ovn pod by generation version instead of chart ve…

…rsion (#1960)"
This reverts commit f075458703d478c9ba8811e8e676dc07c07811c8.
Pull Request

[ ] Make sure you have followed Kube-OVN Code Style.

What type of this PR
Examples of user facing changes:

Features
Bug fixes
Docs
Tests

Which issue(s) this PR fixes
Fixes #(issue-number)
WHAT
copilot:summary
copilot:poem
HOW
copilot:walkthrough

https://jira.alauda.cn/browse/ZSZQ-167

只需要修改 release-1.9 和 release-1.11 分支，其他分支不受影响。release-1.12 和 master 分支，不需要修改

repo: kubeovn/kube-ovn


text:
Add support for Dual-Stack IPv6

Description of the feature you would like to add / User story
As a KubeOne user
I would like to utilize the dual-stack IPv6 feature in Kubernetes
Solution details

Add support for creating clusters with Dual-Stack IPV6 enabled

Additional information
machine-controller and OSM already support Dual-Stack IPv6. KKP already has dual-stack IPv6 support, so we can base our implementation on KKP's implementation.

[x] AWS
[ ] Azure
[ ] GCP
[ ] VSphere
[ ] OpenStack
[ ] Equinix
[ ] Hetzner
[ ] DigitalOcean

/unassign

repo: kubermatic/kubeone


text:
Fix ca-bundle configuration for machine controller webhook

Signed-off-by: Waleed Malik ahmedwaleedmalik@gmail.com

What this PR does / why we need it:
Adds missing flag, volume and volume mount for custom CA bundle is machine-controller webhook's manifests.
Which issue(s) this PR fixes:

Fixes #2585
What type of PR is this?

/kind bug
Special notes for your reviewer:
Does this PR introduce a user-facing change? Then add your Release Note here:

Fixes an issue where custom ca-bundle was not being propagated to the machine controller webhooks

Documentation:

NONE

@ahmedwaleedmalik please also add
"kubeone.k8c.io/cabundle-hash": "{{ .Config.CABundle | sha256sum }}"

to spec.template.metadata.annotations

/approve
/lgtm

/cherry-pick release/v1.5

I meant v1.4.
/cherry-pick release/v1.4

authors: ahmedwaleedmalik kron4eg xmudrii


text:
refactor registrar to use new api objects

WIP refactor registrar to use the latest CSI spec

@saad-ali tests are green now, PTAL.

LGTM!
Thanks @sbezverk

authors: saad-ali sbezverk

repo: kubernetes-csi/driver-registrar


text:
start: fix wait loop for cluster scoped CRDs

Cluster scoped CRDs have a different URI.

/assign @rphillips @aaronlevy
This is critical for our CVO crd.

The issue is actually a different one. The whole CRD check is broken. Will open another PR.

repo: kubernetes-incubator/bootkube


text:
Move from glide to dep

dep is production-ready and supposedly better. it also has vendor pruning built in so we can use that instead of having people use the third-party glide-vc tool to keep the vendor dir size down

/assign @wongma7

/cc @msau42

@hzxuzhonghu Do you have time to continue on this? Using glide is painful. I hope we can migrate to dep.

ping @wongma7 ptal

/lgtm
thank you very much @hzxuzhonghu this seems too good to be true :)

authors: cofyc hzxuzhonghu wongma7

repo: kubernetes-incubator/external-storage


text:
add possibility to disable fail with swap

Added setting to disable swap checking by kubelet.

ci check this

authors: Atoms mattymo

repo: kubernetes-incubator/kubespray


text:
Set node labels from AWS instance tag

Set kubernetes node labels from a given comma-separated list of key=value from AWS instance tag kubespray-node-labels.

@jjungnickel @ArchiFleKs hey guys, any chance for this PR to be merged?

ci check this

/lgtm
/approve

authors: caruccio mirwan woopstar


text:
Send accepts_incomplete correctly on (de)provision

Fixes #655

LGTM if CI is happy

I've verified the fix against the broker from #655, thanks @pmorie

authors: duglin pmorie spadgett

repo: kubernetes-incubator/service-catalog


text:
CAPI v1.5.0-beta.0 has been released and is ready for testing

CAPI v1.5.0-beta.0 has been released and is ready for testing.
Looking forward to your feedback before CAPI 1.5.0 release, the 25th July 2023!
For quick reference

CAPI v1.5.0-beta.0 release notes
Shortcut to CAPI git issues

Following are the planned dates for the upcoming releases

Release
Expected Date

v1.5.0-beta.x
Tuesday 5th July 2023

release-1.5 branch created (Begin [Code Freeze])
Tuesday 11th July 2023

v1.5.0-rc.0 released
Tuesday 11th July 2023

release-1.5 jobs created
Tuesday 11th July 2023

v1.5.0-rc.x released
Tuesday 18th July 2023

v1.5.0 released
Tuesday 25th July 2023

/remove-lifecycle stale

/remove-lifecycle stale

authors: hrak nawazkh vishesh92


text:
Update Generated Code

Ran "make gen" using Go 1.16.1. Some changes were merged, but "make gen"
was not run. This fixes the problem.
See below PR for reference:
https://github.com/kubernetes-sigs/descheduler/pull/523

/assign @damemi
/cc @ingvagabund

/kind cleanup

/lgtm

authors: ingvagabund seanmalloy

repo: kubernetes-sigs/descheduler


text:
unjoin - re-join flow doesn't work

the flow of unjoining and rejoining clusters doesn't work because the unjoin does not clean the resources crested during join and the join fails if these resources are already present.
The unjoin - rejoin flow is needed to create idempotent installation scripts.
I don't know the implementation details behind the join phase, but if the created resources were created with the apply semantic, probably this would be enough to fix this issue.

@raffaelespazzoli can you please append some output of the error message when you unjoin and then re-join?
@xunpan can you help on this?

@gyliu513 I'd see something like this:
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["/home/rspazzol/git/openshift-federation/ansible/roles/install-federation/files/bin/kubefed2", "join", "raffa1", "--cluster-context", "raffa1", "--host-cluster-context", "raffa1", "--add-to-registry", "--v=2"], "delta": "0:00:00.554151", "end": "2018-11-10 13:09:59.352751", "msg": "non-zero return code", "rc": 255, "start": "2018-11-10 13:09:58.798600", "stderr": "I1110 13:09:58.807372   19567 join.go:141] Args and flags: name raffa1, host: raffa1, host-system-namespace: federation-system, registry-namespace: kube-multicluster-public, kubeconfig: , cluster-context: raffa1, secret-name: , limited-scope: false, dry-run: false\nI1110 13:09:58.815129   19567 join.go:195] Performing preflight checks.\nI1110 13:09:59.132907   19567 join.go:283] Registering cluster: raffa1 with the cluster registry.\nI1110 13:09:59.179767   19567 join.go:292] Registered cluster: raffa1 with the cluster registry.\nI1110 13:09:59.179824   19567 join.go:216] Creating federation-system namespace in joining cluster\nI1110 13:09:59.222453   19567 join.go:224] Created federation-system namespace in joining cluster\nI1110 13:09:59.222506   19567 join.go:227] Creating cluster credentials secret\nI1110 13:09:59.222527   19567 join.go:418] Creating service account in joining cluster: raffa1\nI1110 13:09:59.268708   19567 join.go:428] Created service account: raffa1-raffa1 in joining cluster: raffa1\nI1110 13:09:59.268772   19567 join.go:444] Creating cluster role and binding for service account: raffa1-raffa1 in joining cluster: raffa1\nI1110 13:09:59.343927   19567 join.go:538] Could not create cluster role for service account: raffa1-raffa1 in joining cluster: raffa1 due to: clusterroles.rbac.authorization.k8s.io \"federation-controller-manager:raffa1-raffa1\" already exists\nI1110 13:09:59.344176   19567 join.go:448] Error creating cluster role and binding for service account: raffa1-raffa1 in joining cluster: raffa1 due to: clusterroles.rbac.authorization.k8s.io \"federation-controller-manager:raffa1-raffa1\" already exists\nI1110 13:09:59.344298   19567 join.go:233] Could not create cluster credentials secret: clusterroles.rbac.authorization.k8s.io \"federation-controller-manager:raffa1-raffa1\" already exists\nF1110 13:09:59.344410   19567 join.go:117] error: clusterroles.rbac.authorization.k8s.io \"federation-controller-manager:raffa1-raffa1\" already exists", "stderr_lines": ["I1110 13:09:58.807372   19567 join.go:141] Args and flags: name raffa1, host: raffa1, host-system-namespace: federation-system, registry-namespace: kube-multicluster-public, kubeconfig: , cluster-context: raffa1, secret-name: , limited-scope: false, dry-run: false", "I1110 13:09:58.815129   19567 join.go:195] Performing preflight checks.", "I1110 13:09:59.132907   19567 join.go:283] Registering cluster: raffa1 with the cluster registry.", "I1110 13:09:59.179767   19567 join.go:292] Registered cluster: raffa1 with the cluster registry.", "I1110 13:09:59.179824   19567 join.go:216] Creating federation-system namespace in joining cluster", "I1110 13:09:59.222453   19567 join.go:224] Created federation-system namespace in joining cluster", "I1110 13:09:59.222506   19567 join.go:227] Creating cluster credentials secret", "I1110 13:09:59.222527   19567 join.go:418] Creating service account in joining cluster: raffa1", "I1110 13:09:59.268708   19567 join.go:428] Created service account: raffa1-raffa1 in joining cluster: raffa1", "I1110 13:09:59.268772   19567 join.go:444] Creating cluster role and binding for service account: raffa1-raffa1 in joining cluster: raffa1", "I1110 13:09:59.343927   19567 join.go:538] Could not create cluster role for service account: raffa1-raffa1 in joining cluster: raffa1 due to: clusterroles.rbac.authorization.k8s.io \"federation-controller-manager:raffa1-raffa1\" already exists", "I1110 13:09:59.344176   19567 join.go:448] Error creating cluster role and binding for service account: raffa1-raffa1 in joining cluster: raffa1 due to: clusterroles.rbac.authorization.k8s.io \"federation-controller-manager:raffa1-raffa1\" already exists", "I1110 13:09:59.344298   19567 join.go:233] Could not create cluster credentials secret: clusterroles.rbac.authorization.k8s.io \"federation-controller-manager:raffa1-raffa1\" already exists", "F1110 13:09:59.344410   19567 join.go:117] error: clusterroles.rbac.authorization.k8s.io \"federation-controller-manager:raffa1-raffa1\" already exists"], "stdout": "", "stdout_lines": []}

sorry for the formatting, this is ansible's output.
In general I noticed that the secrets in the federation-system namespace and the clusterroles were the objects for which I was getting errors.

@raffaelespazzoli I did some test to un-join and re-join, kubefed2 works fine, can you please run kubefed2 join and unjoin manually to see if it works and then check what is wrong with your ansible script?
Unjoin cluster2, succeed.
root@gyliu-dev1:~/go/src/github.com/kubernetes-sigs/federation-v2# ./bin/kubefed2 unjoin cluster2 --cluster-context cluster2 --host-cluster-context cluster1 --remove-from-registry --v=2
I1110 18:02:27.013294   28407 unjoin.go:112] Args and flags: name cluster2, host-cluster-context: cluster1, host-system-namespace: federation-system, kubeconfig: , cluster-context: cluster2, dry-run: false
I1110 18:02:27.024585   28407 unjoin.go:166] Performing preflight checks for unjoin cluster: cluster2.
I1110 18:02:27.051670   28407 unjoin.go:253] Removing cluster: cluster2 from the cluster registry.
I1110 18:02:27.097270   28407 unjoin.go:261] Removed cluster: cluster2 from the cluster registry.
I1110 18:02:27.097314   28407 unjoin.go:179] Deleting federated cluster resource from namespace: federation-system for unjoin cluster: cluster2
I1110 18:02:27.161053   28407 unjoin.go:190] Deleted federated cluster resource from namespace: federation-system for unjoin cluster: cluster2
I1110 18:02:27.161135   28407 unjoin.go:317] Deleting cluster role binding for service account: cluster2-cluster1 in unjoining cluster: cluster2
I1110 18:02:27.208453   28407 unjoin.go:327] Deleted cluster role binding for service account: cluster2-cluster1 in unjoining cluster: cluster2
I1110 18:02:27.208485   28407 unjoin.go:330] Deleting service account cluster2-cluster1 in unjoining cluster: cluster2
I1110 18:02:27.214038   28407 unjoin.go:337] Deleted service account cluster2-cluster1 in unjoining cluster: cluster2
I1110 18:02:27.214067   28407 unjoin.go:204] Deleting federation namespace: federation-system from unjoin cluster: cluster2
I1110 18:02:27.219185   28407 unjoin.go:214] Deleted federation namespace: federation-system from unjoin cluster: cluster2

Join cluster2 again, succeed.
root@gyliu-dev1:~/go/src/github.com/kubernetes-sigs/federation-v2# ./bin/kubefed2 join cluster2 --cluster-context cluster2 --host-cluster-context cluster1 --add-to-registry --v=2
I1110 18:02:51.772639   28424 join.go:141] Args and flags: name cluster2, host: cluster1, host-system-namespace: federation-system, registry-namespace: kube-multicluster-public, kubeconfig: , cluster-context: cluster2, secret-name: , limited-scope: false, dry-run: false
I1110 18:02:51.782340   28424 join.go:195] Performing preflight checks.
I1110 18:02:51.805633   28424 join.go:283] Registering cluster: cluster2 with the cluster registry.
I1110 18:02:51.877007   28424 join.go:292] Registered cluster: cluster2 with the cluster registry.
I1110 18:02:51.877056   28424 join.go:216] Creating federation-system namespace in joining cluster
I1110 18:02:51.884674   28424 join.go:224] Created federation-system namespace in joining cluster
I1110 18:02:51.884723   28424 join.go:227] Creating cluster credentials secret
I1110 18:02:51.884778   28424 join.go:418] Creating service account in joining cluster: cluster2
I1110 18:02:52.018171   28424 join.go:428] Created service account: cluster2-cluster1 in joining cluster: cluster2
I1110 18:02:52.018237   28424 join.go:444] Creating cluster role and binding for service account: cluster2-cluster1 in joining cluster: cluster2
I1110 18:02:52.044267   28424 join.go:453] Created cluster role and binding for service account: cluster2-cluster1 in joining cluster: cluster2
I1110 18:02:52.044318   28424 join.go:457] Creating common cluster role and binding for service account: cluster2-cluster1 in joining cluster: cluster2
I1110 18:02:52.063560   28424 join.go:466] Created common cluster role and binding for service account: cluster2-cluster1 in joining cluster: cluster2
I1110 18:02:52.063600   28424 join.go:469] Creating secret in host cluster: cluster1
I1110 18:02:52.073357   28424 join.go:696] Using secret named: cluster2-cluster1-token-7t928
I1110 18:02:52.091829   28424 join.go:728] Created secret in host cluster named: cluster2-mkxcv
I1110 18:02:52.091861   28424 join.go:478] Created secret in host cluster: cluster1
I1110 18:02:52.092145   28424 join.go:237] Cluster credentials secret created
I1110 18:02:52.092218   28424 join.go:239] Creating federated cluster resource
I1110 18:02:52.100348   28424 join.go:248] Created federated cluster resource

Check cluster2 status, it is ready again.
root@gyliu-dev1:~/go/src/github.com/kubernetes-sigs/federation-v2# kubectl -n federation-system describe federatedclusters
Name:         cluster1
Namespace:    federation-system
Labels:       <none>
Annotations:  <none>
API Version:  core.federation.k8s.io/v1alpha1
Kind:         FederatedCluster
Metadata:
  Creation Timestamp:  2018-11-11T01:18:48Z
  Generation:          1
  Resource Version:    313085
  Self Link:           /apis/core.federation.k8s.io/v1alpha1/namespaces/federation-system/federatedclusters/cluster1
  UID:                 bddfa1bd-e54f-11e8-9049-00163e01fa8a
Spec:
  Cluster Ref:
    Name:  cluster1
  Secret Ref:
    Name:  cluster1-pl5rk
Status:
  Conditions:
    Last Probe Time:       2018-11-11T02:02:48Z
    Last Transition Time:  2018-11-11T01:19:12Z
    Message:               /healthz responded with ok
    Reason:                ClusterReady
    Status:                True
    Type:                  Ready
Events:                    <none>

Name:         cluster2
Namespace:    federation-system
Labels:       <none>
Annotations:  <none>
API Version:  core.federation.k8s.io/v1alpha1
Kind:         FederatedCluster
Metadata:
  Creation Timestamp:  2018-11-11T02:02:52Z
  Generation:          1
  Resource Version:    313086
  Self Link:           /apis/core.federation.k8s.io/v1alpha1/namespaces/federation-system/federatedclusters/cluster2
  UID:                 e58c423b-e555-11e8-9049-00163e01fa8a
Spec:
  Cluster Ref:
    Name:  cluster2
  Secret Ref:
    Name:  cluster2-mkxcv
Status:
  Conditions:
    Last Probe Time:       2018-11-11T02:02:48Z
    Last Transition Time:  2018-11-11T02:02:48Z
    Message:               /healthz responded with ok
    Reason:                ClusterReady
    Status:                True
    Type:                  Ready
Events:                    <none>

@raffaelespazzoli For your issue, I think the unjoin failed, and this left some garbage data and caused re-join failed. I'd suggest you clean up your cluster and re-run this again. Please make sure unjoin succeed before you re-join again.

Thanks @raffaelespazzoli , so here you want to enable force join here, let's get some comments from @marun for this, the only concern from me is that the force join may leave some garbage data.
@marun WDYT?

I think this issue is a duplicate of #188, and I'm closing accordingly.  unjoin should remove everything it can rather than bailing on the first error it encounters.  Feel free to reopen if you do not agree with my assessment.

authors: gyliu513 marun raffaelespazzoli


text:
gofmt presubmit should be friendlier

Our presubmit should:

Tell users to call make fmt, not go fmt (we don't want to reformat vendor files)
Print out the diff so users can see what changes to make

/good-first-issue

Hey @adrianludwin , what could be the right way to start on this?

authors: adrianludwin rahulii

repo: kubernetes-sigs/hierarchical-namespaces


text:
Update readme and deployment files for release v0.3.0

What type of PR is this?
/kind cleanup
/kind documentation
What this PR does / why we need it:
Upgrading the csi side cars to the latest version.
Modifying the readme file for csi v0.3.0.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Release note:
none

@mkumatag , csi attacher is updated to v3.5.1.


text:
[DOCS] Docs for Preempt action

What this PR does / why we need it:
Added Docs for Preempt Action
Preview: https://github.com/thandayuthapani/kube-batch/blob/preempt/doc/design/preempt-action.md
https://github.com/kubernetes-sigs/kube-batch/issues/434

/assign @k82cn

/lgtm
/approve

repo: kubernetes-sigs/kube-batch


text:
Added Queue status.

Signed-off-by: Da K. Ma klaus1982.cn@gmail.com
Release note:
Added number of PodGroup in different state.

LGTM

/lgtm


text:
Implements prefilter and configures TinyGo unit tests

What type of PR is this?
/kind feature
What this PR does / why we need it:
This implements the prefilter function and configures TinyGo unit tests via make test-guest. This runs the same unit tests without TinyGo on make test.
Which issue(s) this PR fixes:
Special notes for your reviewer:

This uses the name "prefilter" not "preFilter" because it matches the package name and helps clarify it is an operation name. We still use PreFilter when referring to framework.
This implements prefilter node name results with a host callback for the same reason as the status reason: using a host callback allows the guest to control memory allocation. This uses a C-String approach to avoid complexity in marshalling. The same approach is used in http-wasm for header values.
This intentionally does not do anything other design changes, such as caching state. We can do that in another PR.
tinygo test uses a wasmtime by default, so the Makefile has been updated to switch to wazero.
To avoid segfaults in TinyGo tests, this removes nottinygc as a strict dependency, and instead conventionally adds it when compiling plugins to wasm.
This intentionally does not backfill more TinyGo unit tests because the change is already large.

Does this PR introduce a user-facing change?
NONE
What are the benchmark results of this change?
goos: darwin
goarch: arm64
pkg: sigs.k8s.io/kube-scheduler-wasm-extension/internal/e2e
                                                        │  before.txt  │              after.txt               │
                                                        │    sec/op    │    sec/op     vs base                │
PluginFilter/noop-wat/params:_small-12                    262.3n ±  2%   265.2n ±  1%       ~ (p=0.121 n=6)
PluginFilter/noop-wat/params:_real-12                     269.6n ±  2%   268.3n ±  1%       ~ (p=0.619 n=6)
PluginFilter/noop/params:_small-12                        333.1n ±  1%   328.0n ±  1%  -1.52% (p=0.002 n=6)
PluginFilter/noop/params:_real-12                         338.0n ±  2%   332.1n ±  3%  -1.75% (p=0.004 n=6)
PluginFilter/test/params:_small-12                        6.431µ ±  1%   6.438µ ±  0%       ~ (p=0.669 n=6)
PluginFilter/test/params:_real-12                         115.5µ ±  2%   116.8µ ±  0%  +1.14% (p=0.004 n=6)
PluginScore/noop-wat/params:_small-12                     260.6n ±  0%   259.7n ±  3%       ~ (p=0.056 n=6)
PluginScore/noop-wat/params:_real-12                      265.4n ±  0%   263.9n ±  0%  -0.55% (p=0.004 n=6)
PluginScore/noop/params:_small-12                         382.4n ±  1%   378.1n ±  0%  -1.15% (p=0.002 n=6)
PluginScore/noop/params:_real-12                          354.4n ±  0%   348.1n ±  0%  -1.76% (p=0.002 n=6)
PluginScore/test/params:_small-12                         3.668µ ±  1%   3.639µ ±  1%  -0.79% (p=0.002 n=6)
PluginScore/test/params:_real-12                          39.85µ ±  2%   39.16µ ± 12%       ~ (p=0.065 n=6)
PluginFilterAndScore/noop-wat/params:_small-12            379.8n ±  0%
PluginFilterAndScore/noop-wat/params:_real-12             390.6n ± 16%
PluginFilterAndScore/noop/params:_small-12                586.5n ±  5%
PluginFilterAndScore/noop/params:_real-12                 554.6n ±  6%
PluginFilterAndScore/test/params:_small-12                10.17µ ±  1%
PluginFilterAndScore/test/params:_real-12                 169.5µ ±  4%
PluginPreFilter/noop-wat/params:_small-12                                281.1n ±  3%
PluginPreFilter/noop-wat/params:_real-12                                 289.1n ±  1%
PluginPreFilter/noop/params:_small-12                                    347.2n ±  1%
PluginPreFilter/noop/params:_real-12                                     350.6n ±  0%
PluginPreFilter/test/params:_small-12                                    3.533µ ±  2%
PluginPreFilter/test/params:_real-12                                     40.56µ ±  9%
PluginPrefilterFilterAndScore/noop-wat/params:_small-12                  517.5n ±  1%
PluginPrefilterFilterAndScore/noop-wat/params:_real-12                   524.3n ±  3%
PluginPrefilterFilterAndScore/noop/params:_small-12                      788.3n ±  0%
PluginPrefilterFilterAndScore/noop/params:_real-12                       753.4n ±  0%
PluginPrefilterFilterAndScore/test/params:_small-12                      14.10µ ±  1%
PluginPrefilterFilterAndScore/test/params:_real-12                       218.8µ ±  1%
geomean                                                   1.436µ         1.429µ        -0.65%               ¹

fixed bench, as the prior commit didn't actually call prefilter. The below is higher because we don't yet cache the pod being scheduled. The next PR should show some dramatic difference
PluginFilterAndScore/test/params:_real-12                     169.5µ ±  4%
PluginPrefilterFilterAndScore/test/params:_real-12            218.8µ ±  1%

/lgtm

authors: codefromthecrypt sanposhiho


text:
Add information on pod webhook namespace selector

What type of PR is this?
/kind documentation

What this PR does / why we need it:

Add information on how to set namespace selector for the pod webhook.

Which issue(s) this PR fixes:

Related issue: #976
Special notes for your reviewer:
Does this PR introduce a user-facing change?

/ok-to-test

authors: achernevskii alculquicondor

repo: kubernetes-sigs/kueue


text:
Ensure we clarify subjects don't include host-net pods

PR enhances the subject description to call out the fact that subjects don't include host-net "pods"

/lgtm

authors: npinaeva tssurya

repo: kubernetes-sigs/network-policy-api


text:
Support multiple images, tags, or digests when growing image manifests

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Part of https://github.com/kubernetes-sigs/promo-tools/issues/508 and https://github.com/kubernetes-sigs/promo-tools/issues/347, continues https://github.com/kubernetes-sigs/promo-tools/pull/507:

Extract manifest functions into a separate package
Update references to manifest operations
image/manifest: Simplify/remove stutters
image/manifest: Support multiple images, tags, or digests in Grow()
image/manifest: Fixup testdata paths

Signed-off-by: Stephen Augustus foo@auggie.dev
Which issue(s) this PR fixes:

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

- image/manifest: Support multiple images, tags, or digests in `Grow()`

/test pull-cip-verify

/assign @puerco @cpanato
cc: @kubernetes-sigs/release-engineering @CecileRobertMichon
/kind feature

Nice, another chunk reworked!
/lgtm

authors: justaugustus puerco

repo: kubernetes-sigs/promo-tools


text:
[stable/fluent-bit] Fluent Bit v0.11.13

Changes

This is a bug fix release over 0.11 series that includes the following changes:

Core
Environment: fix insertions of variables with extra strings.
Hash Table: implement chaining to avoid collisions.
Parser: release resources on init if a parser fails (avoid crash).

Please sign the CLA @MaxPresman

/ok-to-test

Now obsolete.

authors: MaxPresman unguiculus viglesiasce

repo: kubernetes/charts


text:
[stable/redis] Add metrics service

What this PR does / why we need it:
I add metrics service for redis-exporter.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #5237
Special notes for your reviewer:
@javsalgar, Please review this PR.

@k8s-ci-robot
I signed the CLA, and I received a confirmation email from HelloSign.

/ok-to-test

/retest

@unguiculus Previously, the redis-exporter was included in this chart. I think this is more useful.

/retest

/retest

authors: 7CHANHO carrodher mattfarina


text:
How to get nodes based on label fields.

Hello...
I have configured few nodes with label key=test. Would like to use go client to list only nodes having those label. Tried following, does not seem to work
nodes, _ := cs.CoreV1().Nodes().List(metav1.ListOptions{
LabelSelector: "key=test",
})

that's the proper syntax... your code is ignoring the returned error... try checking that to see if you have a connection or permission issue

Thanks it worked. Yes it was connection issue

authors: collbrain liggitt

repo: kubernetes/client-go


text:
Update README with correct Openshift instructions

Openshift repository includes instructions on how to run standalone Heapster or Heapster with Hawkular-Metrics combination on Openshift (with deployment scripts).

lgtm

authors: burmanm mwielgus

repo: kubernetes/heapster


text:
Error: grpc: received message length xxx exceeding the max size 10485760

(I run helm v2.2.2)
I'm developing a new chart, and when I try to debug, I get the following error:
helm install --dry-run --debug --namespace jitsi --name jitsi  ./jitsi-meet
Created tunnel using local port: '44735'
SERVER: "localhost:44735"
CHART PATH: /home/pierre/f/pierreozoux/charts/stable/jitsi-meet
Error: grpc: received message length 337346954 exceeding the max size 10485760

I guess it is because the message output is too big.
There are just 12 yaml files and 245 lines in total.
Just using dry-run flag is doing the same, and trying to install for real, is also the same.
On the server, not much help neither.
Starting Tiller v2.2.2
GRPC listening on :44134
Probes listening on :44135
Storage driver is ConfigMap
2017/03/16 18:34:08 storage.go:94: Listing all releases with filter
2017/03/16 18:40:01 storage.go:94: Listing all releases with filter
2017/03/16 18:41:04 storage.go:94: Listing all releases with filter

I'll split it in various charts and try again.

Typically, you have to be loading quite a bit of data to hit the maximum size. Are some other files sneaking in there? You can use a .helmignore file to prevent things like .git or other directories from being sent to Tiller.

Indeed! I searched in this repo, but didn't find anything about this error.
But thanks a lot, I solved my issue with .helmignore.

authors: pierreozoux technosophos

repo: kubernetes/helm


text:
[v1.18.0] kubectl's version cannot be retrieved WITHOUT a kube config or additional params

It should be possible to check the kubectl version WITHOUT having a valid or any kubeconfig file.
However, now it just throws an error and does NOT display the version in use (v1.18):
 # kubectl version
W0404 15:19:07.071657   17635 loader.go:223] Config not found: /root/.kube/config
error: Missing or incomplete configuration info.  Please point to an existing, complete config file:

  1. Via the command-line flag --kubeconfig
  2. Via the KUBECONFIG environment variable
  3. In your home directory as ~/.kube/config

To view or setup config directly use the 'config' command.

if you use --client=true it will work:
kubectl version --client=true

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:58:59Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

I agree that it would be nice to print the client version though even if there is no config file.

when you just use version without any options it should fetch client and server version and fetching server version without kubeconfig file would not be possible, so i think this is expected behaviour
-srini

I think a local tool should be able to print its version without any external dependencies or extra parameters. If it does not have a kubeconfig, it should print the client version and throw the same error after that. If you specify --client=true, it should still print just the client version - the same goes for --server=true.

It actually should not act like this... My PR will fix this:https://github.com/kubernetes/kubernetes/pull/89913

even after https://github.com/kubernetes/kubernetes/pull/89913, this is still not working as it did in 1.17

will be fixed in 1.18 by https://github.com/kubernetes/kubernetes/pull/90244
/assign @soltysh

/kind bug

/sig cli
/area kubectl

Seems to be fixed now.

/close

you can run this command :   export KUBERNETES_MASTER=http://127.0.0.1:8080    on master role

authors: Ruimingwang Xtigyro brianpursley bseenu liggitt seans3 zhouya0

repo: kubernetes/kubectl


text:
phase2: handle v1alpha3 kubeadm config

fixes failing end-to-end tests due to the removal of v1alpha2 in master.
fixes kubernetes/kubeadm#1151
the diff is hard to read.
PTAL at the whole file.

move v1alpha1 and v1alpha2 in the same block under version <= 11.
add v1alpha3.

/priority critical-urgent
/kind failing-test
/assign @fabriziopandini
/cc @kubernetes/sig-cluster-lifecycle-pr-reviews

@fabriziopandini SGTM, this PR doesn't handle v1beta1 yet.
if your PR merges before this one i can add v1beta1 to this PR too.
otherwise i can send another PR later.

repo: kubernetes/kubernetes-anywhere


text:
Use kubeadm for GCE installation guide

This is a...

[x] Feature Request
[ ] Bug Report

Problem: https://kubernetes.io/docs/getting-started-guides/gce/ uses old
Proposed Solution: It should use kubeadm to create the Google Compute Engine cluster.
(self-assign)

https://github.com/kubernetes/kubernetes/issues/34949 talks about how to get the networking set up.

/reopen

/reopen
/remove-lifecycle rotten
/lifecycle frozen

authors: ahmetb craigbox


text:
Issue with k8s.io/docs/tutorials/kubernetes-basics/deploy-interactive/

This is a...

[ ] Feature Request
[ X] Bug Report

Problem:
Tutorial hangs at "we are preparing the environment for you..."
Proposed Solution:
Make the tutorial work.
Page to Update:
http://kubernetes.io/...

Thank you for the report @sungwookgit
Could you verify that you can generally get access to the website https://katacoda.com from your local browser? I just accessed the page you indicated, and the tutorial iframe came up and was active without issue, but it is hosted separately from the documention itself. If you're unable to access content from a 3rd party website, the interactive tutorial component may not work correctly for you.

/cc @BenHall

Thanks @sungwookgit, as @heckj mentioned could you please try directly on the site at https://katacoda.com/kubernetes-bootcamp/scenarios/1

Thanks for the quick responses. The linked site shows the same thing. I guess it is either my company network or some missing plugins then. I will try this at my home. FYI, I was using Chrome browser running on Windows 7 :)

@sungwookgit thanks for the feedback and the issue. I'm going to close this issue for now, but feel free to re-open if there's a specific documentation issue. You can also reach us on the sig-docs channel of the Kubernetes slack

authors: BenHall heckj sungwookgit


text:
Removed non-org members from OWNERS.

Removed the following folks because we cannot assign PRs to members outside the organization.
Someone with privileges can invite them, and we'll revert the PR.

matthewdupre
isubuz
coolsvap
gertipoppel
nak3
mikebrow
pires
chrisseto
daizuozhuo
MikeSpreitzer
johscheuer
AntonioMeireles
jijun2
tpryan
paurullan
gouyang
glnds
rutsky
mbruzek
zreigz
caseydavenport
jeffbean
paulzim
WIZARD-CXY
laushinka
ckleban
asridharan
lhuard1A
anzhsoft
JamesDeFabia
ohtake
CreaturesInUnitards
AlainRoy
juretta
joshix
doublerr
bobrik
stp-ip
alexhersh
elsonrodriguez
atomantic
eyalev
dalanlan
mwhahaha
joshperry

LGTM

authors: foxish kelseyhightower


text:
Fix missing build arg in build-in-docker make target

Fixes https://github.com/kubernetes/node-problem-detector/issues/778
Before:

After:

Thanks for the fix!
/ok-to-test
/lgtm

/retest-required

Tests are failing due to https://github.com/kubernetes/test-infra/pull/29751, let's fix that and then this should not be an issue any longer.

/retest-required

/retest

Ah missed the comment about why the tests are failing. Should I rebase on that once merged?

/retest-required

Yes, this is a known issue: https://github.com/kubernetes/kubernetes/issues/119211.
We're working on fixing it, apologies for any inconveniences caused.

/retest-all

/retest

Green bill of health 👍. @mmiranda96 Are you good to approve?

I can't approve PRs unfortunately.
Varsha, could you help us approve this change?
/assign @vteratipally

/lgtm
/approve

authors: btiernay mmiranda96 vteratipally

repo: kubernetes/node-problem-detector


text:
Enable slow API calls allowance in 1.17 tests

More convenient alternative for #1379's PR intention. CL2_ALLOWED_SLOW_API_CALLS env var would be fetched from a preset (it already lives there).
/sig scalability
/cc mm4tt

/lgtm
/approve

repo: kubernetes/perf-tests


text:
make registry.k8s.io reusable

Right now we've hardcoded some things to prioritize shipping an efficient implementation expediently.
In particular the AWS client region : backend bucket mapping is hardcoded in the application, to avoid complex runtime config loading in cloud run, simplifying the app and improving reliability but making the cmd/archeio non-reusable.
However, since we started, some key things have changed:

We stopped using k8s.gcr.io to regionalize backend traffic for us, in order to migrate to Artifact Registry regional instances and unblock the possibility of redirecting k8s.gcr.io to registry.k8s.io. In doing so we configured each cloud run region to forward traffic to a matching Artifact Registry region, leaning on the application loadbalancer (GCLB) in front of the regional backend instances to determine which region we should serve from.
We have substantial funding from AWS, instead of a verbal agreement to host AWS client traffic specifically
Due to 1) and 2) we implemented #147 which was done by configuring a mapping from cloud run region to default S3 bucket, based on region proximity between GCP and AWS.

As a result, except for known-AWS client IPs, we already map based on the location of the application instance receiving the traffic behind the loadbalancer, which appears to be working well so far. We're also not as sensitive to spend on AWS with increased funding.
This has been discussed before, but I propose ripping out the hardcoded bucket mapping and instead allow a simple environment variable configuration like this:
GCP_LAYER_HOST=upstream
AWS_LAYER_HOST=https://s3-bucket-for-instance-region

Where for each ${CLOUD}_LAYER_HOST environment variable we allow either "upstream" (meaning the source registry) or "http...." (meaning some object store).
Then other potential users can use the same binary/image as us and just configure these inputs differently.
The upstream source registry is already configurable, and the only thing we depend on there is public-read-without-authentication.
There will be a cost increase for us as we less-precisely map to the nearest S3 backend, but I don't expect that to be an issue anymore with the updated funding. In return this will be even simpler to maintain, as we need only configure the cloud run instances with the default backend per cloud we support detecting. That mapping can be updated without touching the binary sources and still avoid complex runtime config (and potential operational issues with config parsing failures, slower app warmup, etc).
Future clouds will be straightforward to add.

+1

If/when we do this, we should expand IP data to region-less provider data, like cloud.json => goog.json.

Actually, thinking more about this: I don't think this needs to happen.
So far we've only had 1-2 requests, I think relatively few projects will find themselves in this situation.
If they do, this is relatively easy to build even just configuring something like nginx, and we should focus on what Kubernetes needs (e.g. also things like serving LF privacy policy) and not worry about making this more complex to serve other projects.
If serving public-read images split across multiple providers actually became a very common need, we could engage in collaborating with other projects, but currently there just isn't much demand.

authors: BenTheElder ameukam


text:
Issue with k8s.io/docs/setup/independent/high-availability/

This is a:

[ ] Feature Request
[x] Bug Report

Problem:
for this page: https://kubernetes.io/docs/setup/independent/high-availability/
as written, the instructions almost work on 12.2.2, with one exception.  I get this error:
didn't recognize types with GroupVersionKind: [kubeadm.k8s.io/v1alpha3, Kind=ClusterConfiguration]
in response to:
kubeadm alpha phase kubelet write-env-file --config kubeadm-config.yaml
And things just got worse from there on.
Proposed Solution:
The problem is also reported here: https://github.com/kubernetes/kubeadm/issues/1171
But the exact solution wasn't immediately clear to a n00b.
To get the instructions to work, I needed to add an empty InitConfiguration block to the top of the kubeadm-config.yaml on the second and third control plane nodes.  Specifically, I added this:
  ---
  apiVersion: kubeadm.k8s.io/v1alpha3
  kind: InitConfiguration
  kubernetesVersion: stable

  ---
  (remainder of kubedm-config.yaml from page goes here)

Recommendation, update the kubeadm-config.yaml examples on the page to include these empty blocks.
Otherwise, the documentation is terrific - thank you!
Page to Update:
https://kubernetes.io/docs/setup/independent/high-availability/

hi, let's keep kubernetes/kubeadm#1171
as the tracking issue for this please.
too many issues in different repos are hard to track.
i will add a comment about updating this page.
/close

repo: kubernetes/website


text:
Contribute: Compare Docs Contributing pages with Community Contribuing pages and update Docs

This is a Feature Request

What would you like to be added

Compare Docs Intermediate "Work from a local clone" with Community GitHub workflow. Determine if content from Community should be added to Intermediate. One thing I noted is the Community page has a paragraph about NOT using git pull to update your local branch.
https://kubernetes.io/docs/contribute/intermediate
https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md
For example, the Community guide recommends cloning your fork whereas Intermediate recommends cloning kubernetes/website. I tested both workflows with the prereq that I accidentally permanently deleted my local directories and therefore needed to checkout the branch changes I had pushed to my fork. When I followed the steps on Intermediate and then tried to checkout an existing branch, git couldn’t find the branch; but when I followed the steps in contrib page, I could check out the existing branch.
Also, I'd like to see a specific sections in Intermediate about:

Keeping your fork master up-to-date with kubernetes/website master; https://help.github.com/en/articles/syncing-a-fork
Squashing commits (k8s policy) and link to git info (see Community page)

Also check the Start contributing/Improve existing content section to see if more info is needed, such as squashing commits, which you have to do from command line.
Why is this needed
Make the contribution process as easy as possible for people new to GitHub. Many folks may be familiar with the branch-only git/gerrit workflow like I was, and switching to the GitHub workflow requires an extra step.
Comments

/assign


text:
releases section, relocating tutorials section

With the interest in adding a Releases section (or Releases page from the home page),
investigate whether there is consensus in relocating the  Tutorial sections.
Some comments about this proposed change:

The tutorial section has limited content.
Is the relocation necessary if sections are due to change with the upcoming docs theme addition?
Relocate the Learn K8s Basics tutorial content to the Getting Started section.
Relocate the The Getting Started Release notes and the Release/version skew policy pages to
the Releases section.

Temporarily assigning myself.
/assign @kbhawkey
@jimangel , Related to Release page/section

Closing until new theme is in place.
/close


text:
Translate a Docker Compose File to Kubernetes Resources

When I run the curl command to install kompose, it tells me the exe is incompatible with the 64 bit version of windows. Do you know how I can fix this?

@kish0620 would you be willing to provide some more information?

the command that you ran
the error message that you saw
the version of Windows you're running
what CPU architecture your PC uses

That will help us work out how to revise that page.
/triage needs-information
/language en
/sig cli


text:
Broken link on Submitting blog posts and case studies page

Problem:
The text Upstream Marketing Team on link should point to these https://github.com/kubernetes/community/blob/master/communication/contributor-comms/storytelling-resources/blog-guidelines.md#upstream-marketing-blog-guidelines
Check the page Submitting blog posts and case studies for the problem.
Page to Update:
https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/
Proposed Solution:
It should resolve this issue by adding a simple link and enhancing the document line.
Update the link on the text Upstream Marketing Team to https://github.com/kubernetes/community/blob/master/communication/contributor-comms/storytelling-resources/blog-guidelines.md#upstream-marketing-blog-guidelines and not to this link.
/kind document
/assign
/language en

/triage accepted


text:
Repetitive word(phase) in kubeadm implementation details page

This is a Bug Report
Problem:
There is a repetitive word (phase) in kubeadm implementation details page.

Mark control-plane phase phase can be invoked individually with the command kubeadm init phase mark-control-plane

Proposed Solution:
Remove the repeated word.
Page to Update:
https://kubernetes.io/docs/reference/setup-tools/kubeadm/implementation-details/

/sig docs
/language en
/assign

@T-Lakshmi  can i work on this issue

Hi @pran2711,
Thanks for showing interest on it,
I have already make the changes for this issue, just waiting for triage accepted lable. Once accepted, i will push PR.

Opened PR for it.
#41168

Opened PR #41168 which may fix this issue.

Issue fixed with merged PR #41168, hence closing this issue. Thanks,
/close


text:
Fix orders of yaml of custom-resource-definitions

The orders of kind and metadata were inconsistent, and that made the
doc unreadable.
This fixes the orders in consistent way.
ref: https://github.com/kubernetes/website/issues/13862

/lgtm
/approve

authors: oomichi tengqm


text:
Fixing broken link to Certificate Management with kubeadm

A missing '/' on the link will lead to a 404 error. Fixing it.

please sign the CLA as the bot mentioned above.

I signed it


text:
Update Azure file feature gates for 1.20 beta

Docs for https://github.com/kubernetes/enhancements/issues/1885
/assign @msau42 @annajung
/sig storage
/hold
pr pending merge kubernetes/kubernetes#96293

/assign @SomtochiAma

/milestone 1.20

Hi @andyzhangx Since I saw this issue https://github.com/kubernetes/kubernetes/issues/96508 do you folks will make an exception since the code freeze is on effect or will the enhancement pushed back to 1.21 ?

Hi @andyzhangx Since I saw this issue kubernetes/kubernetes#96508 do you folks will make an exception since the code freeze is on effect or will the enhancement pushed back to 1.21 ?

it could be pushed back to 1.21, depends, will update if there is any new progress, thanks.

hi @andyzhangx this is no longer being tracked for 1.20 release.
Please see https://github.com/kubernetes/enhancements/issues/1885#issuecomment-726531813 for details
Feel free to reopen when an exception has been filed/approved.
/milestone clear
/close

authors: andyzhangx annajung irvifa


text:
Network policy status alpha

Upstream: kubernetes/kubernetes#107963
KEP: https://github.com/kubernetes/enhancements/issues/2943

/close
Wrong branch.


text:
[fr] modify debug link in configure-pod-init

en PR https://github.com/kubernetes/website/pull/33308/files
/assign @remyleone

/lgtm
/approve

authors: Arhell remyleone


text:
Fix 38495 incorrect ValidationAdmissionPolicyBindings

there were some incorrect examples, more info here #38495

/assign @cici37
for technical review

I have some other improvements I will make in a separate PR because wanted to focus on fixing the issues first and then improving the overall doc afterwards.

Thanks for the PR!
/lgtm
nit: if you plan to use codenew shortcode as suggested in https://github.com/kubernetes/website/issues/38495#issuecomment-1353475151

@sftim would you be able to approve?

/approve


text:
Add command to turn off swap in install-kubeadm.md

add swapoff command

/easycla

T-Lakshmi

Hi @T-Lakshmi I have signed the CLA as individual contributor.

Was it because an additional change to /etc/fstab is needed?
Found an Ansible example in https://github.com/kubernetes/website/blob/main/content/en/blog/_posts/2019-03-15-Kubernetes-setup-using-Ansible-and-Vagrant.md#step-22-kubelet-will-not-start-if-the-system-has-swap-enabled-so-we-are-disabling-swap-using-the-below-code

/lgtm

please squash your pr into a single commit

please squash your pr into a single commit

commits have been squashed

/approve

/lgtm

authors: T-Lakshmi lichao127 mengjiao-liu tengqm


text:
[zh-cn]sync manage-resources-containers secret pod-security-standards

M       content/zh-cn/docs/concepts/configuration/manage-resources-containers.md
M       content/zh-cn/docs/concepts/configuration/secret.md
M       content/zh-cn/docs/concepts/security/pod-security-standards.md

/lgtm


text:
SCSS changes to make the docs homepage cards look consistent

Closes #23914
This PR separates the (S)CSS changes from #43164

/area web-development

For finishing touch, few things that are coming to my mind:-

(3rd row, 3rd column) Card/Tile's hyperlink text can be changed to "Documentation versions" and it can be turned into a blue button, as it's looking a little odd that only this card doesn't have any button like others.
(3rd row, 3rd column) Card/Tile's heading can be changed to "Available Docs", as in smaller devices like mobile, that "documentation" word is looking like :-
documentat
ion
At some cards there is some gap between blue button and hyperlinks, maybe by adding some relevant hyperlinks related to that card/tile.. this space can be filled.

@aj11anuj, I appreciate the time taken for the review :)
So regarding the 'Documentation word wrap' which you addressed in the second pointer, We need not change the front matter for that as CSS should adapt to html and not the other way around. I'll just reduce the padding which will render the text properly on most viewports
I'm afraid that the first and the third issues can't be addressed with this PR, As they need some changes over the homepage index . I'd be happy to see a follow-up PR from your end to propose these changes

I don't think the blue card background improves things
The page would look better with whitespace above the buttons

Ideal outcome: also use flexbox and a variable layout so that there are fewer columns - maybe just 1 - on a narrow, mobile-device viewport.

I recommend against making content change in this PR. Style changes should work for the content we have, which is in 13(ish) localizations, and ideally for the content we might have in the future. Pages can get reworded etc.

I get your point @sftim, I've removed the background and focused more on the alignments in the recent push. The page would work just fine on most viewports now

/hold I'd like to try out some ideas

/unhold
Good for review now

I'll change the title of this PR as this is no longer limited to SCSS , Since there are some markup changes as well

authors: Gauravpadam aj11anuj dipesh-rawat sftim


text:
[zh-cn] Update /kubeadm_init/_index.md, add kubeadm_init execute …

add kubeadm_init execute phases

/lgtm

To avoid Markdown in short commit messages:
/retitle [zh-cn] Update /kubeadm_init/_index.md, add kubeadm_init execute…

/approve

authors: mavk sftim tengqm xichengliudui


text:
KEP 4317: Pod Certificates

Doc updates for KEP-4317 (Pod Certificates)

KEP-4317

/sig auth

Hello @ahmedtd :wave: please take a look at Documenting for a release - PR Ready for Review to get your PR ready for review before Tuesday November 19th 2024 18:00 PST. Thank you!

authors: ahmedtd dipesh-rawat spurin


text:
update federation control plane turn down command

kubectl uses --context option for specifying the context, the option --host-cluster-context is for kubefed join.

This change is

@c6h3un need check why the CLA validation failed.

@tengqm Sorry that I pushed with wrong name and email before, I removed those commits.

/approve

authors: c6h3un heckj tengqm


text:
fix the command output

I have verified on version v1.11

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please delete this note before submitting the pull request.
For 1.12 Features: set Milestone to 1.12 and Base Branch to release-1.12
Help editing and submitting pull requests:  https://deploy-preview-9510--kubernetes-io-master-staging.netlify.com/docs/contribute/start/#submit-a-pull-request.
Help choosing which branch to use, see
https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

/lgtm
/approve

authors: chenopis tanshanshan


text:
fix: All missing link is attached

Changes proposed
All missing link is attached by this fix

@AvineshTripathi please have a look
__
  Summary: :hammer_and_wrench: This code needs a fix

@AvineshTripathi done!
__
  Summary: :ok_hand: This code looks good

repo: kubesimplify/website

license: MIT


text:
fix(): revert alpine version

Description

Fixes #
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Checklist:

[ ] The title of the PR states what changed and the related issues number (used for the release note).
[ ] Does this PR requires documentation updates?
[ ] I've updated documentation as required by this PR.
[ ] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have tested it for all user roles.
[ ] I have added all the required unit test cases.

Does this PR introduce a breaking change for other components like kubeslice-controller, worker-operator?

repo: kubeslice/gateway-certs-generator


text:
[FluxCD Integration] Add FluxCD Multi-Cluster Application Management

Add fluxcd/multi-cluster-controller to give Kubesphere the functionality of Multi-Cluster Application Management by filling out the kubeconfig section.
Here is a design of Multi-Cluster HelmRelease Architecture.

/kind feature

repo: kubesphere/ks-devops


text:
:soap: Move inline hooks to utils

Move inline hooks to utils

@yaacov Does this change the look and feel of the UI? i don't think so, just want to check.

authors: RichardHoch yaacov


text:
Fix: legacy backend state reading and GC

For now if restart controller with --controller-namespace. The configuration state will become GeneratingTerraformOutputs and stuck. This is because controller can't got the legacy backend.
Fix that Configuration.Spec.Backend will be overwritten if set --controller-namespace. Instead, now controller
only overwrite Configuration.Spec.Backend  when no backend specified.
Signed-off-by: Qiaozp qiaozhongpei.qzp@alibaba-inc.com

Shoule we add some e2e tests for the "restart controller with --controller-namespace" cases?

If a user applies a Configuration without spec.Backend, then the terraform apply job will use the default kubernetes backend whose secret is {Namespace: ${env.TERRAFORM_BACKEND_NAMESPACE} || ${configuration.Namespace}, Name: tfstate-default-${confguration.Name}}.
Then, the user restarts the controller with --controller-namespace. In this case, the terraform apply job will use the default kubernetes backend whose secret is {Namespace: ${env.TERRAFORM_BACKEND_NAMESPACE} || ${configuration.Namespace}, Name: tfstate-default-${confguration.UID}}.
The two backend secrets are in the same namespace but have different names. Will this cause an error?

There are duplications.  But it's OK.

New secret won't be used. It is created for simplicity (No need for extra logic).
They will be both deleted when calling  backend.Cleanup.

authors: chivalryq loheagn

repo: kubevela/terraform-controller


text:
CNV-42470: Fix link of owner

📝 Description
Fix owner resource link
🎥 Demo
Before:

After:

/cherry-pick release-4.16

authors: gouyang metalice

repo: kubevirt-ui/kubevirt-plugin


text:
IO policy is overwritten to thread for virtio-scsi

What happened:
The IO policy for scsi disk is always set to thread
What you expected to happen:
Be able to set the IO policy independently from the iothreads
How to reproduce it (as minimally and precisely as possible):
Steps to reproduce the behavior.
Start a VM with a disk with this configuration:
  domain:
    ioThreadsPolicy: auto
    devices:
      disks:
      - disk:
          bus: scsi
        name: containerdisk
        io: native

and verify the yaml:
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none' error_policy='stop' io='threads' discard='unmap'/>
      <source file='/var/run/kubevirt-ephemeral-disks/disk-data/containerdisk/disk.qcow2' index='2'/>
      <backingStore type='file' index='3'>
        <format type='qcow2'/>
        <source file='/var/run/kubevirt/container-disks/disk_0.img'/>
      </backingStore>
      <target dev='sda' bus='scsi'/>
      <alias name='ua-containerdisk'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

/assign

repo: kubevirt/kubevirt


text:
Add alert for high memory utilization

Signed-off-by: Andrey Odarenko andreyo@il.ibm.com

What this PR does / why we need it:
This PR introduces new Prometheus alert that will fire when container that runs a VM is close to it's memory limit and close to a risky state of getting killed by runtime. Alert is firing when memory utilization is 20MB close to the memory limit.
Which issue(s) this PR fixes:
Special notes for your reviewer:
Release note:

NONE

/hold

/unhold

Would it be feasible to add a unit test for that?
I see there's already a crds_test.go.

The function NewPrometheusRuleCR is covered in kubevirt_test.go and the new rule is validated and tested in hack/prom-rule-ci/prom-rules-tests.yaml.  Not sure it's feasible to add a unit test for specific rule.

/retest

@andreyod Jira issues are not accessible to anyone outside of RH/IBM - we should only mention publicly accessible links.

@andreyod The alert rule name it doesn't comply with the alert names and should be with a kubevirt_ prefix.
kubevirt_vmi_high_memory_usage or kubevirt_vm_high_memory_usage
There is a PR in progress for adding the kubevirt_ prefix to the other alert rules: https://github.com/kubevirt/kubevirt/pull/4636

/retest

/lgtm

/retest

/retest

/retest

/retest

/retest

/approve

authors: andreyod jean-edouard sradco vladikr


text:
fix racy check in test 5257

What this PR does / why we need it:
This PR fixes a race that can cause test 5257 to fail like in run: https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/6133/pull-kubevirt-e2e-k8s-1.21-sig-storage/1420271384948379648
The test might fail to update the vm spec because vm spec
cant be updated during vmsnapshot. The BeforeTest creates the snapshot and waits
for it to be ready and then updates the vm spec to running, but the create snapshot
function doesnt wait for the SnapshotInProgress in the vm status to be
changed back to nil and so the vm update fails.
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

/lgtm
/approve


text:
Jenkinsfile: Switch to dynamic library fetching and drop branch

Instead of having the library hardcoded to Jenkins master, we can fetch
it dynamically. We also drop the usage of library branches since it does
not make sense to maintain such a thing in the CI. The master branch
should be able to handle both development and release branches.

@MalloZup @ereslibre any clue what the travis error is? i do not think it's related to the PR

@hwoarang Looks like a flake.

i ddin't check it :robot:

authors: MalloZup ereslibre hwoarang

repo: kubic-project/velum


text:
Unhandled Rejection when .jscpd folder is missing on macOS

Describe the bug
I have exactly the same issue as described in #204
(node:9785) UnhandledPromiseRejectionWarning: Error: ENOTDIR: not a directory, unlink '.jscpd/statistic'
    at Object.unlinkSync (fs.js:951:3)
    at Function.rimrafSync [as sync] (/Users/me/project/node_modules/rimraf/rimraf.js:306:17)
    at new LevelDbStore (/Users/me/project/node_modules/jscpd/build/stores/leveldb.js:13:30)
    at StoreManager.create (/Users/me/project/node_modules/jscpd/build/stores/stores-manager.js:98:33)
    at StoreManager.getStore (/Users/me/project/node_modules/jscpd/build/stores/stores-manager.js:75:18)
    at StatisticListener.saveStatistic (/Users/me/project/node_modules/jscpd/build/listeners/statistic.js:83:56)
    at StatisticListener.matchSource (/Users/me/project/node_modules/jscpd/build/listeners/statistic.js:80:14)
    at JscpdEventEmitter.emit (/Users/me/project/node_modules/eventemitter3/index.js:181:35)
    at /Users/me/project/node_modules/jscpd/build/jscpd.js:313:48
    at Array.map (<anonymous>)

To Reproduce

Create a completely new project
Run jscpd src (or jscpd .)

Expected behavior
I would expect to not see a unhandled rejection warning and that the program exists with exit code 1.
Desktop (please complete the following information):

OS: macOS
OS Version: 10.14.4
NodeJS Version: 10
jscpd version: 2.0.13

I close this because I named the configuration file .jscpd instead of .jscpd.json 🙄 Now it works 👍

repo: kucherenko/jscpd

license: mit


text:
Cassandra Grafana dashboard link broken

Link to Grafana dashboard yields 404.
Line 74 - https://github.com/kudobuilder/operators/blob/master/repository/cassandra/3.11/docs/monitoring.md

This would ideally be fixed in the KUDO C* create_operators_pull_request.py script.

(The link works there: https://github.com/mesosphere/kudo-cassandra-operator/tree/master/monitoring/grafana)

added the fix here https://github.com/mesosphere/kudo-cassandra-operator/pull/141

this is fixed now https://github.com/kudobuilder/operators/blob/master/repository/cassandra/3.11/docs/monitoring.md#2-install-the-grafana-dashboard

authors: mpereira tbaums zmalik

repo: kudobuilder/operators


text:
Memory leak

When working on https://github.com/Leafwing-Studios/Emergence/pull/613, I encountered a memory leak, which ultimately led to a panic due to my GPU running out of memory.
This was the commit in question: https://github.com/Leafwing-Studios/Emergence/pull/613/commits/0f60c50a763f7d511e250f59a323ececaad6381d
Here's what my system monitor looked like, before and after toggling on the billboarded text via the F2 key.

The drop is when the game crashed 😅
I'm using this in a simple immediate mode way for now, as seen here, but I am being careful to reuse assets and despawn my entities each frame.

I was afraid of the possibility this would happen 😅

authors: alice-i-cecile kulkalkul


text:
[New game]: The labyrinth of death

🎮 Game Request
Game logic and basic description
You are Isaac Newton and you are searching for it in the underworld. Defeat Hades and claim it!
Use WASD to move, Space for the sword (if you collected it) and Shift to switch to boomerang boomerang (once you collect it) and WASD to control it.
Screenshort:

Point down the features
Demo Vedio:
https://github.com/kunjgit/GameZone/assets/98798977/11278da1-3488-4d63-90a2-0da1853d1b3a
Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

/assign

Hey @Durgesh4993 !
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🕹

Hey @Durgesh4993 ! 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! 😇

repo: kunjgit/GameZone


text:
Pac-Man-Game finished

PR Description 📜
The Pac-Man Game was very limited so I finished it into a more rounded out and finished game.
-Improved the map
-Added portals
-Added a third ghost
-Ghosts start moving on different times
-Added power pellets
-Added ghosts getting scared
-Added ghosts getting eaten
-Added fruit
-Added bonus points
-Added animations with gifs
-Added sound effects
-Added startscreen
-Added restart buttons
-Added instructions
Fixes #5183

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 GameZone's README.md
[x] I have added README.md in my Game folder
[x] I have specified the respective issue number for which I have requested the new game.
[x] I have added my Game to gamesData.json file and it is loading properly on main website as intended.

Thank you soo much for contributing to our repository 💗

Thank you @aamira0 ,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! 😀


text:
read API credentials from .env file

Hi Walid R. Rashed,
I hope this message finds you well. I noticed that the clientId and clientSecret were hard-coded, which could potentially pose a security risk. To address this issue, I made some changes to the code by adding a constructor to read these values from a .env file instead.
Specifically, I did the following:

Imported the dotenv and fs modules
Added the dotenv.config() method to read the environment variables
Replaced the hard-coded clientId with process.env.CLIENT_ID
Read the clientSecret from the .env file using fs.readFileSync()

However, because I do not have an API client and client secret, I was unable to test these changes. Please let me know if you have any feedback or concerns about the updated code.
Thank you for your time and attention.
Best regards,
Hoshmand

Hi @hoshmandctf
Thank you for your contribution!
This approach of yours has some drawbacks, here is why:

Since this is an npm package, your commits take effect on the package level, not the application, by doing this, you'r forcing the developers to use the environment variables and not giving them any other options.
If we go with your approach of getting client_secret and cleint_id directly inside the constructor from the ENV, this will also be a development flexibility issue, because in multi-tenant applications architectures, the developers cant initialize different instances by using different client_id and client_secret

From the README file's documentation, you can see that initializing the Fib instance and authenticating it can be very flexible and developers can use Env files or any other approaches and keep their credentials safe, for example:

// you can get the cleint_secret and client_id values any way you want.
const clientId = process.env.CLEINT_ID
const clientSecret = process.env.CLEINT_SECRET

import { Fib } from 'fib-sdk';
const fib = new Fib( clientId, clientSecret);

So by understanding the above example, I believe this will cover all of your worries.
Regards,

Hi @kurdi-dev,
Thank you for your prompt response and for sharing your concerns about my proposed changes. I appreciate your attention to detail and your commitment to maintaining the flexibility and security of the package.
After considering your feedback, I understand that my approach of getting the client_id and client_secret directly inside the constructor from the environment variables could limit the flexibility of the package and cause issues in multi-tenant applications.
I agree that developers should have the freedom to choose how they want to manage their credentials and that the current approach of initializing the Fib instance and authenticating it using environment variables or any other method is more flexible and secure.
Best regards,
Hoshmand

Thank you for your understanding!
I will close this pr now.

authors: hoshmandctf kurdi-dev

repo: kurdi-dev/fib-sdk


text:
Legend boxes don't reflect the gradient

Feature Proposal
As I have seen in my lib, when you use  gradients, the gradients are not reflected in the legend.
To be precise, the gradient is applied to the legend but due to the gradient size is limited to the scales, the legend are out side of the gradient and then the canvas use the color related to the position.
See example in codepen: https://codepen.io/stockinail/pen/xxpENVM
As you can see the legend is using the red color because is the color from the gradient for legend position.
The same is for polarArea (using the radial gradient) where all legend items are colored with the color of the gradient.

The proposal is to reflect on the legend the gradient.
Possible Implementation
I see only 1 option, creating a generateLabels callback in the plugin to set to the chart in order to create a specific gradient (with dimension of the legend box).
For polarArea, the generateLabels callback could return the color at the data index, calculating the last color for the data index. For this, I have got already a code (even if is written in Java) that it can be translated and used.

Forgot to write that if the user set own generateLabels callback, the callback of the plugin should wrap it, invoking it and changes only the fillStyle and strokeStyle.

It would be great if the legend plugin would resolve the colors with a different context, so a different gradient could be returned based on that. But it does not, so your suggestion might be the only option.

But it does not, so your suggestion might be the only option.

yeah, at he moment it sounds so. I know in CHART.JS v4 there is the plan to re-write legend plugin... in version 4!
Just FYI, I'm creating a prototype. I'll show it to you soon.

In advance, to do that I think we need to map more hooks of plugin (i.e. to set the callback) and also leverage on chart states map (as done in plugin annotation).

@kurkle FYI, generateLabels callback is not the right direction because, when invoked, the legendItems size is not calulcated yet. I've found another way.

Do you think the support to version 2.x is still needed also for this enhancement?

authors: kurkle stockiNail

repo: kurkle/chartjs-plugin-gradient


text:
fix: ImageBuildSpec build_file feature

Description

This PR #2223 introduced build_file in ImageBuildSpec but didn't test if it worked on a real example (my bad)... I tried to use the feature yesterday and it didn't work so I revisited my changes and made sure it works now!
To achieve that, I introduced a new Dockerfile called test.Dockerfile in internal_testsuites/starlark/image-build-package and added a new service that relies on this image.
$ ktdebug run --enclave test internal_testsuites/starlark/image-build-package
WARN[2024-03-14T12:21:29+01:00] An error occurred getting the running engine's version; you may be running an out-of-date engine version
WARN[2024-03-14T12:21:29+01:00] We expected the running engine version to match format X.Y.Z, but instead got '921ba9'; this means that we can't verify the API library and engine versions match so you may encounter runtime errors
INFO[2024-03-14T12:21:30+01:00] Executing Starlark package at '/Users/leovct/Documents/opensource/kurtosis/internal_testsuites/starlark/image-build-package' as the passed argument 'internal_testsuites/starlark/image-build-package' looks like a directory
INFO[2024-03-14T12:21:30+01:00] Compressing package 'github.com/kurtosis-tech/kurtosis/internal_testsuites/starlark/image-build-package' at 'internal_testsuites/starlark/image-build-package' for upload
INFO[2024-03-14T12:21:30+01:00] Uploading and executing package 'github.com/kurtosis-tech/kurtosis/internal_testsuites/starlark/image-build-package'

Adding service with name 'service-1' and image 'kurtosistech/service'
SKIPPED - This instruction has already been run in this enclave

Adding service with name 'service-2' and image 'kurtosistech/service'
SKIPPED - This instruction has already been run in this enclave

Starlark code successfully run. No output was returned.

Made with Kurtosis - https://kurtosis.com
Name:            test
UUID:            1942191df821
Status:          RUNNING
Creation Time:   Thu, 14 Mar 2024 12:02:31 CET
Flags:

========================================= Files Artifacts =========================================
UUID   Name

========================================== User Services ==========================================
UUID           Name        Ports    Status
1b5ec55bc742   service-1   <none>   STOPPED
38dafa01e996   service-2   <none>   STOPPED

Is this change user facing?
YES

References (if applicable)

tagging @mieubrisse @tedim52 for review :)

Hey @leovct , is there any chance you can force undo the most recent merge commit and then merge again? (That should fix the git guardian issue)

Hey @leovct , is there any chance you can force undo the most recent merge commit and then merge again? (That should fix the git guardian issue)Then we can get this merged!

Looks like it introduced a bunch of breaking changes, I'll review that on Monday :) Have a great week-end!

@leovct ah okay, I'll fix that on a separate branch

repo: kurtosis-tech/kurtosis


text:
Fix USERPROFILE access conflicts in Windows CI

Some tests have been failing when multiple jobs are trying to read/write to the same extension file. E.g. https://github.com/kuzudb/kuzu/actions/runs/8853455160/job/24314357568?pr=3387
The path of that file is derived from ClientConfig.homeDirectory, which is set using the USERPROFILE environment variable on Windows. This overrides that in CI to refer to a directory unique to the CI job.

Closing for now. This hasn't actually been showing up recently.

Still an issue: https://github.com/kuzudb/kuzu/actions/runs/9522563438/job/26252460308?pr=3642

If we do #3196, each CI runner will be isolated, so it should no longer be a problem.

If we do https://github.com/kuzudb/kuzu/issues/3196, each CI runner will be isolated, so it should no longer be a problem.

That's true. I guess since this hasn't been a huge issue I'll just close this again in favour of that solution.

authors: benjaminwinger mewim

repo: kuzudb/kuzu