text:
Fix tensor device mismatch on huggingfaceserver on text_embedding

What this PR does / why we need it:
This PR solves an issue while using GPU on huggingfaceserver for the task text_embedding.
We encountered an error RuntimeError : Expected all tensors to be on the same device, but found at least two devices, cuda:0 and cpu!" when allocating a gpu to the InferenceService
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 #4050
Type of changes

[x] Bug fix (non-breaking change which fixes an issue)

Feature/Issue validation/testing:
Please describe the tests that you ran to verify your changes and relevant result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

[x] Build a new image for huggingfaceserver
[x] Specify the new image in the InferenceService at the path spec.predictor.model.image with spec.predictor.model.args set to --task=text_embedding and --device_map=cuda

Special notes for your reviewer:

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

Checklist:

[ ] Have you added unit/e2e tests that prove your fix is effective or that this feature works?
[ ] Has code been commented, particularly in hard-to-understand areas?
[ ] Have you made corresponding changes to the documentation?

Release note:

Fix tensor device mismatch for huggingfaceserver on text_embedding

Re-running failed tests

/rerun-all - rerun all failed workflows.
/rerun-workflow <workflow name> - rerun a specific failed workflow. Only one workflow name can be specified. Multiple /rerun-workflow commands are allowed per comment.

I think this is already fixed in https://github.com/kserve/kserve/pull/4055
cc @Datta0

authors: Haibread yuzisun


text:
分享个脚本，导出单个离线HTML文件，不是用build

| node --version | 10.16   |
| npm --version  | 6.9       |
| nodeppt -v       | 2.1.5     |
| macOS Sierra      | 10.12.3 |
nodepptStandalone.py.zip
之前同事写的，先serve，然后用爬虫全部抓下来转格式，完美生成单独的HTML文件。
简单运行方式，解压，把nodepptStandalone.py放到md文件所在目录，命令行进入目录运行：
python3 ./nodepptStandalone.py  xxxxx.md

这个没有这么麻烦。。。为啥不用 build。。

谢谢，是为了当做ppt对外分享。。。之前试过直接用build，效果没问题，但build出来会有几个文件，如果通过手机或email分享出去直接播放的话稍显麻烦。

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
无法播放rtmp直播流，好像ssl证书不行

类型  	描述
SDK名称	KSYMediaPlayer_iOS
SDK版本	3.0.4.0
设备型号	iphone6s
OS版本	iOS 13.3
问题描述	无法播放rtmp直播流：
操作描述	正常地把一个rtmp直播的地址，放到播放器里播，个别无问题，但是个别就会播放不了。
额外附件，报错信息如下：好像是ssl证书不行。
Task .<1> finished with error [-1200] Error Domain=NSURLErrorDomain Code=-1200 "发生了SSL错误，无法建立与该服务器的安全连接。" UserInfo={_kCFStreamErrorCodeKey=-9816, NSLocalizedRecoverySuggestion=您仍要连接此服务器吗？, NSUnderlyingError=0x283b46ac0 {Error Domain=kCFErrorDomainCFNetwork Code=-1200 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, _kCFNetworkCFStreamSSLErrorOriginalValue=-9816, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816}}, NSLocalizedDescription=发生了SSL错误，无法建立与该服务器的安全连接。, NSErrorFailingURLKey=https://videodev.ksyun.com:8443/univ/monitorclient?accesskey=D8uDWZ88ZKUCPu0KRJkR&expire=1592471700&contmd5=4d660709de55dedbd5bee3a9a67dcb9e&uniqname=ksyPlayer_iOS&signature=NwhmuyI%2Biv%2BGdhxDpFc9FZMpUYA%3D, NSErrorFailingURLStringKey=https://videodev.ksyun.com:8443/univ/monitorclient?accesskey=D8uDWZ88ZKUCPu0KRJkR&expire=1592471700&contmd5=4d660709de55dedbd5bee3a9a67dcb9e&uniqname=ksyPlayer_iOS&signature=NwhmuyI%2Biv%2BGdhxDpFc9FZMpUYA%3D, _kCFStreamErrorDomainKey=3}

Is this now fixed? please help me I am stack on this

license_source: bigquery


text:
Link for TF 2398

Smart seek costing is discussed here: https://dba.stackexchange.com/a/149933/32281

Thanks, updated via https://github.com/ktaranov/sqlserver-kit/commit/684c1a71227763492124d9516621266b7eefc6bd

authors: erikdarlingdata ktaranov

repo: ktaranov/sqlserver-kit

license: mit


text:
Add per-iteration best-fit result reporting

I wondered if you’d have any suggestions as to how to report the best guess at each iteration of the fitting loop for your NelderMead implementation? I'm interested for the purpose of investigating how our solution space is being explored but simply reporting simplex_points.row(0) (from my understanding that is the current lowest-error guess?) does not appear to yield the same results that are returned for the final iteration at the end of the method.
How easy would a feature that enables this diagnostic ability be to implement?

Should be simple to implement. Would you like an iteration-by-iteration print of the minimum value of the objective function?

Exactly; for the minimum objective, if we could call a method to report:

Iteration number
The error from the objective function
The inputs to the objective function that give that error value

I just pushed a rough implementation of function tracing. You can use
settings.verbose_print_level

to set the level of detail.

settings.verbose_print_level = 0: default (no print)
settings.verbose_print_level = 1 print iteration number, current optimal value of the objective function and corresponding vertex
settings.verbose_print_level = 2 print iteration number, current optimal value of the objective function, objective function values for all vertices, and the full vertex matrix.

authors: joncage kthohr

repo: kthohr/optim


text:
My blog can't not load disqus.

I config my disqus shortname but, Disqus is not loaded.

Thanks for PR!
Sorry for the delay in approving.

The identifier can not be static.
The vue-disqus plugin already automatically picks up the current route.
https://github.com/ktquez/vue-disqus/blob/master/src/vue-disqus.vue#L76

Ah, Thank you.

authors: CheolHoJung ktquez

repo: ktquez/vuepress-theme-ktquez


text:
fix(monitor): set actual process name in logs instead of symlinks

We resolved actual process names in and stored it in the userspace process map, but we never updated the log base created in kprobe event.
This PR removes the null check and updates the log base with actual process names in the kretprobe event which we would have recieved from the bprm hook which was triggered before kretprobe execve(at)
Purpose of PR?:
Fixes #984
Does this PR introduce a breaking change?
No
If the changes in this PR are manually verified, list down the scenarios covered::
Check Telemetry Info using kArmor logs
Additional information for reviewer? :
Mention if this PR is part of any design or a continuation of previous PRs
Checklist:

[ ] Bug fix. Fixes #984
[ ] 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

{"Timestamp":1685455502,"UpdatedTime":"2023-05-30T14:05:02.615298Z","NamespaceName":"container_namespace","PodName":"armored-container","ContainerID":"ce0e9a12750f6e26dc8e8481be8ef26035608d02bd2b27385ca47e6e11bdb651","ContainerName":"armored-container","ParentProcessName":"/bin/busybox","ProcessName":"/bin/busybox","HostPPID":59047,"HostPID":96816,"PPID":1,"PID":19,"Type":"ContainerLog","Source":"/bin/busybox","Operation":"Process","Resource":"/bin/cat file.txt","Data":"syscall=SYS_EXECVE","Result":"Passed"}

source: gharchive/pull-request

repo: kubearmor/KubeArmor


text:
ci: adjust e2e workflow

Signed-off-by: moweiwei mo.weiwei@99cloud.net

What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for reviewers:

Does this PR introduced a user-facing change?

Additional documentation, usage docs, etc.:

Codecov Report

Merging #286 (04576de) into release-1.3 (e7da2f0) will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           release-1.3     #286   +/-   ##
============================================
  Coverage        46.20%   46.20%
============================================
  Files                7        7
  Lines              606      606
  Branches           171      171
============================================
  Hits               280      280
  Misses             252      252
  Partials            74       74

authors: codecov-commenter moweiwei

repo: kubeclipper/console


text:
Add phpmyadmin image version

Add latest version to phpMyAdmin image.

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

repo: kubedb/docs


text:
Assign resources for init containers

https://github.com/kubedb/project/issues/404#issuecomment-473733397

@shudipta , can you ensure if mysql init containers have this?

Already have this.

https://github.com/kubedb/mysql/blob/master/pkg/controller/statefulset.go#L115

authors: shudipta tamalsaha the-redback

repo: kubedb/project


text:
fix: pylint R0917 error

What type of PR is this?
/kind bug

What this PR does / why we need it:
Fix pylint error R0917 with python>=3.9
Which issue(s) this PR fixes:

Fixes #157

I resolve the issue #157 by setting max-positional-arguments to 10.
There are other potential solutions, but this one is the most practical. See the discussions in comment https://github.com/kubeedge/ianvs/issues/157#issuecomment-2421629846

This solution is the same as the one discussed in our meeting, and it solves the current problem well.

/lgtm

/lgtm

repo: kubeedge/ianvs


text:
Finalize KFServing v1beta1 core API

Based off proposal https://docs.google.com/document/d/1rV8kI_40oiv8jMhY_LwkkyKLdOwSI1Qda-Dc6Dgjz1g/edit#heading=h.x9snb54sjlu9

This has been accepted
/Close

authors: ellistarn yuzisun

repo: kubeflow/kfserving


text:
Fix 404s in _redirects

The following _redirects still 404:

/docs/pipelines/pipelines-samples/	   /docs/components/pipelines/build-pipeline/

I am not sure the best place to point this one, perhaps just /docs/components/pipelines/overview/

/docs/components/pipelines                     /docs/components/pipelines/pipelines

This is not a 404, but a redundant redirect, so let's remove it.

/docs/components/pipelines/caching                            /docs/components/pipelines/overview/caching

/docs/components/pipelines/caching-v2                         /docs/components/pipelines/overview/caching-v2

/docs/components/pipelines/multi-user                         /docs/components/pipelines/overview/multi-user

/docs/components/pipelines/pipeline-root                      /docs/components/pipelines/overview/pipeline-root

/docs/components/pipelines/pipelines-quickstart               /docs/components/pipelines/overview/quickstart

/docs/pipelines/concepts/*          /docs/components/pipelines/overview/concepts/:splat

This one will cause problems in the future, just update its target to /docs/components/pipelines/concepts (with no :spat)

/docs/pipelines/*                   /docs/components/pipelines/:splat

This one will cause problems in the future, just update its target to /docs/components/pipelines (with no :spat)

Contextualization: https://github.com/kubeflow/website/pull/3737#pullrequestreview-2111822549
Should be fixed after https://github.com/kubeflow/website/pull/3737 gets merged.
/area pipelines

Fixed in https://github.com/kubeflow/website/pull/3737#issuecomment-2166378964.

repo: kubeflow/website


text:
Added a guide to developing reusable components

Fixes https://github.com/kubeflow/website/issues/569

This change is

Preview:

https://deploy-preview-601--competent-brattain-de2d6d.netlify.com/docs/pipelines/sdk/component-development/
https://deploy-preview-601--competent-brattain-de2d6d.netlify.com/docs/pipelines/sdk/best-practices/

Note: I've moved the conceptual info about pipelines and components into a new Concepts section of the docs. See PR https://github.com/kubeflow/website/pull/600. I'll update the component dev guide to link to those concepts when that PR is merged.
Similarly, I'll add links to the component container spec doc when I've added that doc. (PR coming soon.)

This PR is now ready for review. Please note the questions that I sent by email, and comment on this PR with answers to those questions if necessary.
/assign @Ark-kun
/assign @abhi-g

/unassign @abhi-g
/assign @paveldournov

Thank you a lot, Sarah!
/lgtm
/approve

authors: Ark-kun sarahmaddox


text:
fix wrong proxy url

Issue Ref: None
Description: fixes error in document

sorry. it's my mistake.

repo: kubeless/kubeless


text:
Build broken because of some vendors missing

The build seems to be broken in some situations where some dependencies are outdated. This could be fixed by vendoring these dependencies.
I was getting these errors when trying to build cri-o:
$ make
go build -o ocid \
	-tags "selinux seccomp  " \
	github.com/kubernetes-incubator/cri-o/cmd/ocid
go build -o ocic github.com/kubernetes-incubator/cri-o/cmd/ocic
go build -o kpod github.com/kubernetes-incubator/cri-o/cmd/kpod
make -C conmon
make[1]: Entering directory '/home/alvaro/Development/cri-o/conmon'
make[1]: 'conmon' is up to date.
make[1]: Leaving directory '/home/alvaro/Development/cri-o/conmon'
make -C pause
make[1]: Entering directory '/home/alvaro/Development/cri-o/pause'
make[1]: 'pause' is up to date.
make[1]: Leaving directory '/home/alvaro/Development/cri-o/pause'
make -C test/bin2img BUILDTAGS="selinux seccomp  "
make[1]: Entering directory '/home/alvaro/Development/cri-o/test/bin2img'
make[1]: 'bin2img' is up to date.
make[1]: Leaving directory '/home/alvaro/Development/cri-o/test/bin2img'
make -C test/copyimg BUILDTAGS="selinux seccomp  "
make[1]: Entering directory '/home/alvaro/Development/cri-o/test/copyimg'
go build -tags "selinux seccomp  " -o copyimg
# github.com/containers/image/docker
../../../go/src/github.com/containers/image/docker/docker_client.go:119: undefined: tlsconfig.SystemCertPool
Makefile:2: recipe for target 'copyimg' failed
make[1]: *** [copyimg] Error 2
make[1]: Leaving directory '/home/alvaro/Development/cri-o/test/copyimg'
Makefile:55: recipe for target 'copyimg' failed
make: *** [copyimg] Error 2

Then I fixed it with:
$ cd $GOPATH/src/github.com/containers/image/
$ git pull
remote: Counting objects: 151, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 151 (delta 72), reused 72 (delta 72), pack-reused 71
Receiving objects: 100% (151/151), 63.87 KiB | 0 bytes/s, done.
Resolving deltas: 100% (80/80), completed with 41 local objects.
From https://github.com/containers/image
   4f14180..1d7e25b  master     -> origin/master
Updating 4f14180..1d7e25b
Fast-forward
 .gitignore                                                             |   2 ++
 .travis.yml                                                            |   3 +--
 Makefile                                                               |  40 ++++++++++++++++++++++++++--------------
 README.md                                                              |  31 ++++++++++++++++++++++++++-----
 copy/copy.go                                                           |  72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------
 copy/copy_test.go                                                      |   9 +++++----
 copy/fixtures/Hello.bz2                                                | Bin 43 -> 40 bytes
 copy/fixtures/Hello.gz                                                 | Bin 25 -> 39 bytes
 copy/fixtures/Hello.uncompressed                                       |   2 +-
...

@inercia I just built master in a new go root and it builds fine for me.
[root@dhcp-16-129 ~]# mkdir go
[root@dhcp-16-129 ~]# export GOPATH=~/go
[root@dhcp-16-129 ~]# mkdir -p /root/go/src/github.com/kubernetes-incubator/
[root@dhcp-16-129 ~]# cd /root/go/src/github.com/kubernetes-incubator/
[root@dhcp-16-129 kubernetes-incubator]# ls
[root@dhcp-16-129 kubernetes-incubator]# git clone git@github.com:kubernetes-incubator/cri-o.git
Cloning into 'cri-o'...
Enter passphrase for key '/root/.ssh/id_rsa':
remote: Counting objects: 26780, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 26780 (delta 0), reused 0 (delta 0), pack-reused 26772
Receiving objects: 100% (26780/26780), 26.57 MiB | 3.84 MiB/s, done.
Resolving deltas: 100% (11541/11541), done.
[root@dhcp-16-129 kubernetes-incubator]# cd cri-o/
[root@dhcp-16-129 cri-o]# echo $GOPATH
/root/go
[root@dhcp-16-129 cri-o]# make
go build -o ocid \
        -tags "selinux seccomp  " \
        github.com/kubernetes-incubator/cri-o/cmd/ocid
go build -o ocic github.com/kubernetes-incubator/cri-o/cmd/ocic
go build -o kpod github.com/kubernetes-incubator/cri-o/cmd/kpod
make -C conmon
make[1]: Entering directory '/root/go/src/github.com/kubernetes-incubator/cri-o/conmon'
cc -Wall -Wextra -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include    -c -o conmon.o conmon.c
cc -o conmon conmon.o -Wall -Wextra -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include  -lglib-2.0
make[1]: Leaving directory '/root/go/src/github.com/kubernetes-incubator/cri-o/conmon'
make -C pause
make[1]: Entering directory '/root/go/src/github.com/kubernetes-incubator/cri-o/pause'
cc -Os -Wall -Wextra -static   -c -o pause.o pause.c
cc -o pause pause.o -Os -Wall -Wextra -static
strip pause
make[1]: Leaving directory '/root/go/src/github.com/kubernetes-incubator/cri-o/pause'
make -C test/bin2img BUILDTAGS="selinux seccomp  "
make[1]: Entering directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/bin2img'
go build -tags "selinux seccomp  " -o bin2img
make[1]: Leaving directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/bin2img'
make -C test/copyimg BUILDTAGS="selinux seccomp  "
make[1]: Entering directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/copyimg'
go build -tags "selinux seccomp  " -o copyimg
make[1]: Leaving directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/copyimg'
make -C test/checkseccomp
make[1]: Entering directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/checkseccomp'
go build -o checkseccomp
make[1]: Leaving directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/checkseccomp'
./ocid --config="" config --default > ocid.conf
go-md2man -in docs/ocid.conf.5.md -out docs/ocid.conf.5.tmp && touch docs/ocid.conf.5.tmp && mv docs/ocid.conf.5.tmp docs/ocid.conf.5
go-md2man -in docs/kpod.1.md -out docs/kpod.1.tmp && touch docs/kpod.1.tmp && mv docs/kpod.1.tmp docs/kpod.1
go-md2man -in docs/kpod-launch.1.md -out docs/kpod-launch.1.tmp && touch docs/kpod-launch.1.tmp && mv docs/kpod-launch.1.tmp docs/kpod-launch.1
go-md2man -in docs/ocid.8.md -out docs/ocid.8.tmp && touch docs/ocid.8.tmp && mv docs/ocid.8.tmp docs/ocid.8

@mrunalp That's because you have a recent version of github.com/containers/image. Maybe I should have used a different title for this issue, but I mean that the build if broken if you do not have the right version of github.com/containers/image in your GOPATH.

@inercia My $GOPATH doesn't have anything besides the cri-o repo. It is only using the vendored dependencies.
[root@dhcp-16-129 cri-o]# ls -l /root/go/src/github.com/
total 4
drwxr-xr-x. 3 root root 4096 Mar 13 10:09 kubernetes-incubator
[root@dhcp-16-129 cri-o]# make
go build -o ocid \
        -tags "selinux seccomp  " \
        github.com/kubernetes-incubator/cri-o/cmd/ocid
go build -o ocic github.com/kubernetes-incubator/cri-o/cmd/ocic
go build -o kpod github.com/kubernetes-incubator/cri-o/cmd/kpod
make -C conmon
make[1]: Entering directory '/root/go/src/github.com/kubernetes-incubator/cri-o/conmon'
make[1]: 'conmon' is up to date.
make[1]: Leaving directory '/root/go/src/github.com/kubernetes-incubator/cri-o/conmon'
make -C pause
make[1]: Entering directory '/root/go/src/github.com/kubernetes-incubator/cri-o/pause'
make[1]: 'pause' is up to date.
make[1]: Leaving directory '/root/go/src/github.com/kubernetes-incubator/cri-o/pause'
make -C test/bin2img BUILDTAGS="selinux seccomp  "
make[1]: Entering directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/bin2img'
make[1]: 'bin2img' is up to date.
make[1]: Leaving directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/bin2img'
make -C test/copyimg BUILDTAGS="selinux seccomp  "
make[1]: Entering directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/copyimg'
make[1]: 'copyimg' is up to date.
make[1]: Leaving directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/copyimg'
make -C test/checkseccomp
make[1]: Entering directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/checkseccomp'
make[1]: 'checkseccomp' is up to date.
make[1]: Leaving directory '/root/go/src/github.com/kubernetes-incubator/cri-o/test/checkseccomp'
./ocid --config="" config --default > ocid.conf
go-md2man -in docs/ocid.conf.5.md -out docs/ocid.conf.5.tmp && touch docs/ocid.conf.5.tmp && mv docs/ocid.conf.5.tmp docs/ocid.conf.5
go-md2man -in docs/kpod.1.md -out docs/kpod.1.tmp && touch docs/kpod.1.tmp && mv docs/kpod.1.tmp docs/kpod.1
go-md2man -in docs/kpod-launch.1.md -out docs/kpod-launch.1.tmp && touch docs/kpod-launch.1.tmp && mv docs/kpod-launch.1.tmp docs/kpod-launch.1
go-md2man -in docs/ocid.8.md -out docs/ocid.8.tmp && touch docs/ocid.8.tmp && mv docs/ocid.8.tmp docs/ocid.8

@inercia What version of Go are you building with? Just want to make sure it supports vendoring (1.6 or later). It should search for packages in our vendor/ directory before searching the GOPATH

@mrunalp It is strange but, if I remove containers/image from my GOPATH, things get worse:
$ rm -rf ~/Development/go/src/github.com/containers/image
$ make
go build -o ocid \
	-tags "selinux seccomp  " \
	github.com/kubernetes-incubator/cri-o/cmd/ocid
go build -o ocic github.com/kubernetes-incubator/cri-o/cmd/ocic
go build -o kpod github.com/kubernetes-incubator/cri-o/cmd/kpod
make -C conmon
make[1]: Entering directory '/home/alvaro/Development/cri-o/conmon'
make[1]: 'conmon' is up to date.
make[1]: Leaving directory '/home/alvaro/Development/cri-o/conmon'
make -C pause
make[1]: Entering directory '/home/alvaro/Development/cri-o/pause'
make[1]: 'pause' is up to date.
make[1]: Leaving directory '/home/alvaro/Development/cri-o/pause'
make -C test/bin2img BUILDTAGS="selinux seccomp  "
make[1]: Entering directory '/home/alvaro/Development/cri-o/test/bin2img'
make[1]: 'bin2img' is up to date.
make[1]: Leaving directory '/home/alvaro/Development/cri-o/test/bin2img'
make -C test/copyimg BUILDTAGS="selinux seccomp  "
make[1]: Entering directory '/home/alvaro/Development/cri-o/test/copyimg'
go build -tags "selinux seccomp  " -o copyimg
copyimg.go:7:2: cannot find package "github.com/containers/image/copy" in any of:
	/usr/lib64/go/src/github.com/containers/image/copy (from $GOROOT)
	/home/alvaro/Development/go/src/github.com/containers/image/copy (from $GOPATH)
copyimg.go:8:2: cannot find package "github.com/containers/image/signature" in any of:
	/usr/lib64/go/src/github.com/containers/image/signature (from $GOROOT)
	/home/alvaro/Development/go/src/github.com/containers/image/signature (from $GOPATH)
copyimg.go:9:2: cannot find package "github.com/containers/image/storage" in any of:
	/usr/lib64/go/src/github.com/containers/image/storage (from $GOROOT)
	/home/alvaro/Development/go/src/github.com/containers/image/storage (from $GOPATH)
copyimg.go:10:2: cannot find package "github.com/containers/image/transports" in any of:
	/usr/lib64/go/src/github.com/containers/image/transports (from $GOROOT)
	/home/alvaro/Development/go/src/github.com/containers/image/transports (from $GOPATH)
copyimg.go:11:2: cannot find package "github.com/containers/image/types" in any of:
	/usr/lib64/go/src/github.com/containers/image/types (from $GOROOT)
	/home/alvaro/Development/go/src/github.com/containers/image/types (from $GOPATH)
Makefile:2: recipe for target 'copyimg' failed
make[1]: *** [copyimg] Error 1
make[1]: Leaving directory '/home/alvaro/Development/cri-o/test/copyimg'
Makefile:55: recipe for target 'copyimg' failed
make: *** [copyimg] Error 2

And it is fixed again if I git clone github.com/containers/image in my GOPATH, and my Go compiler supports vendoring by default:
$ go version
go version go1.7 linux/amd64

It is strange because I have the vendor/github.com/containers/image in the cri-o repo...
Anyway, I'm closing this issue, because maybe this is not related to the vendoring.

authors: inercia jawnsy mrunalp

repo: kubernetes-incubator/cri-o


text:
fix flaky unit test in external-dns/provider

This unit test relies of the iteration order of the map. This is unreliable and prone to flakes as Go randomizes the iteration of maps.

/approve
/lgtm

Thanks @tariq1890

repo: kubernetes-incubator/external-dns


text:
Fixed kubectl path.

I have following error due to lack of "kubectl  replace.." path:
TASK [kubernetes/kubeadm : Update server field in kube-proxy kubeconfig] *********************************************************
Friday 13 July 2018  15:19:43 +0000 (0:00:00.511)       0:04:24.103 ***********
fatal: [master1 -> 10.0.0.11]: FAILED! => {"changed": true, "cmd": "/usr/local/bin/kubectl get configmap kube-proxy -n kube-system -o yaml | sed 's#server:.*#server:\\ https://127.0.0.1:6443#g' | kubectl replace -f -", "delta": "0:00:00.240920", "end": "2018-07-13 15:19:43.775695", "msg": "non-zero return code", "rc": 127, "start": "2018-07-13 15:19:43.534775", "stderr": "/bin/sh: kubectl: command not found\nsed: couldn't flush stdout: Broken pipe", "stderr_lines": ["/bin/sh: kubectl: command not found", "sed: couldn't flush stdout: Broken pipe"], "stdout": "", "stdout_lines": []}

kubectl should be absolute path.

I fixed my account informatino and Now CLA is enabled.  What should I do?

repo: kubernetes-incubator/kubespray


text:
Update for API doc generator [1.14]

Revised the config.yaml file for resource changes happened in 1.14.
This also adds the latest swagger.json from release-1.14 branch.
Resource (type) changes:

CSIDriver and CSINode added to storage.v1beta1 group;
VolumeAttachement graduated from storage.v1beta1 to v1;
InitializerConfiguration from admissionregistration.v1alpha1 was
dropped (kubernetes/kubernetes#72972);
PriorityClass graduated from scheduling.v1beta1 to scheduling.v1;
new resource auditregistraion.v1alpha1.AuditSink got added;
new resource coordination.v1.Lease got added;
new resource node.v1beta1.RuntimeClass got added;

/lgtm
/approve

/lgtm

authors: tengqm xiangpengzhao

repo: kubernetes-incubator/reference-docs


text:
Unify reconcileInstance and polling queues into a single queue.

Currently as per #717 the decision to use two separate queues was made as an interim solution, we should design a solution that uses a single queue, thereby ensuring that there can only be one outstanding request for a given Instance per controller.

Moving this to 0.1.0, since this is not yet done

I found a race in the integration test during #1017 that working this issue will fix.  It's possible for the polling queue and normal instance queue to begin working on the same instance at the same time, which typically results in one of the goroutines encountering conflict errors from the API server.  As a temporary workaround, we could add a mutex that prevents multiple goroutines from working on the same instance at the same time, but I don't think that's a good long-term fix - I don't want to block a goroutine while another one is working on an instance.  It's better to unify them into a single queue somehow.

authors: arschles pmorie vaikas-google

repo: kubernetes-incubator/service-catalog


text:
remove check for GUID regEx from plan externalid

The hashicorp/cf-vault-service-broker appends the plan name onto the GUID for the External ID using a period as the separator. The existing regEx validation does not allow for periods. The Pivotal docs do not specify an exact format and simply state using a GUID is recommended.
This change removes the regEx check in the api for Plan[].ExternalID so that any other brokers not following a strict GUID format will still work for k8s.

will this check to make sure its a non-empty string?

@duglin yes, there is a test case for that I needed to fix. It looked like there was a copy/paste error on it from the previous test case so it wasn't working. https://github.com/kubernetes-incubator/service-catalog/pull/1038/files#diff-ab3c2e82db881a2a48465940cbe38df7R124

great - thanks!! will review later today

can you change invalid serviceClass - missing guid to ... - missing id ?

couple of minor comments, otherwise it looks good.

@duglin Test references to guid have been switched to id for Plans[].ExternalID.

My concern about removing the regex is that we might need to tighten it in the future, which isn't backward-compatible.  I'd strongly prefer to just allow the period until we can get clarity on https://github.com/openservicebrokerapi/servicebroker/issues/118

that would be breaking change in the spec which means v3 - which would break lots of other things too

I think being spec compliant is more important right now

Adding do-not-merge based on discussion in the July 20, 2017 meeting to relax the regex to allow periods and seek clarity on aspects of the OSB spec.

Issue in OSB API: https://github.com/openservicebrokerapi/servicebroker/issues/273
Related issue: https://github.com/kubernetes-incubator/service-catalog/issues/802
Been thinking about this and there are two uses of this ID that we need to think about:
1 - as the "name" that is exposed to a user.
2 - as the kube "name" for the service and plan
No matter what happens with https://github.com/openservicebrokerapi/servicebroker/issues/273 I think that it would really be a mistake to expose this ID to the user as the way for them to specify which service/plan they want. The UX will just be too painful. So we really need to find a way to let people use the OSB API "name" field instead when specifying the service/plan.  A proposal for how we might do this is here: https://github.com/kubernetes-incubator/service-catalog/issues/802#issuecomment-317299121
Even if we do hide these IDs from the user, using them as the "name" on the kube resource is still problematic because the allowable chars for a kube "name" is restricted to "lower case alphanumeric characters, -, and .".  If OSB API does manage to restrict these fields such that kube can use them then we're fine.  But, I have my doubts the spec can do that, so I think we may need to do some kind mapping like outlined in https://github.com/kubernetes-incubator/service-catalog/issues/802#issuecomment-317299121.

Closing as suggested by @pmorie and no comments since January.

looking at the status of the OSB API issue ( https://github.com/openservicebrokerapi/servicebroker/issues/273 ) it appears that they decided they couldn't tighten the  charset so I think this PR is still valid. Re-opening.

@emaildanwilson want to rebase?

We don't store plans in the service class anymore. is this relevant at all? Does it need to be reapplied to serviceplans specifically?

authors: MHBauer duglin emaildanwilson nilebox pmorie


text:
Fixes to update & watch functionality for TPRs

This PR is a combination of #410 and #439. It will replace those two, but is not ready for merge yet.
Closes #410
Closes #439
Fixes #436
Fixes #406

The functionality herein works properly. After creating a broker with an invalid URL, the controller properly picks it up and updates the status properly:
ENG000656:service-catalog aaronschlesinger$ ks get broker -o yaml test-broker
apiVersion: servicecatalog.k8s.io/v1alpha1
kind: Broker
metadata:
  creationTimestamp: 2017-03-06T18:53:47Z
  name: test-broker
  resourceVersion: "1493"
  selfLink: /apis/servicecatalog.k8s.io/v1alpha1/brokerstest-broker
  uid: 3ae44ce4-029e-11e7-a591-080027d16e09
spec:
  url: http://beefco.de
status:
  conditions:
  - message: Error fetching catalog
    reason: ErrorFetchingCatalog
    status: "False"
    type: Ready

Command decision on this one - we've seen it work and it's behind a feature flag.  I've verified that it works in my cluster and will merge on green.

authors: arschles pmorie


text:
Power on EKS auto scaling group via lambda?

Hi there, this is just an idea.
We have an EKS cluster that used rarely and needs to be powered on when it's used.
It would be great, somehow that if the ALB notices the target group is empty, that it can execute a lambda function to power on the cluster.
Could it be possible?

Hi,
not sure whether i correctly understand this question.
But yes, ALB publish metrics about targets(e.g. HealthyHostCount) in targetgroup: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html
So ideally you can have alarms on these metrics and send to SNS and triggers lambda, then you can do almost anything inside an lambda function :D


text:
crictl exec: add --quiet/-q, --ignore-error/-e and --parallel flags

What type of PR is this?
/kind feature
What this PR does / why we need it:
The flags can be used to further manipulate on the exec behavior. Follow-up on: https://github.com/kubernetes-sigs/cri-tools/pull/1603#issuecomment-2396328240
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

crictl exec: add `--quiet/-q`, `--ignore-error/-e` and `--parallel/-x` flags.

/approve
/lgtm

authors: kwilczynski saschagrunert

repo: kubernetes-sigs/cri-tools


text:
cleanup: remove ioutil for new go version

The io/ioutil package has been deprecated from go 1.16:https://go.dev/doc/go1.16#ioutil
/kind cleanup

/ok-to-test

/lgtm

/assign @a7i

/approve
Thank you for your contribution @my-git9  🏆

repo: kubernetes-sigs/descheduler


text:
Sets type config template pluralname

Sets the template pluralName field of a type config by using the name of the API resource.

This is a good start.  Please do the same for the override and placement resources.

/retest

@danehans Arg, I'm not sure what I was thinking.  Overrides and placement can be automatically pluralized since 'override' and 'placement' is what is being pluralized rather than an arbitrary type name.

No worries. Let me update the PR .

I pass the unmanaged e2e tests locally, but fails in CI:
Ran 34 of 35 Specs in 135.331 seconds
SUCCESS! -- 34 Passed | 0 Failed | 0 Pending | 1 Skipped
--- PASS: TestE2E (135.33s)
PASS
ok  	github.com/kubernetes-sigs/federation-v2/test/e2e	135.389s

Any suggestions @marun?

@danehans The namespaced suite is failing, likely a transitory failure.  Once you push an update that pluralizes only the template the job will restart.

Thank you!
/lgtm
/approve

authors: danehans marun


text:
docs: gRPC Guide Serves 404

I navigated to the gRPC guide and the page serves a 404 at the moment.

@jon-whit Thanks for creating this issue, I will fix it.
/assign

authors: gyohuangxin jon-whit

repo: kubernetes-sigs/gateway-api


text:
Adding changelog for v1.0.0-rc1

What type of PR is this?
/kind documentation
What this PR does / why we need it:
This adds the changelog for v1.0.0-rc1. By approving this PR, you're also approving the release of v1.0.0-rc1.
Does this PR introduce a user-facing change?:
NONE

/cc @thockin @khenidak @MikeZappa87
/assign @bowei @shaneutt @youngnick
/hold for consensus

/lgtm

/hold cancel

authors: robscott youngnick


text:
Graduate the API to v1beta1

Graduate JobSet API to v1beta1. We need to keep v1apha1 for a few more releases to make it easier to customers to migrate.
Ref: https://book.kubebuilder.io/multiversion-tutorial/api-changes

@ahg-g and I were discussing skipping v1beta1 and graduating directly to v1, since several companies have been using for their production training workloads for a few months now, so it effectively GA already.
@kannon92 @vsoch what do you think?

It depends on if you think it's really free of errors and potential issues, or not. I don't see any harm in doing v1beta1 and then having that wiggle room, but it's up to you!

I think the main thing about v1 promotion is that means we should not break any existing user. I think we have been pretty careful on not breaking the API anymore so I think its fine to promote to GA.
Could you ask those companies (or even you!) to create an adopters page? It'd be nice to convey that people are actually using this project for something.

@vsoch it is not about free of errors, this is more about what commitment we are making to the API stability. Since multiple users are already dependent on it, this is practically becoming GA because everything we do moving forward must be backward compatible, so might as well just make that commitment official in the API.

Could you ask those companies (or even you!) to create an adopters page? It'd be nice to convey that people are actually using this project for something.

we can mention that Google Cloud is using it (we are not at liberty to list the customers); @vsoch if you feel comfortable perhaps we can list Lawrence Livermore National Laboratory?

I will ask! To be clear - "using it" meaning for development and prototyping or in production? We do not have a production Kubernetes cluster. That's what we are working towards.

/assign

@ahg-g @danielvegamyhre from the KubeFlow discussions, do we want to table this?

Yes, I think so.

Based on our recent conversations let's have a chat on the next Batch WG and Kubeflow Training WG calls to define actions items. It would be nice to identify list of pending APIs for JobSet V1 for various ML training/fine-tuning use-cases (e.g. PodGroups, Elastic Jobs, Stateful Indexed Jobs, etc.)
We can discuss short and long term goals, and gradually start working on them.
cc @tenzen-y @johnugeorge @terrytangyuan

@ahg-g @andreyvelich can you clarify what aspect of the recent discussions led you to want to pause graduation to v1? I've been having to spend a lot of time on an internal project lately and missed some of the latest conversations I think.

A few examples:

Support elastic policy to create HPA for PyTorch elastic.
JobSet doesn't have Restarting and Running conditions.
@ahg-g proposed to introduce  the JobSetTemplate that we can deploy together with Training Operator to simplify submission of Distributed PyTorch for users without understanding how to configure environment variables in JobSet.

As we discussed in this thread: https://docs.google.com/document/d/1C2ev7yRbnMTlQWbQCfX7BCCHcLIAGW2MP9f7YeKl2Ck/edit?disco=AAABKU-uQyA
since we want to make JobSet APIs stable in V1, we want to prototype use-cases in production for Jax, MPI, or PyTorch to understand if we need to make any changes to the JobSet APIs.
I am happy to discuss it on the next Batch WG call tomorrow if we have time for it. cc @bigsur0

Thanks @andreyvelich, who can help create tracking issues for the first two that describe the requirements in more details? @tenzen-y ?

@andreyvelich @ahg-g I raised the dedicated issues there:

[ ] #570
[ ] #571

/remove-lifecycle rotten

/remove-lifecycle stale

authors: ahg-g andreyvelich danielvegamyhre kannon92 tenzen-y vsoch

repo: kubernetes-sigs/jobset


text:
Allow run test-multikueue-e2e for mac os

What type of PR is this?
/kind bug
What this PR does / why we need it:
To allow run test-multikueue-e2e on mac os.
Which issue(s) this PR fixes:
Related to #1924
Special notes for your reviewer:
The docker on mac os working another way than on linux. So we can't bind port to 178.18.0.1. That's why we need to use internal kind cluster connection to control plane on  MultiKueue secrets.
Does this PR introduce a user-facing change?
No

/assign

/test pull-kueue-test-multikueue-e2e-main-1-29

/test pull-kueue-test-multikueue-e2e-main-1-29

/test pull-kueue-test-multikueue-e2e-main-1-29

/test pull-kueue-test-multikueue-e2e-main-1-29

/test pull-kueue-test-multikueue-e2e-main-1-29

/test pull-kueue-test-multikueue-e2e-main-1-29

@trasc wdyt of the overall approach?

/approve
Leaving LGTM to @trasc

/lgtm

/release-note-none

/remove-kind bug
/kind cleanup

authors: alculquicondor mbobrovskyi tenzen-y trasc

repo: kubernetes-sigs/kueue


text:
fix(packages/core): don't add \n for headless stderr printer

Fixes #7297

Description of what you did:

My PR is a:

[ ] 💥 Breaking change
[x] 🐛 Bug fix
[ ] 💅 Enhancement
[ ] 🚀 New feature

Please confirm that your PR fulfills these requirements

[x] Multiple commits are squashed into one commit.
[x] The commit message follows Conventional Commits, which allows us to autogenerate release notes; e.g. fix(plugins/plugin-k8s): fixed annoying bugs
[x] All npm dependencies are pinned.

/lgtm

repo: kubernetes-sigs/kui


text:
missing CPU for node "xxx", skipping

What happened?:
Can't make kubectl top node work
What did you expect to happen?:
Please provide the prometheus-adapter config:

prometheus-adapter config
resourceRules:
  cpu:
    containerLabel: container
    containerQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>, container!=""}[3m]))
      by (<<.GroupBy>>)
    nodeQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>, id='/'}[3m]))
      by (<<.GroupBy>>)
    resources:
      overrides:
        namespace:
          resource: namespace
        node:
          resource: node
        pod:
          resource: pod
  memory:
    containerLabel: container
    containerQuery: sum(container_memory_working_set_bytes{<<.LabelMatchers>>, container!=""})
      by (<<.GroupBy>>)
    nodeQuery: sum(container_memory_working_set_bytes{<<.LabelMatchers>>, id="/"})
      by (<<.GroupBy>>)
    resources:
      overrides:
        namespace:
          resource: namespace
        node:
          resource: node
        pod:
          resource: pod
  window: 1m

Please provide the HPA resource used for autoscaling:

HPA yaml
Does not meter, I have no node resources

Please provide the HPA status:
Does not meter
Please provide the prometheus-adapter logs with -v=6 around the time the issue happened:

prometheus-adapter logs
I1208 15:15:14.926535       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:14.926544       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:14.926555       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:14.926564       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:14.926572       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:14.926882       1 httplog.go:131] "HTTP" verb="LIST" URI="/apis/metrics.k8s.io/v1beta1/nodes" latency="3.65278ms" userAgent="kubectl/v1.23.3 (darwin/arm64) kubernetes/816c97a" audit-ID="8d1396ec-b420-46b2-8959-8ed9bfe123b4" srcIP="10.21.80.171:34326" resp=200
I1208 15:15:15.957861       1 handler.go:143] prometheus-metrics-adapter: GET "/apis/metrics.k8s.io/v1beta1/nodes" satisfied by gorestful with webservice /apis/metrics.k8s.io/v1beta1
I1208 15:15:15.961470       1 api.go:90] GET http://monitoring-kube-prometheus-prometheus.mgmt.svc:9090/api/v1/query?query=sum(container_memory_working_set_bytes{node%3D~"ip-10-21-221-138.ca-central-1.compute.internal|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx"%2Cid%3D'%2F'})+by+(node)&time=1670512515.958 200 OK
I1208 15:15:15.961484       1 api.go:90] GET http://monitoring-kube-prometheus-prometheus.mgmt.svc:9090/api/v1/query?query=sum(rate(container_cpu_usage_seconds_total{node%3D~"xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx|xxxxxxxxxxxxxxxxxxxxxx"%2C+id%3D'%2F'}[3m]))+by+(node)&time=1670512515.958 200 OK
I1208 15:15:15.962225       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:15.962242       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:15.962252       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:15.962261       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:15.962271       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:15.962284       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:15.962294       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping
I1208 15:15:15.962309       1 provider.go:293] missing CPU for node "xxxxxxxxxxxxxxxxxxxxxx", skipping

Anything else we need to know?:
The problem is with query container_cpu_usage_seconds_total{<<.LabelMatchers>>,id='/'}[4m], cadvisor does not response with id="/", I have a lot of ids like:
/kubepods/besteffort/pod2761ccbb-07c5-44ae-b841-8a570f569915
/kubepods/besteffort/pod016611cc-9081-4e1a-b55c-19f402038cb9/4a133e441a3ec3960e63594c32f9a78dea021c712de0bdaa4bc7...
Environment:

prometheus-adapter version: v0.10.0
prometheus version:  v2.39.1
Kubernetes version (use kubectl version): 1.23
Cloud provider or hardware configuration: AWS EKS
Other info:

I think it might be due to this rule in the default cadvisor configuration.
      - sourceLabels: [id, pod]
        action: drop
        regex: '.+;'

The metric wanted here is exported in this format:
container_memory_working_set_bytes{container="",id="/",image="",name="",namespace="",pod=""} 1.499369472e+09 1670968452168

But the rule above would drop it, due to there not being a pod defined for this entry. I'll test this theory tomorrow.

/assign @olivierlemasle
/triage accepted

Closing since this is issue with the helm configuration that is hosted in a different repository.

@dgrisonnet review on the PR suggests that my fix is incorrect - prometheus-adapter should be using different metrics (from node-exporter, not cgroups). I think this issue should be re-opened.

No, the review was referring to this effort https://github.com/kubernetes-sigs/prometheus-adapter/pull/516, that I already rejected because we don't want a dependency on node-exporter here.
The changes from your PR looked reasonable to me, at least it fixed the issue at hand. But if they want to use new queries, it is up to them.
There is one thing that is certain which is that this repository doesn't provide a configuration for kubelet ServiceMonitor so your issue shouldn't be fixed here.

I think it might be due to this rule in the default cadvisor configuration.
      - sourceLabels: [id, pod]
        action: drop
        regex: '.+;'

The metric wanted here is exported in this format:
container_memory_working_set_bytes{container="",id="/",image="",name="",namespace="",pod=""} 1.499369472e+09 1670968452168

But the rule above would drop it, due to there not being a pod defined for this entry. I'll test this theory tomorrow.

Thanks a lot!

authors: dashpole dgrisonnet kwohlfahrt nenych

repo: kubernetes-sigs/prometheus-adapter


text:
migrate to github.com/aws/aws-sdk-go-v2

What type of PR is this?
/kind cleanup
What this PR does / why we need it:

migrate to github.com/aws/aws-sdk-go-v2

Which issue(s) this PR fixes:
Fixes #1381
Special notes for your reviewer:
Does this PR introduce a user-facing change?

migrate to github.com/aws/aws-sdk-go-v2

/hold
/assign @saschagrunert @xmudrii @dims

/lgtm

/lgtm

/unhold

authors: cpanato saschagrunert

repo: kubernetes-sigs/promo-tools


text:
nodestatus: Only log low-level messages if verbosity is increased

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Unless the nodestatus controller is being debugged, then these messages
are really not that important.
Which issue(s) this PR fixes:
Fixes #1066

Does this PR have test?
N/A

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

NONE

Codecov Report

Merging #1083 (def981f) into main (5b70570) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1083   +/-   ##
=======================================
  Coverage   50.43%   50.43%
=======================================
  Files          42       42
  Lines        4761     4761
=======================================
  Hits         2401     2401
  Misses       2281     2281
  Partials       79       79

authors: codecov-commenter jhrozek


text:
Fixing windows container builds

Signed-off-by: Mark Rossetti marosset@microsoft.com
/assign @jayunit100 @daman1807
Fixes https://github.com/kubernetes-sigs/windows-service-proxy/issues/31

I tested this out with mrosse3/kpng:test and mrosse3/kpng:latest (both pushed from the same execution of the script) and was able to pull both images on Windows nodes

/cc @jsturtevant

Thanks mark!!!! Ok looking now

@daman1807 - what version of containerd do you have on the nodes?
I'm running  containerd://1.7.0-beta.3 from the GH release and the pod is starting up normally.
In containerd v1.7 we added some paths to PATH by default for hostprocess containers.

@marosset I will update the containerd in the windows node to 1.7.0-beta.3. I might be wrong but it looks like we need to fix the working dir in dockerfile or the update in 1.7+ handles this only 😅. Will test this out.
https://github.com/kubernetes-sigs/windows-service-proxy/blob/main/Dockerfile.windows#L11

@marosset I tried with 1.7.0-beta.3 but still, the issue persists. Shall I update the dockerfile here, it works if I update the dockerfile.

Interesting - I've been testing this on Windows Server 2022 nodes. I wonder if there is some difference in behavior with Windows Server 2019 and Windows Server 2022 w.r.t. the paths here. I'll see if i can find something out

repo: kubernetes-sigs/windows-service-proxy


text:
[incubator/elasticsearch] Add pod disruption budgets.

So that clusters don't become unavailable during node restarts.
cc @icereval

Marking this as stale. Please update within one week.

@unguiculus this is ready for review.

/ok-to-test

@jmcarp Readme update still missing.

Marking stale. Please update readme.

Closing as stale. Feel free to reopen if/when you decide to pick this up again.

authors: jmcarp unguiculus viglesiasce

repo: kubernetes/charts


text:
[cinder-csi-plugin, occm] Unable to multiattach PV across pods on different nodes

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug - Unable to multiattach PV across pods on different nodes

/kind feature

What happened:
Trying to attach PV to multiple pods in a kubernetes cluster on multiple worker nodes, we are using openstack for worker node VMs
storage class is set to "multiattach= True"
But when we are using a deployment to attach across multiple worker nodes, it fails with error
What you expected to happen:
Should be able to attach to all the pods across all worker nodes
How to reproduce it:

Create SC
Create PVC
Attach PVC to deployment and create it
Scale up the pods, so that it schedules on all worker nodes
Some pods will remain in containercreating state as the volume attachment fails

Anything else we need to know?:
we are using cinder.csi.openstack.org as CSIDriver based on occm
Error log
Events:
Type     Reason              Age                From                     Message

Normal   Scheduled           29s                default-scheduler        Successfully assigned default/task-pv-deployment-77bcbf5fc6-48lph to workernode-2
Warning  FailedAttachVolume  12s (x6 over 28s)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-07f4902c-3ee0-4de9-b1be-7dd4bc19da93" : rpc error: code = Internal desc = ControllerPublishVolume Attach Volume failed with error disk 5a7764f0-d30c-44ca-a05d-b939173116b3 is attached to a different instance (06d963d3-d576-41e1-9bf6-162e179e571f)
Environment:

openstack-cloud-controller-manager(or other related binary) version:
OpenStack version: 5.5.0
Others:
kubernetes version 1.19.4, 1.23.1
quay.io/k8scsi/csi-node-driver-registrar:v1.2.0
quay.io/k8scsi/csi-attacher:v2.1.1
quay.io/k8scsi/csi-provisioner:v1.4.0
quay.io/k8scsi/csi-snapshotter:v1.2.2
quay.io/k8scsi/csi-resizer:v0.4.0
docker.io/k8scloudprovider/cinder-csi-plugin:v1.18.0
docker.io/k8scloudprovider/openstack-cloud-controller-manager:v1.18.0

have you tried through this?
https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/features.md#multi-attach-volumes

authors: jichenjc madeinindiadot

repo: kubernetes/cloud-provider-openstack


text:
[manila-csi-plugin] Updated external-provisioner to v2.0.2

What this PR does / why we need it:
Currently, manila-csi-plugin uses external-provisioner sidecar v1.4.0, which doesn't support v1beta1 snapshots as a volume data source. This PR updates it to v2.0.2.
Which issue this PR fixes(if applicable):
fixes https://github.com/kubernetes/cloud-provider-openstack/issues/1232
Special notes for reviewers:
This PR needs to be merged before #1205.
Release note:

manila-csi-plugin: Updated external-provisioner v2.0.2

PTAL @ramineni @jichenjc

/cc @tombarron @gouthampacha @Fedosin

@gman0 Isn't it better to merge this PR with the snapshotter to make sure tests pass as both are related ?

@ramineni I can do that


text:
Adopt go-build-template and push images as 1.2

The latest version(1.2) exechealthz docker images have been pushed to gcr.io. Listed as below:

gcr.io/google_containers/exechealthz:1.2
gcr.io/google_containers/exechealthz-amd64:1.2
gcr.io/google_containers/exechealthz-arm:1.2
gcr.io/google_containers/exechealthz-arm64:1.2
gcr.io/google_containers/exechealthz-ppc64le:1.2

Previous Makefile is broken due to the new appear vendor folder. It is fixed now.
I tried go-build-template but found it not very friendly to set multiple BASEIMAGEs for different ARCHs. So I switch back.
@thockin @bprashanth

This change is

yeah /go/src is the right place.  Take another look at the build template
repo I linked before.  I fixed multi-arch.
On Thu, Sep 22, 2016 at 10:58 PM, Zihong Zheng notifications@github.com
wrote:

@MrHohn commented on this pull request.
In exec-healthz/Makefile https://github.com/kubernetes/contrib/pull/1778
:

@@ -53,11 +53,11 @@ endif
cd $(TEMP_DIR) && sed -i "s|BASEIMAGE|$(BASEIMAGE)|g" Dockerfile

Compile the binary inside a container for reliable builds

docker run --rm -it -v $(TEMP_DIR):/build golang:$(GOLANG_VERSION) /bin/bash -c "make -C /build server ARCH=$(ARCH)"

docker run --rm -it -v $(TEMP_DIR):/build golang:$(GOLANG_VERSION) /bin/bash -c "mv /build/vendor/* /go/src && make -C /build server ARCH=$(ARCH) TAG=$(TAG)"

The previous command tried to build under /build, which is outside
$GOPATH and $GOROOT. So go will not look in the vendor folder(
golang/go#12511 https://github.com/golang/go/issues/12511).
What about this command?
docker run --rm -it -v $(TEMP_DIR):/go/src/build golang:$(GOLANG_VERSION)
/bin/bash -c "make -C /go/src/build server ARCH=$(ARCH) TAG=$(TAG)"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/contrib/pull/1778, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVOoWt5LBP09nUF1MH1Qg8CiaBbEwks5qs2qTgaJpZM4KEeBg
.

@thockin PTAL, the new commit adopts go-build-template.

Once we commit this we should apply a tag.  I'd like to advocate for semver (3-field) versions everywhere.  Arguments?

I will send you a PR with a couple tweaks - I an constantly refining :)

Yeah, MAJOR.MINOR.PATCH seems good to me.
One more question is: should the tagging happen locally? It does not make much sense applying an union tag for the contrib repo. There are some tags on the contrib repo like cluster-autoscaler-0.3.0, which adds the sub-repo name as prefix. Though I don't think that's good neither.

authors: MrHohn thockin

repo: kubernetes/contrib


text:
Mark Heapster as Deprecated

This marks Heapster as deprecated, adding a deprecation timeline that
culminates in the retirement of the Heapster project for the Kubernetes
1.13 release.
As per the discussion in SIG Instrumentation.

cc @kubernetes/heapster-maintainers @kubernetes/sig-instrumentation-misc @brancz @piosz

/hold to make sure we don't accidentally merge this before people have a chance to voice concerns.

P.S. I've written up the deprecation timeline as a draft.  I'd like it to be similarly aggressive to what's listed, if possible, but I'm open to suggestions.

reviewers/approvers, please take a look:
@acobaugh, @almogbaku, @andyxning, @bluebreezecf, @burmanm, @crassirostris, @emfree, @ezeev, @huangyuqi, @jamtur01, @johanneswuerbach, @jsoriano, @kawych, @Kokan, @loburm, @mcorbin, @miaoyq, @mwielgus, @mwringe, @piosz, @theairkit, @x13n, @yogeswaran

/cc @piosz
I don't think we should fully deprecate Heapster, at least not at this point. For instance, Heapster is currently a go-to monitoring agent for Stackdriver.
I suggest to deprecate only Heapster API and work on replacing it with metrics API served by Metrics Server. My understanding of current monitoring architecture for k8s: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md is that Heapster is going to become just another third-party monitoring agent.

@kawych can we find a way to have heapster transition from this org to a stackdriver organization? From the Kubernetes (sig-instrumentation) project point of view we agreed that Heapster is to be depcrecated. That doesn't mean stackdriver can't continue to support it, but as the Kubernetes project as a whole it's not a project we want to continue supporting. Can we agree on deprecating it here and having a stackdriver fork and support as necessary for your organization?

For instance, Heapster is currently a go-to monitoring agent for Stackdriver.

@brancz beat me to the punch here, but I'll follow up with extended thoughts.
Stackdriver using Heapster is all well and good, but, IMO, that's not a good reason to keep Heapster around as a maintained Kubernetes project -- it's a good reason for GCE to keep around a Heapster fork until they can migrate to a different monitoring solution (or really as long as they want).
One of the key observations of the new monitoring plan was that the Heapster model of development (vendor dump) is unsustainable.  Even apart from that, the Heapster codebase needs significant love.  It has serious design issues (ask me about these later, if you're interested), years accumulated cruft with no real policy around what we can remove, and serious usability issues (I'd be happy to expand on these later as well).
Furthermore, non-deprecated Heapster poses problems from an organization perspective.  People continue to request that we add new sinks, and with the current policies, we don't have a good reason to say no.  It's unclear if this is because they believe that Heapster is still the recommended solution for monitoring Kubernetes (it's not), because they want their monitoring solution to reach a larger audience (which is, in-and-of-itself, also a problem -- see below), or because they don't want to maintain collection code.
On that subject, from a Kubernetes perspective, we want people to invest in a healthy monitoring ecosystem with solutions designed to work with their tools from the beginning, as opposed to shoehorning the tools into Heapster's architecture -- we have a number of PRs like "this specific sink has issues with this way the metrics are structured in Heapster, so we need to work around it".  I'm not try to cast a bad light on our sink maintainers -- they do a wonderful job with the resources they have, but it's tough trying to keep things working, between the core Heapster code and the sink-specific hacks.
As an added benefit, this'll help ensure that, as we move forward with features that require use of the new monitoring architecture, we can be more certain that distributions have either switched over to using it, or made a conscious decision to maintain their own copy of Heapster.
To summarize: one of the main reasons for the new monitoring architecture was to remove Heapster as a bottleneck to development, and to ensure more maintainable code.  Keeping Heapster around as  a maintained Kubernetes project hinders that effort.

Thanks for taking the time to express yourself @DirectXMan12! You have clearly laid out, what my thoughts are exactly (but expressed them poorly myself).

Is metrics-server going to be promoted from incubator?
Agreed that we need also promote metrics-server to kubernetes organization alongside the deprecation of Heapster if we do need to deprecate Heapster.

I suggest to deprecate only Heapster API and work on replacing it with metrics API served by Metrics Server. My understanding of current monitoring architecture for k8s: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md is that Heapster is going to become just another third-party monitoring agent.

It also seems to me that keep the scrape and sink ability for Heapster should be ok. IMHO, moving to metrics api, metrics server is good for HPA to better support custom metrics which is the currently the big pain point for instrumentation. So, i think we should move the api functionality from Heapster to metrics api.
IMHO, Heapster deprecation is too sudden. There are no simple and easy setup guides for metrics api, metrics server and third party tsdb servers pipeline available to end users to learn and try for now which is a big gap between Heapster. Actually i, even as a developer, has no clear thinking about how to set up a monitor system with metrics api, metrics server and third party tsdb to replace the existing one backed by Heapster with no big changes. If we want end users move to the new monitor pipeline, we should add some docs or guides to help them to migrate from Heapster backed monitoring system to the new one.
Also there are some existing add-ons or functionalities depends on the data from Heapster. What is the procedure to help those components migrating to the new pipeline smoothly.
BTW, what is the replacement for eventer. People may still be using it.

one of the main reasons for the new monitoring architecture was to remove Heapster as a bottleneck to development, and to ensure more maintainable code. Keeping Heapster around as a maintained Kubernetes project hinders that effort.
Agreed that maintaining Heapster with multi sinks is painful. But maybe we should think a way for Heapster to support a plugin mechanism just like out-of-tree cloud provider support or different device support with device plugin instead of kicking it off and setup a new one. :)

It's really a very sudden news to me! I was thinking contributing a new sink(poseidon) which is leaded by sig-scheduling.

Yeah, our current ongoing Poseidon/Firmament scheduler effort leverages Heapster real-time metrics for resource scheduling. We created a new sink for pushing metrics information out of heapster to Firmament scheduler.
As Dujun mentioned, we were about to initiate new Poseidon sink upstreaming process in the next couple of days.

@DirectXMan12 Thanks for the detailed and excellent explanation.
Sorry for not catching up with the latest usage about HPA/kubectl top and Heapster. :)
Maybe we could do this better in the following aspects:

Add the deprecation summary for Heapster also to the Kubernetes release v1.11 release note and update the deprecation info for Kubernetes release v1.12 and v1.13. Most people will try to read the summary release note for Kubernetes to learn the trends for Kubernetes. So, i think it is also a good place to make the heapster deprecation widely known.
Add a detailed setup docs for metrics api, metrics server and third party monitoring system to learn.
Add the replacement binary for eventer in case some people still using it.

@DirectXMan12 @brancz
Thank you for detailed explanations. I've also discussed with @piosz the Stackdriver case and once he approves, I have no objections. Removing myself from reviewers.

As the very short-term co-maintainer of the influxdb sink, I fully support this effort. For the influxdb case, I believe telegraf with its prometheus input plugin ought to be able to replace the functionality of heapster by pulling metrics straight from metrics-server. I haven't dug into this yet, but I wouldn't be surprised if someone in the TICK community is already doing just that, and we just need to document those methods and configurations within the kubernetes project as an example to get metrics into influxdb, and as a migration path for the heapster+influxdb users out there.

Add the deprecation summary for Heapster also to the Kubernetes release v1.11 release note and update the deprecation info for Kubernetes release v1.12 and v1.13. Most people will try to read the summary release note for Kubernetes to learn the trends for Kubernetes. So, i think it is also a good place to make the heapster deprecation widely known.

Yes, definitely!

Add a detailed setup docs for metrics api, metrics server and third party monitoring system to learn.

I'd love to improve the docs.  Can you put together a specific list of complaints you have with the official setup docs in the Kubernetes documentation?

Add the replacement binary for eventer in case some people still using it.

We should definitely link to that somewhere.  Does anybody remember exactly what it was?  I can't recall.  I'll need to track it down otherwise.

For the influxdb case, I believe telegraf with its prometheus input plugin ought to be able to replace the functionality of heapster by pulling metrics straight from metrics-server.

It shouldn't be pulling from metrics-server.  It should query the nodes instead.  At any rate, we should have follow-up PRs to build up a list of alternatives for the third-party monitoring solutions.
@piosz any objections to this timeline.  Otherwise, I'll plan on merging by the end of the week.

Since there are no further maintainer objections lodged, I'm going to merge this.

Hey guys, were any decisions ever made W/R/T the replacement for eventer? I see a bunch of discussion of linking to a replacement but with no follow-up...

It differs based on sink.  I believe there was a fluentd event exporter at one point, and there's now a stackdriver event exporter, plus what appears to be a more generic one at https://github.com/alauda/event-exporter (not endorsing that one, but it does appear to be a potential solution).

There's also Heptio's eventrouter, it appears: https://github.com/heptiolabs/eventrouter

authors: DirectXMan12 acobaugh andyxning brancz deepak-vij eherot kawych m1093782566

repo: kubernetes/heapster


text:
expose kubernetes version

There have been a lot of times now that we've had to use different versions of yaml for different k8s versions. for example, init-containers. I've also seen some templates flat out not work with older k8s versions.
I'd like to see two features added to helm.

a minimum k8s version field in Charts. This will give the user warning/block the deployment of a chart that is known to be too new for a particular version of k8s.

expose to the gotl templates, the major, minor, micro version of k8s. Templates can then use this information to render the right object if it wants to support optional features or multiple versions of k8s.

Just noting that .Capabilities.KubeVersion exposes Kubernetes version info to templates, so point 2 has already been solved.
example: https://github.com/kubernetes/helm/blob/f9c9e9d6cb7f16d6708992af00891c43bc42856c/pkg/lint/rules/testdata/albatross/templates/svc.yaml#L11-L12

It seems if the KubeVersion is already available to Helm then it would be a simple check to handle number 1 on the client.

@bacongobbler oh, cool. didn't know about that one. Thanks. :)

So a field in chart.yaml that takes a semver compatible value?

yeah. and bails if k8s is older then it.

Also we can go full on semver range so chart can be deprecated and still work for older clusters and safely refuse to work for newer clusters if they are known to be incompatible.

even better. :)

we should close this in favour of #2708 as that better describes the proposal in this ticket. Thanks @jascott1 for summarizing!

closing in favour of #2708.

we should close this in favour of #2708 as that better describes the proposal in this ticket

No, #2708 only covers the first item, not

2. expose to the gotl templates, the major, minor, micro version of k8s. Templates can then use this information to render the right object if it wants to support optional features or multiple versions of k8s.

repo: kubernetes/helm


text:
Update embargo doc link in SECURITY_CONTACTS and change PST to PSC

See https://github.com/kubernetes/security/issues/8 for more information

/close
The change was already synced by the Kubernetes Publisher bot from https://github.com/kubernetes/kubernetes/pull/75201

repo: kubernetes/kubelet


text:
Add godep dependency golang.org/x/sys/unix

Fix #7
I've tried this in a brand new GOPATH.
Both "godep restore + godep build" and "go build" work.
@derekwaynecarr @eparis We don't have enough reviewer for this repo yet, are you ok with this PR? If so, I'll manually merge it. :)
/cc @dchen1107

Tested PR, was able to build.
Thanks!

@derekwaynecarr Thanks for reporting the issue and verifying this PR.
Manually merged.

authors: Random-Liu derekwaynecarr

repo: kubernetes/node-problem-detector


text:
Keeping selected test name

Refresh shouldn't change selected test name (if possible).

/lgtm

/lgtm
(we were still discussing abt it offline:)
Thanks for this cool change.
Btw @wojtek-t - this should no longer trigger that refresh issue.

authors: krzysied shyamjvs wojtek-t

repo: kubernetes/perf-tests


text:
Identify a list of container images under Kubernetes Org

Background
There are lot of places where images related to Kubernetes can be found:

Container image manifests and yamls: https://github.com/kubernetes/k8s.io/tree/main/k8s.gcr.io
Base Image exception list: https://github.com/kubernetes/sig-release/blob/master/release-engineering/baseimage-exception-list.md
SBOM: (Software Bill of Materials) @puerco: any pointers on how to parse the SBOM files and if they are a good source to get a list of images?

https://sbom.k8s.io/v1.22.0/release
https://sbom.k8s.io/v1.22.0/source

Goal

Find out an authoritative source for list of container images under Kubernetes org (i.e. release, k8s.io, kubernetes) including but not limited to the above resources
Filter the list to only point to the most recent image or in case of core k8s images most recent n, n-1 and n-2 release images
Convert this into a JSON doc that can be consumed as input for container image scanner automation

xref: kubernetes/sig-security#3
/sig security release
Side note: This issue might be transferred to kubernetes-sigs/security when it is created

Fixed by https://github.com/kubernetes/test-infra/pull/23419

repo: kubernetes/sig-security


text:
Docs are not mobile friendly

This is a Bug Report
Problem:
Docs are unusable on mobile:

Proposed Solution:
Docs are usable on mobile.
This will mostly involve CSS work via media queries to set the correct content width, font size.
For the menu, there right be the need to make it collapsible via a bit of JS.
Page to Update:
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands

Just to add more information, the reference documentation is generated with:
https://github.com/kubernetes-incubator/reference-docs
The CSS cames from https://github.com/kubernetes-incubator/reference-docs/tree/master/gen-apidocs/generators.
And the Kubernetes site imports it with:
https://github.com/raelga/kubernetes-website/blob/master/update-imported-docs/reference.yml

/kind feature
/priority backlog

/language en

/remove-lifecycle stale
Maybe we switch to the markdown format docs for kubectl.

Changes were made in 1.18 to improve mobile friendliness.
Can this issue be closed now?

/close
Let's see if there are still complaints on this.

authors: brianpursley raelga sftim steren tengqm

repo: kubernetes/website


text:
[ja] Translate docs/contribute/participate/roles-and-responsibilities.md into Japanese

This is a Feature Request
What would you like to be added
Translate docs/contribute/participate/roles-and-responsibilities.md into Japanese
Why is this needed
There is no Japanese translation for this page
Comments

File to translate:

https://github.com/kubernetes/website/blob/main/content/en/docs/contribute/participate/roles-and-responsibilities.md

Original:

https://kubernetes.io/docs/contribute/participate/roles-and-responsibilities/

/language ja
/area localization
/assign
/triage accepted


text:
fix 404: Not Found

404 error returned when clicking the link

/assign @kbarnard10

Thanks for your PR @xichengliudui but it needs to go against this repository: https://github.com/kubernetes/kubernetes-docs-zh
The Chinese language docs are fixed there, and then imported to the main docs repo (where this PR is currently).


text:
zh-trans: add kops.md

未解决引入英文原文导致的冲突，重新创建PR：#11293

/assign @tengqm


text:
Add Logging to glossary

Associated with #5993

/assign @chenopis


text:
Adding alternative command to create namespace

As this is first place user look to find details to create a namespace, added an alternative command to create a namespace. Also, this is mostly used way to create namespace instead of YAML.

/approve
/lgtm


text:
Create advanced.md

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Remember to delete this note before submitting your pull request.
For pull requests on 1.15 Features: set Milestone to 1.15 and Base Branch to dev-1.15
For pull requests on Chinese localization, set Base Branch to release-1.14
For pull requests on Korean Localization: set Base Branch to dev-1.14-ko.<latest team milestone>
If you need Help on editing and submitting pull requests, visit:
https://kubernetes.io/docs/contribute/start/#improve-existing-content.
If you need Help on choosing which branch to use, visit:
https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

/assign @dchen1107
Please give this PR approval.

/retest

@chenrui333  我已经把错误的地方都改正过来了。

/assign @dchen1107
Please give this PR approval.

@zhangx501 建议本地构建一下，解决构建问题


text:
Update translation in podpreset.md

Update translation in podpreset.md

/lgtm
/approve

authors: tengqm wwgfhf


text:
[ko] Translate docs/home/supported-doc-versions documentation

Translated "This website contains documentation for the current version of Kubernetes and the four previous versions of Kubernetes." of https://github.com/kubernetes/website/blob/dev-1.21-ko.5/content/en/docs/home/supported-doc-versions.md in Korean which was missing earlier.
Issue -> https://github.com/kubernetes/website/issues/28512

/assign @seokho-son

/label tide/merge-method-squash

@anubha-v-ardhan Thank you for the contribution!
/lgtm
Please squash commits in PR according to the contribution guideline :)
Thank you !
https://kubernetes.io/docs/contribute/new-content/open-a-pr/#squashing-commits

@seokho-son I think I did something wrong. I fetched and merged kubernetes:main to my anubha-v-ardhan:patch- 2. What should I do now

@anubha-v-ardhan
Since base branch for feature-branch of this PR is dev-1.21-ko.5,
merging feature-branch with main branch mixes commits in dev-1.21-ko.5, main(63 commits), and your commit(1 commit).
For squashing, you just needs to rebase in your local branch. no need to merge with other branch :)
I think you can cherry-pick your commit to resolve commit conflicts,
or it is ok to close and open new PR according to your preference :)

/hold

Thanks for the help @seokho-son. I am closing this and opening a new PR. This was my first ever PR in open source, sorry for the inconvenience caused. :' )

authors: anubha-v-ardhan jihoon-seo seokho-son


text:
Add natalisucks to docs reviewers and approvers of English language content

As part of my Co-chair TODOs for SIG Docs, am making sure I'm added to the reviewers and approvers list for English language content ❤

/lgtm

/approve
Welcome!

authors: natalisucks reylejano sftim


text:
Multiple changes

Virtual IPs and Service Proxies page images replacement
en.toml file data sort order
link: #38165 & #38257

Hi! Please see PR https://github.com/kubernetes/website/pull/38287. It fixes https://github.com/kubernetes/website/issues/38257 already.

/retitle Multiple changes
/hold
I'm not sure of the intent here: was it to improve diagrams, or to sort the English localization strings? I see both changes in one PR.
OK to unhold once it's clear which single change we're making.

@tamilselvan1102 Hi there, as per Tim's feedback, if you could please rebase and confine your changes to a single change, that would be great. It's also acceptable to close this PR and open two newer ones to contain your changes in precise places/threads. Thanks again.

/close
Feel free to reopen and 1) resolve the conflicts; 2) address the reviewer's feedbacks.

@natalisucks
created new pull request. please confirm

authors: QuinceyJames natalisucks sftim tamilselvan1102 tengqm


text:
Remove old, unused images

Remove some images that as I see things are not used anywhere by this website.

Hi @sftim . Thanks for cleaning up the images.
/approve

/lgtm

authors: kbhawkey sftim tengqm


text:
[zh-cn] Update kubernetes-basics

the description before is confused

Please use the following command to detect the synchronization status of the English document and modify it together. Thanks!
./scripts/lsync.sh content/zh-cn/docs/tutorials/kubernetes-basics/_index.html

Hi:
I run the command and get follwing result:
content/zh-cn/docs/tutorials/kubernetes-basics/_index.html is still in sync

@xuruidong Please run the command in the main branch. Your patch-1 branch is "contaminated".

@xuruidong Please run the command in the main branch. Your patch-1 branch is "contaminated".

@tengqm  Thanks for your reminder！
@my-git9 Please review again, thanks!

LGTM, please squash your commit: https://kubernetes.io/docs/contribute/new-content/open-a-pr/#squashing-commits

LGTM, please squash your commit: https://kubernetes.io/docs/contribute/new-content/open-a-pr/#squashing-commits

@my-git9
Done !

/lgtm
Thanks

/approve

authors: my-git9 tengqm xuruidong


text:
Synchronize Polish localization for ver 1.28, part 4

Synchronize Polish localization for ver 1.28, part 4

/lgtm

/approve

authors: kpucynski mfilocha


text:
Update admission webhook doc

Replacing #7586.
Fixing #7002
The old doc was still claiming admission webhooks an alpha feature.
The intention of this doc is quickly ramp up users to experiment with the admission webhooks. For production use cases, we need @lavalamp 's more detailed instructions in #6836. I've said that in the doc as well.

I've addressed the comments in the previous PR, and created the PR against the master branch.

As a followup, we should move admission webhooks and initializers to their own doc.

a couple nits, lgtm as a step in the right direction

Can we cherrypick this into 1.9?

Thanks @liggitt. I'll hold to give @jennybuckley a chance to review.

/lgtm

@heckj could you approve the change? Thanks.

/approve

authors: caesarxuchao heckj janetkuo jennybuckley liggitt


text:
Typos in docs/proposals/container-image-vulnerability-adaptor.md

Describe the bug
Typo is picutre
Expected behavior
Typos picutre should be changed into picture

I fixed the typo

https://github.com/kubescape/kubescape/pull/678#issue-1349466893

@RohitYandigeri where?

Kindly check the current content
And typo is there

Kindly check the current content
And typo is there

Can you please close your PR as a newbie I want to merge the PR

as a newbie I want to merge the PR

@RohitYandigeri I wish you best of luck :)

authors: RohitYandigeri bishal7679 dwertent

repo: kubescape/kubescape


text:
Cluster Utilization is empty

Describe the bug
In the overview section, Utilization is empty.
To Reproduce
Steps to reproduce the behavior:
Create a new cluster with k3d, setup metrics and open cluster in monokle.
Expected behavior
It show Utilization stats.
Screenshots

Desktop (please complete the following information):

OS: macOS
Version: 14.5

Additional context
When the same cluster is opened in Lens, it is showing Utilization stats.

My k3s cluster has same issue.

authors: ChillarAnand genki

repo: kubeshop/monokle


text:
Show namespace dropdown in  'All namespaces' mode

The namespace is inherited from the existing resource or from global namespace dropdown.
However if user selected All namespaces and creates a new resource there is no namespace available.
In this scenario we use a hardcoded fallback to default namespace.
In order to allow overriding the hardcoded namespace we need to add a new field to the screens that create new resources.
The list of screens:

PlanWizard
AddEditProviderModal

After discussion:
a. when in "all namespace" fallback to operator default namespace.
b. visualize the namespace in all modals that create or edit resources, so user will have a way to know where the new resource will be created.
closing, this was fixed in:  #207

authors: rszwajko yaacov


text:
UI validation rules for the Provider resource name are not aligned with Kubernetes standards

A follow up for: #646
The current UI validation rules for the Provider resource name value are not aligned with Kubernetes DNS Subdomain Name standards.
Differences:

The '.' character is not allowed
Starts with an alphabet character instead of allowing to start with an alphanumeric character

cc:// @RichardHoch @anarnold97

@sgratch Please see my comment on https://issues.redhat.com/browse/MTV-684. Thanks.

authors: RichardHoch sgratch


text:
Replace "k8s.io/utils/pointer" with "kubevirt.io/kubevirt/pkg/pointer"

Is your feature request related to a problem? Please describe:
In the code we used  k8s.io/utils/pointer package but this is has been replaced with the kubevirt package kubevirt.io/kubevirt/pkg/pointer. As a reference, you can see the best-practice in kubevirt coding conventions
Describe the solution you'd like:
Replace all the leftover  k8s.io/utils/pointer with kubevirt.io/kubevirt/pkg/pointer functions
Describe alternatives you've considered:
Keep the code messy and with multiple libraries which do the same thing
Additional context:
Good first issue for new contributors

/label good-first-issue

/sig code-quality

@alicefr there are so many file to change. Should i make changes to single PR or split into multiple one ?

/assign

@anishbista60 maybe try to split per directory, the BUILD.bazel files they will be updated automatically once you do make

@alicefr ok , but going to per directory will result into more no. of PR . SO, IMO i will try to make a PR with changes in 10 files. would it be fine ?

@alicefr ok , but going to per directory will result into more no. of PR . SO, IMO i will try to make a PR with changes in 10 files. would it be fine ?

Sure, you can try also to see by components and directory like pkg/virt-launcher, pkg/virt-controller... Even if the PR is large, it should be relatively simple to review. The only issue if you change multiple file together in the same PR is that rebases might occur more frequently.

@alicefr ok , but going to per directory will result into more no. of PR . SO, IMO i will try to make a PR with changes in 10 files. would it be fine ?

Sure, you can try also to see by components and directory like pkg/virt-launcher, pkg/virt-controller... Even if the PR is large, it should be relatively simple to review. The only issue if you change multiple files together in the same PR is that rebases might occur more frequently.

yeah, Agreed . Would be problem with rebasing . Then i will go with directory wise. Thank you .

please look into all of this PR .

@alicefr could you please add the reason for this change in the issue's description?

@alicefr could you please add the reason for this change in the issue's description?

@orelmisan well, there is already, we should favor the kubevirt library over the k8s's one. I also linked the document with the kubevirt code-convetion where this is suggested. What should I add on top of this?

@alicefr Based on today community call. could you please label this issue as hacktoberfest?

Now, this is the last PR which closes the issue. please take a look.
Thank you every one for your kind review.

/sig code-quality

/kind cleanup
@alicefr the rename finally landed

authors: alicefr anishbista60 dhiller orelmisan

repo: kubevirt/kubevirt


text:
virt-launcher, vcpu: Fix EmulatorThreadPin assign strategy

What this PR does / why we need it:
Currently, when CPUManagerPolicyBetaOption is set to full-pcpus-only, the virt-launcher pod is assigned with two CPU threads for emulator-threads [0] - but only if the amount of CPUs originally requested was even.
This is not aligned with the EmulatorThreadPin assignment on virt-launcher, where 2 threads are requested regardless of the amount of vCPUs.
This PR Fixes the EmulatorThreadPin assignment to request the second emulator thread only if the amount of vCPUs is even.
[0] https://github.com/kubevirt/kubevirt/pull/10593
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:
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note:

Change second emulator thread assign strategy to best-effort.

/retest-required

Change: Added unit test cases

/retest-required

Ok, it looks good to me now. Thanks for making the changes.
/approve

authors: RamLavi vladikr


text:
tests/utils: move GetNodeHostModel to libnode

What this PR does
Move function to its right context
Release note

NONE

/approve

@orelmisan hi I think the commit and pr are so simple and explain that I moved the function to libnode, I think it's clear enough why to move stuff from test utils to specific lib library..


text:
network: Discontinue (and remove) the passt network core binding

What this PR does
This PR is the next implemention phase of https://github.com/kubevirt/community/blob/main/design-proposals/passt-impl-iface-api-replacment.md
passt [1] network core binding has been marked for deprecation in v1.2 [2] and per the original phase plan it is now discontinued towards v1.3.
Users who would like to continue using the binding are encouraged to use the passt network binding plugin [3].
The passt network core binding did not reach graduation (GA), therefore its removal does not require any special exception nor commitment to preserve the functionality of existing running VMs.
However, in order to ease the upgrade transition for users who are using this network binding, the discontinuation implementation is preserving existing workloads (VMs) running without disruption.
Once the cluster us upgraded, new VMs or migrated VMs will not be able to run with the passt network core binding.
Future releases may drop this soft transition and do not commit to keep such old VMs running.
[1] https://kubevirt.io/user-guide/virtual_machines/interfaces_and_networks/#passt
[2] https://github.com/kubevirt/kubevirt/pull/10866
[3] https://kubevirt.io/user-guide/virtual_machines/net_binding_plugins/passt
Before this PR:
After this PR:

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer
Notification for the deprecation and removal has been communicated through the mailing list and v1.2 release, where warnings have been posted to users when passt configuration was detected.
This final removal is following with the original plan.

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

The 'passt' core network binding is discontinued and removed.

Changes: updated the last two commits messages

This change make the code more testable in a way it doesnt depend on production code feature-gates info (GA/Deprecated..).

The suggested change is an overkill at this stage.
You can simply allow registration of feature-gates, which makes sense by its own.
The only change that is needed is to add this function:
func RegisterFeatureGate(fg FeatureGate) {
	featureGates = append(featureGates, fg)
}

And changing featureGates to be a slice.

The suggested change is an overkill at this stage. You can simply allow registration of feature-gates, which makes sense by its own.
The only change that is needed is to add this function:
func RegisterFeatureGate(fg FeatureGate) {
	featureGates = append(featureGates, fg)
}

And changing featureGates to be a slice.

The suggested change merly introduce new type and converting existing function to method.
What you suggest could also work, but it means we define and expose a function just for unit tests.
Sometime there is no other option, in this case I think we can avoid it :slightly_smiling_face:

The suggested change merly introduce new type and converting existing function to method.
What you suggest could also work, but it means we define and expose a function just for unit tests.
Sometime there is no other option, in this case I think we can avoid it 🙂

Sorry, the changes suggested in this PR are an overkill IMO.
The suggested registration option can be used for production as well.
I will send a PR for this later to show it.

Sorry, the changes suggested in this PR are an overkill IMO. The suggested registration option can be used for production as well.
I will send a PR for this later to show it.

Here it is: https://github.com/kubevirt/kubevirt/pull/11968
You could use a smaller version in this PR if you prefer not to rebase over that one.

Sorry, the changes suggested in this PR are an overkill IMO. The suggested registration option can be used for production as well.
I will send a PR for this later to show it.

Here it is: #11968
You could use a smaller version in this PR if you prefer not to rebase over that one.

Thanks for the PR :slightly_smiling_face:
I dont think I can make it smaller there are two commits and both necessary.
It seems to me no smaller then the change this PR suggests, and note we need this only for unit tests.
Please consider the change this PR suggests :slightly_smiling_face:

You could use a smaller version in this PR if you prefer not to rebase over that one.

Done
Changes: The first commit of #11968 is cherry-picked, the raise warning test when deprecated API is used were changed accordingly.
Please take another look

@enp0s3 could you please have a look at the areas that are not part of sig-net? :slightly_smiling_face:

/approve
@ormergi Thank you!

/override pull-kubevirt-e2e-k8s-1.29-sig-operator
/hold for virt folks to validate
FYI @acardace @fossedihelm

/unhold
Just the usual failures we'll be addressing soon when releasing v1.2.2.

/retest-required

Unrelated failure, on etcd access in the sif0storage tests.
/test pull-kubevirt-e2e-k8s-1.28-sig-storage

authors: EdDev acardace dhiller enp0s3 ormergi


text:
Fix port collisions on spice port allocation

From the qemu network namespace refactoring patch, there was a hardcoded
spice port left which could lead to spice port allocation errors. Make
sure, that libvirt can freely choose a port on VM starts by setting the
port number explicitly to -1.
Also included a functional test, which ensures that two VMs with spice interfaces can be started on the same host, without port collissions.

retest this please

retest this please

retest this please

retest this please

retest this please


text:
Set leader metric after controller is functional

What this PR does / why we need it:
Move exposing leader Prometheus metric after the controller is functional and tighten it up with a unit test.
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:
I think we can remove the /leader endpoint.
Release note:
NONE

/retest

/approve

/retest

/retest

/retest

authors: ashleyschuett dhiller xpivarc


text:
Add SUSE to ADOPTERS.md

What this PR does / why we need it:
https://github.com/kubevirt/community/issues/110
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

Acked-by: Claudio Fontana cfontana@suse.de
--
Claudio Fontana
Engineering Manager Virtualization, SUSE Labs Core
SUSE Software Solutions Italy Srl

/lgtm

/cc @fabiand
/cc @dankenigsberg

/lgtm

Looks good Vasily. Thanks!

@vasiliy-ul  Wow!  This is amazing!  Thank you for this!
Please invite the project to speak at a SuSe event sometime.  I have inside information that the project organizer has great interest in it. ;)

/approve

authors: hw-claudio jfehlig mazzystr rmohr vasiliy-ul


text:
Feature Request: Expose host capabilities to CEL

We want to allow the user to use Kubwarden's host capabilities while writing CEL expressions.
By doing this we can extend the CEL language with Kubwarden's specific features, while keeping the compatibility with ValidatingAdmissionPolicies.
Acceptance Criteria

[x] #14
[x] #31
[x] #16
[x] #15
[x] ~Add e2e tests~ we decided to not write e2e tests as the libraries can be easily tested with a mockery generated mock
[x] Update documentation: ensure the README explains to end users how to use the host capabilities we expose
[x] Kubewarden docs: mention CEL support, link to this repository for more information about the specific language extensions we have done with this EPIC

Links to https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/
Ported examples from https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/
Ingress policy example
Sigstore policy example

[x] Move the mockery-generated mock in policy-sdk-go and release and consume v0.8.1

Closing as completed, docs are in next.

authors: fabriziosestito viccuad

repo: kubewarden/cel-policy


text:
Cannot upgrade Cassandra from 3.11.6 to 3.11.7

What happened:
While upgrading Cassandra from 3.11.6 to 3.11.7, the upgrade failed with the following error message, despite being parameter passed for NUM_TOKENS:
Error: failed to update instance for new operatorversion default/cassandra-3.11.7-1.0.3: admission webhook "instance-admission.kudo.dev" denied the request: failed to check immutable parameters for Instance default/cassandra-instance: parameter 'NUM_TOKENS' was changed to immutable in operator version cassandra-3.11.7-1.0.3 but no value was provided

What you expected to happen:
Successful upgrade from Cassandra 3.11.6 to 3.11.7
How to reproduce it (as minimally and precisely as possible):

Install Cassandra operator version 3.11.6

kubectl kudo install cassandra --app-version 3.11.6

Once the operator is up and running, trigger an upgrade to 3.11.7

kubectl kudo upgrade cassandra --instance cassandra-instance --app-version 3.11.7

OR
kubectl kudo upgrade cassandra --instance cassandra-instance --app-version 3.11.7 -p NUM_TOKENS=256

Anything else we need to know?:
No
Environment:

Kubernetes version (use kubectl version): v1.20.2
Kudo version (use kubectl kudo version): v0.18.2
Operator: cassandra
operatorVersion: 3.11.6-1.0.1, 3.11.7-1.0.2+
Cloud provider or hardware configuration: aws
OS (e.g. from /etc/os-release): ubuntu
Kernel (e.g. uname -a): 5.4.0-62-generic
Install tools:
Others:

@farhan5900 Can you recheck the scenario? I just tested this locally and it worked as expected:
aneumanns-MBP:kudo-cassandra-operator aneumann$ ./shared/vendor/kubectl-kudo upgrade cassandra --instance cassandra-instance --app-version 3.11.7
operatorversion default/cassandra-3.11.7-1.0.2 created
Error: failed to update instance for new operatorversion default/cassandra-3.11.7-1.0.2: admission webhook "instance-admission.kudo.dev" denied the request: failed to check immutable parameters for Instance default/cassandra-instance: parameter 'NUM_TOKENS' was changed to immutable in operator version cassandra-3.11.7-1.0.2 but no value was provided
aneumanns-MBP:kudo-cassandra-operator aneumann$ ./shared/vendor/kubectl-kudo upgrade cassandra --instance cassandra-instance --app-version 3.11.7 -p NUM_TOKENS=256
operatorversion default/cassandra-3.11.7-1.0.2 already installed
instance default/cassandra-instance updated
aneumanns-MBP:kudo-cassandra-operator aneumann$

@farhan5900 Can you recheck the scenario? I just tested this locally and it worked as expected:
aneumanns-MBP:kudo-cassandra-operator aneumann$ ./shared/vendor/kubectl-kudo upgrade cassandra --instance cassandra-instance --app-version 3.11.7
operatorversion default/cassandra-3.11.7-1.0.2 created
Error: failed to update instance for new operatorversion default/cassandra-3.11.7-1.0.2: admission webhook "instance-admission.kudo.dev" denied the request: failed to check immutable parameters for Instance default/cassandra-instance: parameter 'NUM_TOKENS' was changed to immutable in operator version cassandra-3.11.7-1.0.2 but no value was provided
aneumanns-MBP:kudo-cassandra-operator aneumann$ ./shared/vendor/kubectl-kudo upgrade cassandra --instance cassandra-instance --app-version 3.11.7 -p NUM_TOKENS=256
operatorversion default/cassandra-3.11.7-1.0.2 already installed
instance default/cassandra-instance updated
aneumanns-MBP:kudo-cassandra-operator aneumann$

Thanks, @ANeumann82 for checking. I also checked again, It is working fine now.

Thanks, @ANeumann82 for checking. I also checked again, It is working fine now.

repo: kudobuilder/kudo