text:
Upgrade scheduler-plugins version to v0.26.0

What this PR does / why we need it:
I upgraded the scheduler-plugins version to v0.26.0.
Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):
Fixes #
Checklist:

[ ] Docs included if any changes are user facing

Pull Request Test Coverage Report for Build 5712926246

0 of 0   changed or added relevant lines in 0 files are covered.
10 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.1%) to 40.336%

Files with Coverage Reduction
New Missed Lines
%

pkg/controller.v1/mpi/mpijob_controller.go
10
80.12%

Totals

Change from base Build 5643216133:
-0.1%

Covered Lines:
3861

Relevant Lines:
9572

💛  - Coveralls

source: gharchive/pull-request

authors: coveralls tenzen-y

repo: kubeflow/training-operator

license_type: permissive

license_source: github-api


text:
update ibmcloud ks cluster config command

the doc referes to
ibmcloud ks cluster-config which is deprecated and will soon be unsupported.
ibmcloud ks cluster config is recommended.

This change is

@Tomcli

Thanks @moficodes
/lgtm
/ok-to-test

Thanks both!
/approve

authors: Tomcli moficodes sarahmaddox

repo: kubeflow/website


text:
Remove "in Kubeflow" from "Multi-Tenancy"

See #2465

@Bobgy can you please approve? :)

/lgtm
/approve
Thank you！

authors: Bobgy RFMVasconcelos


text:
Adjusted header and footer to open external links in new tab.

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

This change is

Preview: https://deploy-preview-500--competent-brattain-de2d6d.netlify.com/

/assign @abhi-g


text:
CronjobTrigger retry logic appears faulty, doesn't allow for startup

Is this a BUG REPORT or FEATURE REQUEST?: BUG Report
What happened: When a Function and its driving CronJobTrigger are created together, chances are slim that the CronJobTrigger would find the corresponding function. There is supposed to be an exponentially increasing timeout in retrying but it seems that it's not working as intended. After a re-deploy to the CronJobTrigger resource, the function is found.
What you expected to happen: I expected the cronjob-trigger-controller to eventually find the function it should evoke, but it fails to start up.
How to reproduce it (as minimally and precisely as possible): Set up Kubeless. Create a single kubernetes manifest file, or a helm chart that creates a function and a trigger together (real-life usecase is when setting up a cron-task, you'd co-locate the function and it's trigger in the same helm chart, for example). Try installing the chart/manifest. If it worked, try again. <50% chance I'm seeing that it's actually finding the function.
Anything else we need to know?:
I trimmed some irrelevant parts of the logs. I'm getting the impression that the exponential retry logic is not really working as intended, because the logs show that the 5x retries are burnt through within a second (the timestamps are the same).
time="2021-02-23T09:51:04Z" level=info msg="Running Kubeless cronjob trigger controller version: v1.0.3"
time="2021-02-23T09:51:04Z" level=info msg="Starting Cron Job Trigger con...
time="2021-02-23T09:51:04Z" level=info msg="Cronjob Trigger controller cac...
time="2021-02-23T09:51:04Z" level=info msg="Cron Job Trigger controller syn...
time="2021-02-23T10:04:29Z" level=info msg="Processing update to CronJo...
time="2021-02-23T10:04:29Z" level=error msg="Unable to find the function cleanup...
time="2021-02-23T10:04:29Z" level=error msg="Error processing kubeless/cleanup (will retry): ...
time="2021-02-23T10:04:29Z" level=info msg="Processing update to CronJob Trigg...
time="2021-02-23T10:04:29Z" level=error msg="Unable to find the function clea..
time="2021-02-23T10:04:29Z" level=error msg="Error processing kubeless/cleanup (will retry): ...
time="2021-02-23T10:04:29Z" level=info msg="Processing update to CronJo...
time="2021-02-23T10:04:29Z" level=error msg="Unable to find the function cle...
time="2021-02-23T10:04:29Z" level=error msg="Error processing kubeless/cleanup (will retry): ...
...
time="2021-02-23T10:04:29Z" level=error msg="Error processing kubeless/cleanup (will retry): ...
time="2021-02-23T10:04:29Z" level=info msg="Processing update to CronJob Tr...
time="2021-02-23T10:04:29Z" level=error msg="Unable to find the function cleanup...
time="2021-02-23T10:04:29Z" level=error msg="Error processing kubeless/cleanup (will retry): ...
time="2021-02-23T10:04:29Z" level=info msg="Processing update to CronJo...
time="2021-02-23T10:04:29Z" level=error msg="Unable to find the function cleanup...
time="2021-02-23T10:04:29Z" level=error msg="Error processing kubeless/cleanup (giving up): ...
E0223 10:04:29.445826       1 cronjob_trigger_controller.go:186] functions.kubeless.io "cleanup" not found

Environment:

Kubernetes version (use kubectl version): v1.18.10
Kubeless version (use kubeless version): v1.0.8
Cloud provider or physical cluster: AWS Kubernetes

Hi @delanni,
I agree, that's weird, we should probably check the retry logic there. To unblock you, maybe you can try to use helm hooks to install both resources at different stages? You can try to install the CronJobTrigger in the post-install hook for example.

Thanks for the suggestions @andresmgot! I'll check out what I can do with hooks for now. Our plan with Kubeless is to simplify our architecture a bit, but if we have to hack around, it wouldn't result in altogether optimization :)
Having looked into the issue, it's probably not a proper bug, simply a bit over-optimistic config:
https://github.com/kubeless/cronjob-trigger/blob/93203511328d6cb770e04067169a19155fe4cbc2/vendor/k8s.io/client-go/util/workqueue/default_rate_limiters.go#L41
Starting out with 5ms, if we're upping to the 4th exponent, it's still only 2^4*5 = 80ms, with the sum total of <160ms.
If you agree with an adjustment in this area, I'd either suggest retrying ~10x (so the change is only local to the specific creation retries) or adjust the base timeout to 150ms (which would mean a total wait of 5s, which is still OK in human time).
What do you think? Maybe this could be a config param?

Yes, unfortunately, with helm's hooks, I'd need to have some executors prepared with kubeless and potentially kubectl prepared on an image so I can fire off the setup request afterwards, so it's not an option for the simplification :)

right, we could either increase that base timeout or just increase the number of retries:
https://github.com/kubeless/cronjob-trigger/blob/master/pkg/controller/cronjob_trigger_controller.go#L43
If we do 10 retries rather than 5, the wait step goes up until ~5s, which should be more than enough. Would you mind sending a PR? The CI can build an image that you can use afterwards to check if that will fix your issue.

Yes, unfortunately, with helm's hooks, I'd need to have some executors prepared with kubeless and potentially kubectl prepared on an image so I can fire off the setup request afterwards, so it's not an option for the simplification :)

mmh, that should not be needed. You would create the same manifests, just adding the hook annotation for the trigger to be created after the rest is installed:
https://helm.sh/docs/topics/charts_hooks/
But maybe I am unaware of some requirements of your setup.

You're right. I thought I should try to create the resource with the kubeless cli in a post-install hook (as if post-install hooks were scripts, like in most other systems I know). But in fact, the hooks here are resources, so I can fit the triggers there. I'll give that a shot, thanks for recommending! :)

I missed your first suggestion, I

source: gharchive/issue

authors: andresmgot delanni

repo: kubeless/cronjob-trigger


text:
The role created by helm chart has no enough permission for client to connect

Hi, nice project.
My team works on a cluster which we expect to have permissions as strict as possible. This means we don't even want to provide the clients with permissions like creating pods, etc.. So I deployed kubevpn using helm chart, and according to #332, I would expect that creating a kubeconfig for the service account kubevpn-traffic-manager and distribute it to others will be okay. However it seems the permission is not enough (I have do some tests and i will show which permissions are missed later below).
Still i wonder if the service account created by helm chart is for the purpose of creating kubeconfig for clients to use, or it's for internal pods only and i am using it wrongly?
And what's more, the Role provided in https://github.com/kubenetworks/kubevpn/issues/332#issuecomment-2348019063 doesn't seem to work too, at least in my case. It still needs create pods/portforward and create pods/exec to properly work. Its using an asterisk is also not clear enough and not ensuring minimal permissions.
FYI: Here's how I managed to modify the kubevpn-traffic-manager Role created by the helm chart to work as a kubeconfig, as well as corresponding code lines:

requires list pods and list services https://github.com/kubenetworks/kubevpn/blob/9edf0122a719c730c0537a1775b06ee7a6f78090/pkg/handler/connect.go#L435

requires create pods/portforward https://github.com/kubenetworks/kubevpn/blob/9edf0122a719c730c0537a1775b06ee7a6f78090/pkg/handler/connect.go#L217

requires get pods and create pods/exec https://github.com/kubenetworks/kubevpn/blob/9edf0122a719c730c0537a1775b06ee7a6f78090/pkg/handler/connect.go#L242

NO

Hi, nice project.
My team works on a cluster which we expect to have permissions as strict as possible. This means we don't even want to provide the clients with permissions like creating pods, etc.. So I deployed kubevpn using helm chart, and according to #332, I would expect that creating a kubeconfig for the service account kubevpn-traffic-manager and distribute it to others will be okay. However it seems the permission is not enough (I have do some tests and i will show which permissions are missed later below).
Still i wonder if the service account created by helm chart is for the purpose of creating kubeconfig for clients to use, or it's for internal pods only and i am using it wrongly?
And what's more, the Role provided in #332 (comment) doesn't seem to work too, at least in my case. It still needs create pods/portforward and create pods/exec to properly work. Its using an asterisk is also not clear enough and not ensuring minimal permissions.
FYI: Here's how I managed to modify the kubevpn-traffic-manager Role created by the helm chart to work as a kubeconfig, as well as corresponding code lines:

requires list pods and list services https://github.com/kubenetworks/kubevpn/blob/9edf0122a719c730c0537a1775b06ee7a6f78090/pkg/handler/connect.go#L435
requires create pods/portforward https://github.com/kubenetworks/kubevpn/blob/9edf0122a719c730c0537a1775b06ee7a6f78090/pkg/handler/connect.go#L217
requires get pods and create pods/exec https://github.com/kubenetworks/kubevpn/blob/9edf0122a719c730c0537a1775b06ee7a6f78090/pkg/handler/connect.go#L242

No you are not wrong.

#332 permission is for client usage. attention pod verb "*", means client can list/create/update pod. but  can use more strict. as you say. (list pod,create pods/portforward, get pod, create pod/exec). those permission is minimum
helm chart serviceaccount is not use for client, just for server.

Of course, #332 permission is too open, we can make a list to point out which permission is really needs.

As long as I've tested on my local cluster created via kind, k8s v1.31.2, pods with verb * does not cover create pods/portforward and create pods/exec , so that from #332 is not directly usable, but still needs these two

helm chart serviceaccount is not use for client, just for server.

Understood, so its my own responsibility to create a service account for kubeconfig to use. Hopefully we can have this use case added to the doc page with a proper set of permissions? I don't think providing average developers with overly open permissions is a good idea.

Ok, got it .
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubevpn-traffic-manager
rules:
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["pods/portforward", "pods/exec"]
  verbs: ["create"]

i made a permission list for client usage, but without tested it 😂

As long as I've tested on my local cluster created via kind, k8s v1.31.2, pods with verb * does not cover create pods/portforward and create pods/exec , so that from #332 is not directly usable, but still needs these two

helm chart serviceaccount is not use for client, just for server.

Understood, so its my own responsibility to create a service account for kubeconfig to use. Hopefully we can have this use case added to the doc page with a proper set of permissions? I don't think providing average developers with overly open permissions is a good idea.

Yes, after we discussed, we can add doc for client minimum permission

Ok, got it .
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubevpn-traffic-manager
rules:
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["pods/portforward", "pods/exec"]
  verbs: ["create"]

i made a permission list for client usage, but without tested it 😂

Let's use this as minimum permission for now ~

repo: kubenetworks/kubevpn

license: MIT


text:
Revert "Fix kubernetes version in kubeadm"

Reverts kubenow/KubeNow#138

No need for this

authors: andersla mcapuccini

repo: kubenow/KubeNow

license_source: bigquery


text:
[BUG] 双栈子网场景，虚拟机仅指定 ipv4地址，log 显示已分配 v6地址，但是 annotation没记录上

Kube-OVN Version
release-1.12-mc
Kubernetes Version
1.21.5
Operation-system/Kernel Version
4.19
Description

Steps To Reproduce

创建虚拟机仅指定v4地址，实际使用双栈网络
等待虚拟机 pod Running， 可以看到虚拟机一直未创建出来

Current Behavior

Expected Behavior

创建虚拟机仅指定v4地址，实际使用双栈网络
虚拟机可以创建出来

这应该是 kubevirt 的bug，kubevirt 会对 annotaion 进行 reconcile

repo: kubeovn/kube-ovn


text:
fix : null 처리 및 Object Storage 설정 변경

요약
테스트 중 버그 수정 및 설정 변경입니다.
변경 사항 설명
1. null 처리
FeedSummaryDto에 null 처리가 안되어있는 부분을 처리했습니다.
2. Object storage 설정 추가
이제 Object storage에 사진이나 영상 등 파일을 넣으면 무조건 공개가 되도록 수정했습니다.
관련 이슈 및 참고 자료
없음

확인했습니다.

repo: kuberMAPtes/noon-main-api-server


text:
Monocular api download repo even repo is not configured.

I commented out repo setting on values.yaml because it takes too long to synchronize repo.
api:
  ...
  config:
    repos:
      # Official repositories
      #- name: stable
      #  url: https://kubernetes-charts.storage.googleapis.com
      #  source: https://github.com/kubernetes/charts/tree/master/stable
      #- name: incubator
      #  url: https://kubernetes-charts-incubator.storage.googleapis.com
      #  source: https://github.com/kubernetes/charts/tree/master/incubator
      # Add your own repository
  ...

But it looks like that Monocular api pod is downloading repo.
Is it working properly?.
$ kubectl get pods -n monocular
NAME                                            READY     STATUS             RESTARTS   AGE
monocular-mongodb-779c69c4b8-ldd8w              1/1       Running            0          41m
monocular-monocular-api-5566949b68-62p4r        0/1       CrashLoopBackOff   3          9m
monocular-monocular-prerender-cdc9449bf-bvf4f   1/1       Running            0          41m
monocular-monocular-ui-59948df86d-hphcw         1/1       Running            0          9m

$ kubectl logs -f monocular-monocular-api-5d894ff7d6-9d4j6 -n monocular
time="2018-05-02T08:15:13Z" level=info msg="Configuration bootstrap init" configFile="/monocular/config/monocular.yaml"
time="2018-05-02T08:15:13Z" level=info msg="Configuration file found!"
time="2018-05-02T08:15:13Z" level=info msg="Loading CORS from config file"
time="2018-05-02T08:15:13Z" level=info msg="Loading repositories from config file"
time="2018-05-02T08:15:13Z" level=info msg="Configuration bootstrap finished"
time="2018-05-02T08:15:13Z" level=info msg="Using cache directory" path="/monocular/repo-data"
time="2018-05-02T08:16:22Z" level=info msg="Deprecated chart skipped" name=stash
time="2018-05-02T08:16:22Z" level=info msg="Deprecated chart skipped" name=aws-cluster-autoscaler
time="2018-05-02T08:16:22Z" level=info msg="Deprecated chart skipped" name=kubedb
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=gitlab-ce
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=swift
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=voyager
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=kube-lego
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=dask-distributed
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=telegraf
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=nginx-lego
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=searchlight
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=sugarcrm
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=gitlab-ee
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=g2
time="2018-05-02T08:16:23Z" level=info msg="Deprecated chart skipped" name=kubed
time="2018-05-02T08:16:23Z" level=info msg="Local cache missing" name=mongodb-replicaset version=2.1.3
time="2018-05-02T08:16:23Z" level=info msg="Downloading metadata" dest="/monocular/repo-data/stable/mongodb-replicaset/2.1.3/chart.tgz" source="https://kubernetes-charts.storage.googleapis.com/mongodb-replicaset-2.1.3.tgz"
time="2018-05-02T08:16:23Z" level=info msg="Local cache missing" name=openebs version=0.5.3
time="2018-05-02T08:16:23Z" level=info msg="Downloading metadata" dest="/monocular/repo-data/stable/openebs/0.5.3/chart.tgz" source="https://kubernetes-charts.storage.googleapis.com/openebs-0.5.3.tgz"
time="2018-05-02T08:16:23Z" level=info msg="Local cache missing" name=mongodb version=2.0.2
time="2018-05-02T08:16:23Z" level=info msg="Downloading metadata" dest="/monocular/repo-data/stable/mongodb/2.0.2/chart.tgz" source="https://kubernetes-charts.storage.googleapis.com/mongodb-2.0.2.tgz"

@YunSangJun if no repos are provided it defaults to the stable and incubator ones! You could try setting 1 small repository (this one, for example).

@prydonius Ok. Thanks. I'll try it.

authors: YunSangJun prydonius

repo: kubernetes-helm/monocular


text:
Remove /run mount for backward compatibility with docker.

For https://github.com/containerd/containerd/issues/1494.
Remove /run mount because Docker doesn't do that, and there are images relying on this behavior.
In we really want to make /run tmpfs in the future, we may need to handle copyup.
Signed-off-by: Lantao Liu lantaol@google.com

/cc @ijc

LGTM. I wonder if we could construct an overlay with a tmpfs (or perhaps disposable real fs) upperdir rather than doing a copy up?

LGTM. I wonder if we could construct an overlay with a tmpfs (or perhaps disposable real fs) upperdir rather than doing a copy up?

Sorry, I maybe using the wrong term. I just mean create the tmpfs volume on the host, copy content from rootfs to the volume, and mount it into the image.

Apply LGTM based on https://github.com/kubernetes-incubator/cri-containerd/pull/233#issuecomment-328293940.

authors: Random-Liu ijc

repo: kubernetes-incubator/cri-containerd


text:
Build with go install

Closes: #313

Another issue I see while testing:
 make install.tools
go get github.com/vbatts/git-validation
go get github.com/alecthomas/gometalinter
gometalinter --install
Installing:
  aligncheck
  staticcheck
  varcheck
  lll
  gas
  gocyclo
  golint
  gosimple
  gotype
  ineffassign
  interfacer
  misspell
  deadcode
  goconst
  goimports
  unconvert
  dupl
  errcheck
  structcheck
  unused
can't load package: package github.com/HewlettPackard/gas: cannot find package "github.com/HewlettPackard/gas" in any of:
	/usr/lib/golang/src/github.com/HewlettPackard/gas (from $GOROOT)
	/home/mrunal/go/src/github.com/alecthomas/gometalinter/vendor/src/github.com/HewlettPackard/gas (from $GOPATH)
WARNING: failed to install one or more linters: exit status 1 (installing individually)
can't load package: package github.com/HewlettPackard/gas: cannot find package "github.com/HewlettPackard/gas" in any of:
	/usr/lib/golang/src/github.com/HewlettPackard/gas (from $GOROOT)
	/home/mrunal/go/src/github.com/alecthomas/gometalinter/vendor/src/github.com/HewlettPackard/gas (from $GOPATH)
WARNING: failed to install github.com/HewlettPackard/gas: exit status 1
gometalinter: error: failed to install the following linters: github.com/HewlettPackard/gas
make: *** [Makefile:167: .install.gometalinter] Error 1

Debugged @mrunalp's problem, turns out there was a gometalinter already installed in /usr/bin. We've decided to address the problem by installing tools to GOPATH/bin and searching in there instead, so that we always use a local copy of tools.

Builds and tests fine on my system

Tests work here, too (except #322).

LGTM

@runcom @rhatdan @sameo @cyphar PTAL

This should fix #311 as well.

Awesome, great job @jawnsy

I'll run tests locally (given the known ping host failure) and merge in a while.

everything works fine on my system :) (except that now I have to run sudo GOPATH=$GOPATH make localintegration to run tests, but that's fine)

Thanks @jawnsy

Thanks for the quick review & merge, @runcom!

@runcom About the GOPATH, you can use sudo -E to preserve your environment variables (including GOPATH). In a follow-up, I'll look at building the test binary as non-root (looking at the docs for go test it looks possible) and sudo running the test program.

sigh Now everything breaks on my system and I can no longer build cri-o. Was the old system really so broken that it needed to be replaced with another system that doesn't work as well as the old one? Not to mention the fact that it was broken after two or three days of review -- given that it's holiday season maybe it's a bit odd to expect that nobody was too busy to read their backlog of ~700 emails?

In particular, this thing that I don't understand is the logic behind this change -- go install combines the compilation and installation of binaries. I don't know of a single distribution where this is how the build process works -- deb, rpm and PKGBUILD all have separate "build" and "install" sections.
So the real question is, who is the Makefile targeted at?

Not to mention that as far as I can tell, go install will install the static libraries and I cannot find where it's shoved the compiled binaries. Remind me how this is better again?

Oh, and I currently cannot find where the binaries are installed (it's not in $GOPATH/pkg)... THIS is why distributions don't use the Makefiles of upstream Go projects -- because Go makes it ridiculously easy to break the build system.

After reading the discussion in #313 I can see why you wanted this @jawnsy. However here are a few points:

The vendor/src -> vendor change means you cannot compile with older versions of Go. And also now certain GOPATH tricks no longer work (and no, you can't fix them with symlinks). Okay, maybe we don't care about this.

go install is a touch too magical for me. In particular, it doesn't produce single binaries -- it attempts to install things as well (in essentially random paths). And that then doesn't work for me at all (it just generates .a files), not to mention that it breaks the package building process of all distributions that I'm aware of.

So we really need to consider what purpose our Makefile serves. If you want to use go install, that's fine -- but lets not break the Makefile in order to make it so that distributions can no longer use our Makefile...

authors: cyphar jawnsy mheon mrunalp runcom

repo: kubernetes-incubator/cri-o


text:
Fix container/sandbox list.

For https://github.com/kubernetes-incubator/cri-tools/issues/179.
This PR:

Added -l and -n in crictl sandboxes.
Fix container list order, latest created container should be on top.
Change sandbox to sort by created timestamp, too. @yanxuean Are you ok with that? If user want to know sandboxes in the same namespace, they could always use --namespace to filter.

Signed-off-by: Lantao Liu lantaol@google.com

Change sandbox to sort by created timestamp, too. @yanxuean Are you ok with that? If user want to know sandboxes in the same namespace, they could always use --namespace to filter.

I am OK.

/lgtm

authors: Random-Liu yanxuean

repo: kubernetes-incubator/cri-tools


text:
In-memory implementation of storage

Issue: https://github.com/kubernetes-incubator/external-dns/issues/44
This is first step for implementing storage, the functionality provided in this PR supposed to:

[x] Provide in-memory dnsprovider - closed in https://github.com/kubernetes-incubator/external-dns/pull/59
[x] Make use of in-memory dns provider to create simple in-memory non-persistent storage with test coverage
[x] Write proposal for storage

More details come later

@linki please review

@ideahitme Will do. I love your well-structured code in this PR 👍

As per the latest discussion (which I already documented here https://github.com/kubernetes-incubator/external-dns/pull/114) do you guys think I should continue on this PR ?
Since this PR does not put storage into the application flow, I was thinking we can merge this and we could iterate on it to implement the changes ? What do you think ? Or I could start another PR to which I could include commits from this PR ?
/cc @linki

Whichever way you recommend is fine with me. How much would we add to master that we actually don't want? (Didn't take a closer look, yet)

/cc @iterion @justinsb
As per discussion with @linki, will close this PR and create a new one with better approach for implementing ownership, as described in the doc: https://github.com/kubernetes-incubator/external-dns/pull/114

authors: ideahitme linki

repo: kubernetes-incubator/external-dns


text:
[cephfs-provisioner] PVC creation shouldn't fail if the ceph user secret already exists

[cephfs-provisioner] When using deterministicNames: true creating a PVC, deleting it and creating it afterwards may fail because the ceph user secret already exists.
This could be solved by just doing:
apierrors "k8s.io/apimachinery/pkg/api/errors"
[...]
if err != nil && !apierrors.IsAlreadyExists(err) {
                klog.Errorf("Cephfs Provisioner: create volume failed, err: %v", err)
                return nil, fmt.Errorf("failed to create secret")
 }

I'm glad to do a PR with this, I'm just having a hard time building the provisioner due to this:
https://github.com/kubernetes-incubator/external-storage/issues/1150
If you help me sort this out I could test it in my own clusters.

@humblec Did you finally take a look at this?

@fcgravalos you can try this PR https://github.com/kubernetes-incubator/external-storage/pull/1122 to resolve #1150 and then send a PR with the fix for this issue.

Thanks @humblec I'll try that out later and submit a PR if I manage to fix it

hey @humblec I merged your PR in my fork and I was able to test my changes :). It works! I'm moving forward with a PR :)

@humblec you were assigned to the PR :)
If we merge it, we'll merge your changes to fix the build too :)

authors: fcgravalos humblec

repo: kubernetes-incubator/external-storage


text:
Add --wait flag to svcat commands

Waits for the operation to complete (or fail). Use in conjunction with the --timeout 30s flag to limit how long svcat will wait before giving up. Timeout is a human readable golang duration, like 1us, 20ms, 50ns, 100s, 2m, 1h.
$ svcat provision --wait

$ svcat bind --wait

$ svcat deprovision --wait

#  waits for all bindings associated with the instance to be deleted.
$ svcat unbind INSTANCE

$ svcat unbind --name BINDING --wait

I went back and forth on if wait should be the default or not. Ultimately I decided that it shouldn't because that's inconsistent with kubectl, and for the most part other clis as well don't wait by default. Also it seems more clear when you say --wait --timeout 5m instead of just a timeout by itself which may make you think that it applies to the operation and not the wait.
Part 1 of #1736 that covers the following svcat commands: provision, deprovision, bind and unbind.

I want to tackle next moving the svcat tests to our e2e tests so that they hit a real cluster instead of the test http server. I think it will be easier to test stuff like this (and the other mutating verbs) once we are moved over.

Right now this is how the svcat tests work:

I recorded the json body returned from the api server for requests like "get serviceclasses" and saved them in cmd/svcat/testdata/responses
The svcat tests have a test httpserver than converts the requested url into a path to the recorded response in that directory and returns the file contents.
The tests then compare the output from the cli to the golden file output in cmd/svcat/testdata/output.

I've gotten a bit of flack over how this all works (both when I first donated the code and later). People have said that they would prefer that the tests either use the fake clients (I didn't know that existed at the time), or were changed to e2e tests that actually hit the binary from the shell. A big part of that is that setting up new testdata or updating it is not straightforward.
Since the tests all work against a live ups-broker (that's the testdata that I recorded), I figured it would be easy to change the tests to run as e2e tests and also add tests for verbs that mutate state (which we don't test right now at all).
That was a long explanation, maybe the discussion should be moved into the existing issue https://github.com/kubernetes-incubator/service-catalog/issues/1810? 😀

As a side note, I'm making a kubectl plugin that will help you do the same thing but for pods and deployments. ✨

This is what it looks like when the timeout is hit before the operation is complete
$ svcat provision iloveponies --class mysql --plan 5-7-14 --wait --timeout 1ns
  Name:        iloveponies
  Namespace:   default
  Status:
  Class:       mysql
  Plan:        5-7-14

Parameters:
  {}
Error: timed out waiting for the condition

LGTM, svcat continues to rock!

This looks neat. You should add a test in each of the files in pkg/svcat/service-catalog for the new methods you added. Hopefully that isn't too hard to figure out, if not I could pair with you and write some ginkgo tests.

--interval looks nice, thanks for adding that! LGTM

fix the test before merging if that error is real...

repo: kubernetes-incubator/service-catalog


text:
Switch to use multi stage build for container

Switch to use multi-stage build
remove wildcard match in dockerignore
update e2e test to not build binary separately

/cc @M00nF1sh

/lgtm
/approve


text:
pkg/descheduler/strategies: fix typo

Signed-off-by: Mateusz Gozdek mgozdekof@gmail.com

While you're at it can you also fix this one:
https://github.com/kubernetes-sigs/descheduler/blob/master/pkg/descheduler/pod/pods.go#L111
switcheds > switches

It may be worth importing the script hack/verify-spelling.sh from from the kubernetes repo

/ok-to-test
/lgtm
/assign @damemi
/kind cleanup

On a separate note, it may be worth importing the script hack/verify-spelling.sh from from the kubernetes repo

I was testing with codespell, so I probably didn't catch all of them.

/lgtm

Opened a PR to add the verify script in https://github.com/kubernetes-sigs/descheduler/pull/430

authors: damemi farah invidian seanmalloy

repo: kubernetes-sigs/descheduler


text:
GRPCRoute docs on matching rules are unclear

There are no examples or docs on specifying only the service name in matching rules like so:
  rules:
    - matches:
        - method:
            service: package.name.version.Service

There is a matching rule example for when you match by service name and header value, but nothing for arguably the most common use case of routing by only the service name.

@rauanmayemir can you explain this issue little more, like what documentation updation are needed?

@Nishant-k-sagar currently it makes it look like I can't specify routes that will match only by the serviceName. It may seem trivial, but it is the most obvious use case and not having it as a first basic example is surprising to me.
It's like if HTTPRoute didn't have examples for /user and only had a list of /user/login, /user/logout, /user/profile, that would lead to wondering if I can group match or do I have to write out all the possible endpoints.
Maybe it's unrelated, but cilium implementation does not support the way to do it: https://github.com/cilium/cilium/issues/34079

authors: Nishant-k-sagar rauanmayemir

repo: kubernetes-sigs/gateway-api


text:
Stop relying setting RemoveSelfLink=false feature-gate - we're locking it to true with GA graduation in 1.24

Upstream Kubernetes is going to get rid of ability to set SelfLink in release 1.24 (basically graduate graduate RemoveSelfLink feature gate to stable - see the KEP https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1164-remove-selflink, for a bit more details).
It seems that kube-batch is still vendoring Kubernetes version that is setting it to false:
https://github.com/kubernetes-sigs/kube-batch/blob/master/vendor/k8s.io/apiserver/pkg/features/kube_features.go#L141
This is one more heads'up to stop relying on it (if you do in any place).

Sure - fixed

/close

authors: ArangoGutierrez wojtek-t

repo: kubernetes-sigs/kube-batch


text:
[Prow Plugin] Make removing sig tags operations sticking after rebases

Pattern we see during sig api-machinery triaging:
Twice a week, we scrape all PRs/Issues with sigs/api-machinery labeled, we manually remove the sig label for PRs falls outside of the sig. Once the PR is rebased, the sig label will be added back (respecting the OWNERS file)
We probably can provide options to make sig label removal operations sticking to reduce the triaging toils
cc @henrywu573 @jpbetz

Why not update the OWNERS file to stop inaccurately labeling it? :-)

The labeling itself is accurate, imagine upon rebase the touched content for that sig remains the same, but we always re-apply the label

The labeling itself is accurate, imagine upon rebase the touched content for that sig remains the same, but we always re-apply the label

We apply the label only if your PR diff contains a file under one of the OWNERS files. It's looking at the PR's patch, not the git push. (If it's not, that's the bug, but I'm pretty sure that's not it).
When you rebase, the label gets applied again because you are in fact PRing a file that is under one of the OWNERS configured with the SIG label.
The only broken case by lack of feature currently is if someone pushes a bad diff that touches lots of files, then decides to stop modifying those files, we don't remove the label because we don't distinguish between how the label was added.
But in that case, pushing the PR again should not re-label it, and this case isn't that common, and would only require manually fixing the label once. Checking for this on every push could eat a lot of API calls since we'd have to look for if the bot previously added the label. (Also, the labels supported are arbitrary, it's not actually just SIG labels).
However in the case that the PR does touch a file under one of the api machinery OWNERS, then it will be re-labeled on every push and attempting to manually remove it is the wrong fix versus updating the OWNERS files.
I observe mostly the latter.

then sounds like the triaging process is not optimal (as we currently remove the sig label for PRs we think other sig should review) - instead we should have some new mechanism, or have a new triaging state (like /sig-api-machinery-triaged, and we can update the filter to exclude these PRs)

The label can be manually added by the author or reviewers but ... yeah I agree the process is not optimal.

authors: BenTheElder krzyzacy

repo: kubernetes-sigs/prow


text:
cleanup release.md

Add a line jump to fix rendering
Remove outdated release info

Thanks!
/lgtm
/approve

authors: hbagdi robscott

repo: kubernetes-sigs/service-apis


text:
Running redis without a password - discussion or PR?

Ahoy!
I want to run redis in my trusted network, not exposed to the internet, and I think that the redis docs imply that that is the primary way that redis was designed to be used. Unfortunately, I think the stable helm chart here does not expose a way to configure redis without a password.
I'm not sure what the process is like in this repo for suggesting changes. Would you all be interested in further discussion about this? I'd be happy to work on a PR for making passwords optional, but I'm not sure that a) that change would be welcome or b) what style of configuration is conventional for turning off security in an official Helm chart.
I hope this makes sense! Please let me know if I can clarify or if I'm misunderstanding something.

#378

Closing in favor of #378.

authors: lachie83 rileylark seanknox

repo: kubernetes/charts


text:
[stable/testlink]

Is this a request for help?: Y

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
FEATURE REQUEST

Version of Helm and Kubernetes:
Any
Which chart:
stable/testlink
Hi I am happy this chart exists, thank you.
Could you please add an ingress template like:
{{- if .Values.ingress.enabled -}}
{{- $fullName := include "fullname" . -}}
{{- $servicePort := .Values.service.port -}}
{{- $ingressPath := .Values.ingress.path -}}
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: {{ $fullName }}
  labels:
    app: {{ template "name" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
{{- with .Values.ingress.annotations }}
  annotations:
{{ toYaml . | indent 4 }}
{{- end }}
spec:
{{- if .Values.ingress.tls }}
  tls:
  {{- range .Values.ingress.tls }}
    - hosts:
      {{- range .hosts }}
        - {{ . }}
      {{- end }}
      secretName: {{ .secretName }}
  {{- end }}
{{- end }}
  rules:
  {{- range .Values.ingress.hosts }}
    - host: {{ . }}
      http:
        paths:
          - path: {{ $ingressPath }}
            backend:
              serviceName: {{ $fullName }}
              servicePort: http
  {{- end }}
{{- end }}

Thank you very much
Regards Seyhbold

/remove-lifecycle stale


text:
[stable/concourese]add app description   which provide app abstract for project dashboard

add app description which provide app abstract for project dashboard,releated app description

/lifecycle frozen

authors: prydonius zouyee


text:
[stable/verdaccio] Upgrade version, add logo and fix documentation

upgrade Verdaccio to 2.7.0
add logo, keywords and additional source
fix documentation

/ok-to-test

/lgtm

authors: etiennetremel unguiculus


text:
DO NOT MERGE: Testing functional tests

Testing for #369

Great success!!!! :1st_place_medal:


text:
[stable/prometheus] add required tillerVersion to Chart.yaml

In reaction to #3546, users reported issues with tiller 2.7. This PR adds tillerVersion: ">2.8.0" to Charts.yaml. Additionally, it fixes some typos.

/assign @unguiculus

/hold
The Charts CI system is still using tiller 2.7. We need to upgrade that.

/hold cancel

/assign @gianrubio

/lgtm
/ok-to-test

How is this possible?
Chart incompatible with Tiller v2.10.0-rc.1

@instigardo what's the error?

authors: gianrubio hoesler instigardo mattfarina unguiculus


text:
Incorrect error reporting if clusterrole.rules resources not pluralised (configmap instead of configmaps)

With RBAC enabled, setting the ClusterRole to -
...
- apiGroups: [""]
  resources: ["configmap"] // Instead of configmaps
  verbs: ["get", "watch", "list"]
...

causes the go-client client.CoreV1().ConfigMaps("").{...} method(s) to return ERROR
"unknown (get configmaps)" instead of warning the user about an RBAC Permission denied issue, which is otherwise reported if the resource is no specified in the ClusterRole definition.

The actual error reason itself has a description that mentions forbidden, but the message itself does not.
ERROR : &errors.StatusError{ErrStatus:v1.Status{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ListMeta:v1.ListMeta{SelfLink:"", ResourceVersion:"", Continue:""}, Status:"Failure", Message:"unknown (get configmaps)", Reason:"Forbidden", Details:(*v1.StatusDetails)(0xc0002da4e0), Code:403}}

Is it a requirement that rules.resources should be specified only in the pluralized format ?

if the client is requesting configmaps, the presence or absence of a configmap authz rule should have no impact on the result from the API

Alright thanks. Will close the issue in that case.

authors: liggitt nitishm

repo: kubernetes/client-go


text:
Refer to kubectl exec - it how to call the client go API shell to interact. It's too difficult. I need help. I find many materials are non interactive

Refer to kubectl exec - it how to call the client go API shell to interact. It's too difficult. I need help. I find many materials are non interactive

This is an interactive shell I wrote. I can't use the keyboard's page up \ page down \ backspace\tab, etc
package main
import (
"bufio"
"fmt"
"k8s.io/api/core/v1"
"k8s.io/client-go/kubernetes"
"k8s.io/client-go/kubernetes/scheme"
"k8s.io/client-go/rest"
"k8s.io/client-go/tools/clientcmd"
"k8s.io/client-go/tools/remotecommand"
"log"
"os"
"sync"
"syscall"
"time"
)
type WSStreamHandler struct {
resizeEvent chan remotecommand.TerminalSize
rbuf        []byte
cond        *sync.Cond
closeSignal  syscall.Signal
closeTimeout time.Duration

ptyClosed chan struct{}

sync.Mutex

}
func GetClient() (*kubernetes.Clientset,*rest.Config,error) {
config, err := clientcmd.BuildConfigFromFlags("https://192.168.1.1:6443", "")
config.BearerToken="eyJhbGciOiJSg"

if err != nil {
	//msg := fmt.Sprint("connect api service err %v", err)
	fmt.Println("GetClient() ", "clientcmd.BuildConfigFromFlags()", "连接k8sapi错误", 0, err)
	return nil,nil,err
}

//logger.Error(err)
clientSet, err := kubernetes.NewForConfig(config)
if err != nil {
	//msg := fmt.Sprint("connect api service err %v", err)
	fmt.Println("GetClient() ", "clientcmd.BuildConfigFromFlags()", "连接k8sapi错误", 0, err)
	return nil,nil,err
}
//logger.Error(err)
//fmt.Println(reflect.TypeOf(clientSet))
return clientSet,config,nil

}
type xtermMessage struct {
MsgType string json:"type"  // 类型:resize客户端调整终端, input客户端输入
Input   string json:"input" // msgtype=input情况下使用
Rows    uint16 json:"rows"  // msgtype=resize情况下使用
Cols    uint16 json:"cols"  // msgtype=resize情况下使用
}
func runtty()  {
var	handler *WSStreamHandler
p,client,_:=GetClient()
req := p.CoreV1().RESTClient().Post().
	Resource("pods").
	Name("nginx-64646d7bc8-4d8tt").
	Namespace("test").
	SubResource("exec").
	VersionedParams(
		&v1.PodExecOptions{
			Command:   []string{"/bin/bash"},
			Stdin:     true,
			Stdout:    true,
			Stderr:    true,
			TTY:     true,
		}, scheme.ParameterCodec)

exec, err := remotecommand.NewSPDYExecutor(client, "POST", req.URL())
if err != nil {
	//msg := fmt.Sprint("connect api service err %v", err)
	fmt.Println( err)

}
handler = &WSStreamHandler{
	resizeEvent: make(chan remotecommand.TerminalSize)}
handler.cond = sync.NewCond(handler)
go handler.Run()
err = exec.Stream(remotecommand.StreamOptions{
	Stdin:  handler,
	Stdout: handler,
	Stderr: handler,
	TerminalSizeQueue: handler,
	Tty:    true,
})
handler.Write([]byte("echo aaa >> /tmp/188.txt \n\r"))
if err != nil {
	log.Println("error executor: ", err)
	handler.Write([]byte("亲，你选择的容器不存在！bye~bye~"))
	return
}

return

}
func (h *WSStreamHandler) Run() {
h.rbuf=[]byte("ifconfig \n")
reader := bufio.NewReader(os.Stdin)

for {

	cmdString, err := reader.ReadByte()

	if err != nil {
		fmt.Println(err)
	}

	h.Lock()
	h.rbuf = append(h.rbuf, cmdString)

	h.cond.Signal()
	h.Unlock()
}

}
func (h *WSStreamHandler) Read(b []byte) (size int, err error) {
h.Lock()
for len(h.rbuf) == 0 {
h.cond.Wait()
}
size = copy(b, h.rbuf)
h.rbuf = h.rbuf[size:]

h.Unlock()

return

}
func (h *WSStreamHandler) Write(b []byte) (size int, err error) {
size = len(b)
os.Stdout.Write(b)

return

}
func (h *WSStreamHandler) closeTimeoutC() <-chan time.Time {
if h.closeTimeout >= 0 {
return time.After(h.closeTimeout)
}
return make(chan time.Time)

}
func (h *WSStreamHandler) Next() (size *remotecommand.TerminalSize) {
ret := <-h.resizeEvent
size = &ret
return

}
func main()  {
runtty()

}

@871690991 did you find a solution for this ? I've been stuck for days having the same question


text:
[octavia-ingress-controller] make timeout value configuable

Is this a BUG REPORT or FEATURE REQUEST?:

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

What happened:
see https://github.com/kubernetes/cloud-provider-openstack/issues/2222#issuecomment-1530756259
What you expected to happen:
How to reproduce it:
Anything else we need to know?:
Environment:

openstack-cloud-controller-manager(or other related binary) version:
OpenStack version:
Others:

1st follow up of https://github.com/kubernetes/cloud-provider-openstack/issues/2222

Looks like solved by #2235?

yes, it's solved

authors: dulek jichenjc

repo: kubernetes/cloud-provider-openstack


text:
[OCCM] fix listener pop during iteration

What this PR does / why we need it:
Move the remove of the listener at the end of the loop.
Since the listener is a pointer and needed during the loop the removal will mess up the logic.
We observed on a k8s service with 4 ports that a load balancer listener pool were updated on every reconcile loop.
Which issue this PR fixes(if applicable):
fixes https://github.com/kubernetes/cloud-provider-openstack/issues/1795
Special notes for reviewers:
Release note:

NONE

/ok-to-test

thanks for the PR
do you mind create an issue with background and impact etc ( which is in your commit msg basically) so we can track the changes etc, thanks

and please update the header of PR to [OCCM] fix listener pop during iteration
which indicate this is for OCCM change.. thanks

@jichenjc thx for your help the issue is created

@lingxiankong @jichenjc I was able to reproduce the issue again and I will try to provide a many informations I can.
On OpenStack side there is one LoadBalancer with 2 listeners.

While iterating over service.Spec.Ports the lbaas.ensureOctaviaListeneris called to get the listener from curListenerMapping map

Right before the popListener call the listener pointing to the Name listener_0_kube_service_g04_kube-system_ingress-nginx-controller

After the popListener call, the listener is pointing to the Name listener_1_kube_service_g04_kube-system_ingress-nginx-controller and here is the problem, because we are still on the portIndex = 0 but the listener is now pointing to the wrong one and the function ensureOctaviaPool is mixing members up!

here https://go.dev/play/p/OXmDUNxHIVj you can also see the issue if you don't trust my debugger ;)

/override openstack-cloud-controller-manager-e2e-conformance-test

here https://go.dev/play/p/OXmDUNxHIVj you can also see the issue if you don't trust my debugger ;)

Thanks for the investigation @FlorinPeter, I see the issue now, the problem is caused by the line:
curListenerMapping[key] = &curListeners[i]

Here the value of curListenerMapping is a pointer which is going to be changed during the ports iteration.
So rather than moving curListeners = popListener(curListeners, listener.ID), we should change the definition of curListenerMapping to curListenerMapping := make(map[listenerKey]listeners.Listener) to avoid the potential issues in the future.
Changed version: https://go.dev/play/p/45IYjqFA2fZ

So rather than moving curListeners = popListener(curListeners, listener.ID), we should change the definition of curListenerMapping to curListenerMapping := make(map[listenerKey]listeners.Listener) to avoid the potential issues in the future.

sorry but this is a massive change and there is absolutely no benefit doing it instead of moving this function to the end!
I attached the diff of a possible change in order that you understand what implications it will have and besides that there are still if listener == nil { checks that needs to changed....
I have no clue why we need to overcomplicate such a small fix...
diff --git a/pkg/openstack/loadbalancer.go b/pkg/openstack/loadbalancer.go
index 4eabdc4..9620e20 100644
--- a/pkg/openstack/loadbalancer.go
+++ b/pkg/openstack/loadbalancer.go
@@ -1205,7 +1205,7 @@ func (lbaas *LbaasV2) buildMonitorCreateOpts(svcConf *serviceConfig, port corev1
 }

 // Make sure the pool is created for the Service, nodes are added as pool members.
-func (lbaas *LbaasV2) ensureOctaviaPool(lbID string, name string, listener *listeners.Listener, service *corev1.Service, port corev1.ServicePort, nodes []*corev1.Node, svcConf *serviceConfig) (*v2pools.Pool, error) {
+func (lbaas *LbaasV2) ensureOctaviaPool(lbID string, name string, listener listeners.Listener, service *corev1.Service, port corev1.ServicePort, nodes []*corev1.Node, svcConf *serviceConfig) (*v2pools.Pool, error) {
 	pool, err := openstackutil.GetPoolByListener(lbaas.lb, lbID, listener.ID)
 	if err != nil && err != openstackutil.ErrNotFound {
 		return nil, fmt.Errorf("error getting pool for listener %s: %v", listener.ID, err)
@@ -1334,7 +1334,7 @@ func (lbaas *LbaasV2) buildBatchUpdateMemberOpts(port corev1.ServicePort, nodes
 }

 // Make sure the listener is created for Service
-func (lbaas *LbaasV2) ensureOctaviaListener(lbID string, name string, curListenerMapping map[listenerKey]*listeners.Listener, port corev1.ServicePort, svcConf *serviceConfig, _ *corev1.Service) (*listeners.Listener, error) {
+func (lbaas *LbaasV2) ensureOctaviaListener(lbID string, name string, curListenerMapping map[listenerKey]listeners.Listener, port corev1.ServicePort, svcConf *serviceConfig, _ *corev1.Service) (listeners.Listener, error) {
 	listener, isPresent := curListenerMapping[listenerKey{
 		Protocol: getListenerProtocol(port.Protocol, svcConf),
 		Port:     int(port.Port),
@@ -1349,7 +1349,7 @@ func (lbaas *LbaasV2) ensureOctaviaListener(lbID string, name string, curListene
 		var err error
 		listener, err = openstackutil.CreateListener(lbaas.lb, lbID, listenerCreateOpt)
 		if err != nil {
-			return nil, fmt.Errorf("failed to create listener for loadbalancer %s: %v", lbID, err)
+			return listeners.Listener{}, fmt.Errorf("failed to create listener for loadbalancer %s: %v", lbID, err)
 		}

 		klog.V(2).Infof("Listener %s created for loadbalancer %s", listener.ID, lbID)
@@ -1417,7 +1417,7 @@ func (lbaas *LbaasV2) ensureOctaviaListener(lbID string, name string, curListene
 		if listenerChanged {
 			klog.InfoS("Updating listener", "listenerID", listener.ID, "lbID", lbID, "updateOpts", updateOpts)
 			if err := openstackutil.UpdateListener(lbaas.lb, lbID, listener.ID, updateOpts); err != nil {
-				return nil, fmt.Errorf("failed to update listener %s of loadbalancer %s: %v", listener.ID, lbID, err)
+				return listeners.Listener{}, fmt.Errorf("failed to update listener %s of loadbalancer %s: %v", listener.ID, lbID, err)
 			}
 			klog.InfoS("Updated listener", "listenerID", listener.ID, "lbID", lbID)
 		}
@@ -1728,7 +1728,7 @@ func (lbaas *LbaasV2) checkService(service *corev1.Service, nodes []*corev1.Node
 }

 // checkListenerPorts checks if there is conflict for ports.
-func (lbaas *LbaasV2) checkListenerPorts(service *corev1.Service, curListenerMapping map[listenerKey]*listeners.Listener, isLBOwner bool, lbName string) error {
+func (lbaas *LbaasV2) checkListenerPorts(service *corev1.Service, curListenerMapping map[listenerKey]listeners.Listener, isLBOwner bool, lbName string) error {
 	for _, svcPort := range service.Spec.Ports {
 		key := listenerKey{Protocol: listeners.Protocol(svcPort.Protocol), Port: int(svcPort.Port)}

@@ -1856,10 +1856,10 @@ func (lbaas *LbaasV2) ensureOctaviaLoadBalancer(ctx context.Context, clusterName
 	// This is an existing load balancer, either created by occm for other Services or by the user outside of cluster.
 	if !createNewLB {
 		curListeners := loadbalancer.Listeners
-		curListenerMapping := make(map[listenerKey]*listeners.Listener)
+		curListenerMapping := make(map[listenerKey]listeners.Listener)
 		for i, l := range curListeners {
 			key := listenerKey{Protocol: listeners.Protocol(l.Protocol), Port: l.ProtocolPort}
-			curListenerMapping[key] = &curListeners[i]
+			curListenerMapping[key] = curListeners[i]
 		}
 		klog.V(4).InfoS("Existing listeners", "portProtocolMapping", curListenerMapping)

@@ -1874,6 +1874,9 @@ func (lbaas *LbaasV2) ensureOctaviaLoadBalancer(ctx context.Context, clusterName
 				return nil, err
 			}

+			// After all ports have been processed, remaining listeners are removed if they were created by this Service.
+			curListeners = popListener(curListeners, listener.ID)
+
 			pool, err := lbaas.ensureOctaviaPool(loadbalancer.ID, cutString(fmt.Sprintf("pool_%d_%s", portIndex, lbName)), listener, service, port, nodes, svcConf)
 			if err != nil {
 				return nil, err
@@ -1882,9 +1885,6 @@ func (lbaas *LbaasV2) ensureOctaviaLoadBalancer(ctx context.Context, clusterName
 			if err := lbaas.ensureOctaviaHealthMonitor(loadbalancer.ID, cutString(fmt.Sprintf("monitor_%d_%s", portIndex, lbName)), pool, port, svcConf); err != nil {
 				return nil, err
 			}
-
-			// After all ports have been processed, remaining listeners are removed if they were created by this Service.
-			curListeners = popListener(curListeners, listener.ID)
 		}

 		// Deal with the remaining listeners, delete the listener if it was created by this Service previously.
@@ -2100,10 +2100,10 @@ func (lbaas *LbaasV2) ensureLoadBalancer(ctx context.Context, clusterName string
 	if err != nil {
 		return nil, fmt.Errorf("error getting LB %s listeners: %v", loadbalancer.Name, err)
 	}
-	curListenerMapping := make(map[listenerKey]*listeners.Listener)
+	curListenerMapping := make(map[listenerKey]listeners.Listener)
 	for i, l := range oldListeners {
 		key := listenerKey{Protocol: listeners.Protocol(l.Protocol), Port: l.ProtocolPort}
-		curListenerMapping[key] = &oldListeners[i]
+		curListenerMapping[key] = oldListeners[i]
 	}
 	for portIndex, port := range ports {
 		key := listenerKey{Protocol: listeners.Protocol(port.Protocol), Port: int(port.Port)}
@@ -2746,7 +2746,7 @@ func (lbaas *LbaasV2) updateOctaviaLoadBalancer(ctx context.Context, clusterName
 			return fmt.Errorf("loadbalancer %s does not contain required listener for port %d and protocol %s", loadbalancer.ID, port.Port, port.Protocol)
 		}

-		_, err := lbaas.ensureOctaviaPool(loadbalancer.ID, cutString(fmt.Sprintf("pool_%d_%s", portIndex, loadbalancer.Name)), &listener, service, port, nodes, svcConf)
+		_, err := lbaas.ensureOctaviaPool(loadbalancer.ID, cutString(fmt.Sprintf("pool_%d_%s", portIndex, loadbalancer.Name)), listener, service, port, nodes, svcConf)
 		if err != nil {
 			return err
 		}
diff --git a/pkg/util/openstack/loadbalancer.go b/pkg/util/openstack/loadbalancer.go
index 605a307..ddca8b9 100644
--- a/pkg/util/openstack/loadbalancer.go
+++ b/pkg/util/openstack/loadbalancer.go
@@ -314,18 +314,18 @@ func UpdateListener(client *gophercloud.ServiceClient, lbID string, listenerID s
 }

 // CreateListener creates a new listener
-func CreateListener(client *gophercloud.ServiceClient, lbID string, opts listeners.CreateOpts) (*listeners.Listener, error) {
+func CreateListener(client *gophercloud.ServiceClient, lbID string, opts listeners.CreateOpts) (listeners.Listener, error) {
 	mc := metrics.NewMetricContext("loadbalancer_listener", "create")
 	listener, err := listeners.Create(client, opts).Extract()
 	if mc.ObserveRequest(err) != nil {
-		return nil, err
+		return listeners.Listener{}, err
 	}

 	if err := WaitLoadbalancerActive(client, lbID); err != nil {
-		return nil, fmt.Errorf("failed to wait for load balancer %s ACTIVE after creating listener: %v", lbID, err)
+		return listeners.Listener{}, fmt.Errorf("failed to wait for load balancer %s ACTIVE after creating listener: %v", lbID, err)
 	}

-	return listener, nil
+	return *listener, nil
 }

 // DeleteListener deletes a listener.

@lingxiankong I updated the comment, can you please override the openstack-cloud-controller-manager-e2e-conformance-test and bring this to an end?
I also checked the previous versions and only 1.23 is affected as far I can see.
Is there a planned patch release or how is the patches release cadence?

No idea why the occm pod failed to create (we need to get the pod logs when it fails), but given this change shouldn't affect the deployment, so I would override the job.
/override openstack-cloud-controller-manager-e2e-conformance-test
/override openstack-cloud-controller-manager-e2e-test

/lgtm

/approve
/lgtm
a separate topic: suffering this error
/usr/local/bin/runner.sh: line 114: ./tests/ci-occm-e2e-conformance.sh: No such file or directory
guess this PR suffering same per above?

@lingxiankong the test failed, can you help to grant me owner so I can overwrite as well? Thanks

/override openstack-cloud-controller-manager-e2e-conformance-test

authors: FlorinPeter jichenjc lingxiankong ramineni


text:
Support listener timeouts as service annotations

What this PR does / why we need it: Extends support for listener timeout values to Kubernetes services via annotation
Which issue this PR fixes: fixes #588
Special notes for your reviewer: the additional createOpts for the listener are supported in gophercloud by virtue of this change https://github.com/gophercloud/gophercloud/pull/1544
Release note:

Adds support for setting timeout_client_data, timeout_member_connect, timeout_member_data, and timeout_tcp_inspect values on load balancers

/check-cla

/test cloud-provider-openstack-acceptance-test-lb-octavia

Hi, before reviewing this PR, i need more information of the original feature request, already left a comment in the issue.
just FYI, there is already a PR doing the same thing, https://github.com/kubernetes/cloud-provider-openstack/pull/422.

I've elaborated on the linked issue in a way that I hope will explain the intent of the feature. I took a look at #422 and see that it does include TimeoutClientData and TimeoutMemberData in the updateOpts, but notice that it does not address the absence of the other two timeout values (timeout_member_connect and timeout_tcp_inspect) that this change includes.

/retest

/retest cloud-provider-openstack-acceptance-test-lb-octavia

/test cloud-provider-openstack-acceptance-test-k8s-cinder

/test cloud-provider-openstack-acceptance-test-lb-octavia

/test cloud-provider-openstack-acceptance-test-csi-cinder

/test cloud-provider-openstack-acceptance-test-e2e-conformance

/lgtm
I'm satisfied with the reasons outlined in this comment. https://github.com/kubernetes/cloud-provider-openstack/issues/588#issuecomment-483434994

/ok-to-test
/approve

authors: dims hogepodge itsc0lin lingxiankong mrhillsman


text:
Update the default image name to fcp

As the image now is available at the release location.
/assign @shashidharatd

/lgtm

authors: irfanurrehman shashidharatd

repo: kubernetes/federation


text:
Nginx ingress controller + GCE Ingress = Whitelisting broken

We are running on GKE and using the latest nginx-ingress-controller:0.9.0-beta.11
We are trying to setup an Ingress controller that:

Terminates SSL for all services that are using it, so services don't have to think about that
Can be used as a firewall for incoming traffic, so has IP whitelisting

What we now have:

Nginx ingress controller with whitelist-source-range
A GCE Ingress in front of it to terminate SSL + Certifcate using ingress.gcp.kubernetes.io/pre-shared-cert & kubernetes.io/ingress.global-static-ip-name

Unfortunately, this setup doesn't work as intended with the default nginx.tmpl. This is because the $the_real_ip has the user's real IP but also the GCE HTTP load balancer IP in it, which brakes the whitelisting because it doesn't recognize the GCE LB IP and everything is denied.
So what we are trying to get is just the $remote_addr in the $the_real_ip. What we tried for this:

Using use-proxy-protocol, but this breaks nginx and isn't supported with GCE
Upload a new nginx.tmpl which ties $the_real_ip to $remote_addr, this works, but this requires us to have a custom nginx.tmpl uploaded, just for 3 lines changed.

What is the best way to continue with this? Is this a bug on the GCE ingress because it should support use-proxy-protocol or should this be fixed in the Nginx ingress so it can also support a $the_real_ip version that works for incoming GCE Ingress traffic?

@bviolier why are you using the gce ingress controller in front of nginx ingress controller? It's because of the certs or the static IP?

Upload a new nginx.tmpl which ties $the_real_ip to $remote_addr, this works, but this requires us to have a custom nginx.tmpl uploaded, just for 3 lines changed.

Please share the change.

@aledbf We have a lot of services running on subdomains with the same main domain. For that main domain, we have a wildcard uploaded in GCP. The GCE-ingress terminates all these sub-domains with the same certificate.
This makes sure that we don't have to have any certificates in k8s-secrets, but also makes sure that not every service (20+ atm) has to provide its own certificate-secret through its Ingress (as far as I know you cannot point to another namespace for secrets, so you always need to have your own secret, meaning 20 of the same certificates in different secrets).
Another possible solution would be to have nginx-ingress always use a default certificate if it doesn't have one, but as far as I know that's not an option (which makes sense).
And it's probably not the most correct solution, but I changed
   map $http_x_forwarded_for $the_real_ip {
        default          $http_x_forwarded_for;
        ''               $remote_addr;
    }

to
    map $remote_addr $the_real_ip {
        default          $remote_addr;
        ''               $remote_addr;
    }

Which is off course specific for my use-case.

@bviolier thank you for providing this information

Another possible solution would be to have nginx-ingress always use a default certificate if it doesn't have one, but as far as I know that's not an option (which makes sense).

You can use the flag --default-ssl-certificate for that.

And it's probably not the most correct solution, but I changed

I need to review this part of the template and have sections by cloud providers to avoid this issue.

@aledbf I already looked at --default-ssl-certificate, but according to the documentation this does:
NGINX provides the option server name as a catch-all in case of requests that do not match one of the configured server names.
But as I understand it, this wouldn't work in this case, because there is a server-name for all the sub-domains. Am I correct in assuming that?

@bviolier the catch-all server is not related to the flag --default-ssl-certificate but you need to add the tls section to the ingress to make this work. Something like
  tls:
  - hosts:
    - foo.bar

(no need to add secretName)
With this section in the ingress the controller will use the default certificate in your host

Thanks @aledbf, that worked for me!

Please close the issue

authors: aledbf bviolier

repo: kubernetes/ingress


text:
Update apimachinery to 1.9 and regenerate the apiserver code

Update apimachinery to 1.9 and regenerate the apiserver code.
@krousey @medinatiger @roberthbailey

/test pull-kube-deploy-build

/lgtm

authors: krousey maisem

repo: kubernetes/kube-deploy


text:
I wish /docs/user-guide/networkpolicies/ had a pointer to a precise definition of NetworkPolicy resources

This page alleges that NetworkPolicy is defined at http://kubernetes.io/docs/api-reference/extensions/v1beta1/definitions/#_v1beta1_networkpolicy but that page has no such fragment.

Now that NetworkPolicy appears in http://kubernetes.io/docs/api-reference/extensions/v1beta1/definitions/ it is no longer so difficult to find a precise definition.


text:
Removed = at the end of the flags.

This change is

/lgtm

@caesarxuchao can you please help approve this? I'm going to update this file for taint related, so hope this can be committed first. Thanks.

Merged :)

Thanks @caesarxuchao :)


text:
[1.18][ClusterLoader2] Enable custom timeouts for probes

Backport changes to 1.18 branch, enabling customization of probes timeout

/cc @mborsz

You still need to cherry pick config changes.
/lgtm
/approve

authors: jprzychodzen mborsz

repo: kubernetes/perf-tests


text:
Migrate prometheus manifests to embed FS

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
This is a follow up to https://github.com/kubernetes/perf-tests/pull/2200
This PR migrates the most manifest-heavy part of CL2: prometheus.
Which issue(s) this PR fixes:
Special notes for your reviewer:
It includes https://github.com/kubernetes/perf-tests/pull/2200, please review the second commit only.
/assign @jupblb

/hold I will submit this on Monday

/hold cancel


text:
Issue with k8s.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

This is a Bug Report

403 Forbidden
No index.html in mounted volume
root@task-pv-pod:/# mount | grep nginx
/dev/mapper/rhel-root on /usr/share/nginx/html type xfs (rw,relatime,attr2,inode64,noquota)
root@task-pv-pod:/# ls /usr/share/nginx/html
root@task-pv-pod:/#
root@task-pv-pod:/# exit
[root@xxx-TECH1P ~]# ls /mnt/data/
index.html

RHEL, Kubernetes 1.15.2, latest Kubespray, Docker 19.03.1, Flannel
Upd: localhost, Fedora 30, KinD, docker 19.03.1, same thing.

Minikube on localhost same thing :(

@lstday, can you summarize what you have to do to replicate this issue?
I checked these steps and did not see any problem.
/triage needs-information

authors: lstday sftim

repo: kubernetes/website


text:
Issue with k8s.io/docs/reference/using-api/api-concepts/

This is a Bug Report

Problem:
https://kubernetes.io/docs/reference/using-api/api-concepts/#server-side-apply contains an example of the new managedFields metadata, with operation: Apply and a value for time. But https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.16/#managedfieldsentry-v1-meta says the time must be omitted when the operation is Apply.
Proposed Solution:
Fix whichever doc is wrong.
Page to Update:
One of the two cited above.

Hello @MikeSpreitzer .
The current docs (https://kubernetes.io/docs/) are version 1.17. Does this issue only apply to version 1.16?
API Reference v1.17, time field description:
Time is timestamp of when these fields were set. It should always be empty if Operation is 'Apply'

/sig api-machinery

Oh, I did not notice that my second URL was specific to release 1.16.  But your quote shows that it is the same in 1.17.

authors: MikeSpreitzer kbhawkey


text:
Explanation for "Pod Conditions" section is not clear.

This is a Bug Report
Problem:
This is an issue for better explanation for the Pod Conditions section on the page https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/.
There is a statement A Pod has a PodStatus, which has an array of PodConditions through which the Pod has or has not passed. Does this mean that the PodConditions array is an array of fixed length of pre-decided conditions? Does the array also include the conditions through which the Pod has not been through?
About the status field
The status field is a string, with possible values "True", "False", and "Unknown".
What kind of Truthy or Falsy values are we talking here. Is it supposed to tell whether a Pod has been in this condition (True) or not (False). What is Unknown then?
About the "type" field
It tales 4 values: PodScheduled , Ready , Initialized  and ContainersReady .
Are these supposed to occur in this order? Do these correspond to the PodConditions ie. does each one of it make an entry in the PodConditions array that is talked about in this section?
Proposed Solution:
Provide a better explanation of the Pod Condition section.
Page to Update:
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

/priority backlog
/language en
It'd be great to see this page tidied up

authors: adityamandhare sftim


text:
Untitled database: Table 1 - AppSheet databases

https://www.appsheet.com/dbs/database/ELZ90lVZKU4ryLu-do4b_7/table/xCH5C1fAql4_QfzQnK6Rp6

/language en

Please provide some details on the issue that you are facing.
/triage needs-information

@BothHybrid2022 Is it the accurate description of the issue you wish to report? It would be beneficial to include the correct details (here). Currently, it appears to resemble spam or or an unintentional creation of an issue in the wrong repository.

/close not-planned
Closing this issue for now. Please feel free to reopen it and provide the accurate details for the issue encountered in the documentation at https://kubernetes.io.


text:
don't make table-cell font-size smaller

partly addresses #12806

hm I don't see this change reflected at https://deploy-preview-12807--kubernetes-io-master-staging.netlify.com/docs/concepts/extend-kubernetes/api-extension/custom-resources/
I see font-size: 0.85em in (compiled?) CSS. Maybe I need to regenerate those?

hm I don't see this change reflected at https://deploy-preview-12807--kubernetes-io-master-staging.netlify.com/docs/concepts/extend-kubernetes/api-extension/custom-resources/
I see font-size: 0.85em in (compiled?) CSS. Maybe I need to regenerate those?

Hello @ryan-williams. Currently you need to generate the CSS and commit these files to this PR.
What font size are you setting for the table cell text? Also, there are tables that have code markup.

This needs a rebase / merge conflicts fixing.
(Prow doesn't seem to have noticed).

hello! could we please resolve the conflicts or close this PR?

Hi @ryan-williams , are you still working on this? :)

I'll resurrect this this wknd, thanks

authors: kbhawkey ryan-williams ryanmcginnis sftim xiangpengzhao


text:
san diego contributor summit blog

blog post for the contributor summit

/lgtm

/hold
some quick fixes in while getting an approve

/approve

/lgtm
release the hold when ready 👍

Looks good. Is the branch up to date? I don't see the list of currently published blogs in the right hand nav? I may be looking at an old preview though.

/hold cancel

authors: jonasrosland kbarnard10 kbhawkey mrbobbytables parispittman


text:
Explain how to manage Kubernetes running on HUAWEI CLOUD provider.

Add kubernetes-sigs/cloud-provider-huaweicloud documentation.
Fixes https://github.com/kubernetes-sigs/cloud-provider-huaweicloud/issues/69

/assign @jimangel
@ reviewers, you can get the page from here.

who can provide technical review on this documentation change (to verify that it is accurate)?

@kevin-wangzefeng is one of the maintainers of kubernetes-sigs/cloud-provider-huaweicloud, maybe he can help to confirm.

/lgtm

/lgtm

/label tide/merge-method-squash

authors: RainbowMango kevin-wangzefeng sftim


text:
StreamingProxyRedirects deprecation docs

Mark the StreamingProxyRedirects and ValidateProxyRedirects features as deprecated. Note that there was incorrect information about StreamingProxyRedirects being GA, so that has also been corrected.
For https://github.com/kubernetes/enhancements/issues/1558

/assign @ashnehete

LGTM
/sig node
/kind cleanup deprecation

/approve

oh, right
/lgtm

authors: PI-Victor ashnehete tallclair


text:
Fix wrong redirections

Resolves #30676

Can we also change the redirects to:
/security/ /docs/reference/issues-security/security/ 301

to always redirect to English translation?

/retitle Fix wrong /security redirection

@rikatz I reflected your comment. 😊

/label tide/merge-method/squash

/label tide/merge-method-squash

/sig security

authors: jihoon-seo rikatz sftim


text:
[hi] Add  content/hi/docs/concepts/overview/what-is-kubernetes.md

Added one file
Localized what-is-kubernetes.md to Hindi.
Follow -up to #30732

@anubha-v-ardhan , @divya-mohan0209 please merge this PR? I have updated this file.

@ashish-jaiswar
Please review the comments I have entered previously. They haven't been addressed.

hey @divya-mohan0209 , you haven't reviewed this PR yet. I think you have commented in different PR. Because  I don't see your review comment.

Hello @ashish-jaiswar , the reviews will be marked as outdated.

Re-reviewed it again.

hi @divya-mohan0209 , @anubha-v-ardhan  I have updated this file, if it looks good please merge this PR.

hey, @anubha-v-ardhan please merge this PR.

/label tide/merge-method-squash
/assign

/lgtm
/approve
Thank you @ashish-jaiswar, @kranurag7


text:
Remove duplicate word from “Reviewing pull requests”

I have removed the second add from the page.

This definitely solves the typo!
/lgtm

authors: eminalemdar mtardy


text:
[zh-cn] improve container-lifecycle-hooks.md

[zh-cn] improve container-lifecycle-hooks.md
$ ./scripts/lsync.sh content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md
content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md is still in sync

/lgtm
/approve


text:
[ja] fix typo

en PR https://github.com/kubernetes/website/pull/34278/files
/assign @atoato88
/assign @nasa9084

/lgtm
Thanks!!

LGTM too 😀

/approve

I re-pushed the fix and did a rebase, the build took a very long time


text:
Fix name of default ClusterRoleBinding for kube-proxy

fix Core component roles Default ClusterRoleBinding system:kube-proxy to system:node-proxier.

/close
Feel free to reopen with more evidences.

authors: libinglong tengqm


text:
Use echo -n rather than echo to avoid trailing newline...

...during secret creation

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For 1.9 Features: set Milestone to 1.9 and Base Branch to release-1.9
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: Please check the “Allow edits from maintainers” box (see image below) to
allow reviewers to fix problems on your patch and speed up the review process.
Please delete this note before submitting the pull request.
NOTE: After opening the PR, please un-check and re-check the "Allow edits from maintainers" box. This is a temporary workaround to address a known issue with GitHub.

This change is

CLA signed

/lgtm


text:
Improve kubeadm documentation

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For 1.9 Features: set Milestone to 1.9 and Base Branch to release-1.9
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: Please check the “Allow edits from maintainers” box (see image below) to
allow reviewers to fix problems on your patch and speed up the review process.
Please delete this note before submitting the pull request.
NOTE: After opening the PR, please un-check and re-check the "Allow edits from maintainers" box. This is a temporary workaround to address a known issue with GitHub.

Edits, updates and improvements to the existing kubeadm docs.
cc @kubernetes/sig-cluster-lifecycle-pr-reviews

This change is

/lgtm

@zacharysarah Changes addressed.

LGTM :shipit:

authors: jbeda luxas zacharysarah


text:
Role-Based Access Control

A Botkube user needs to be able to run executors with the appropriate roles and permissions as they normally have working in the Kubernetes cluster. Currently executors are run using the botkube-clusterrole ClusterRole assigned to the botkube-sa service account. This means all Botkube users in a given communication channel have the same permissions which may be too broad or narrow in scope. Implementing access control moves the Botkube security perimeter from the communication channel scope to the communication user scope.
AC

Any given user of Botkube in a communication tool (e.g. a Slack user) has a permission/role mapping to their permissions/roles in the appropriate Kubernetes cluster where Botkube is installed
Executor commands run by a given user are run with that user's K8s permissions
Cluster admins can configure user mappings from a high level and at the individual user level
Users can see their user/role mapping as appropriate

Stretch goals:

A user with existing access to a K8s cluster that is configured with Botkube RBAC can configure their own account mapping through an authorization process

Tasks

[x] https://github.com/kubeshop/botkube/issues/873
[ ] #933
[ ] #934
[ ] #935

Related:

#840
#841

@brampling could you please update this issue with requirements, so we can estimate it? It still has empty description. Thanks

@lpetkov FYI

authors: brampling pkosiec

repo: kubeshop/botkube


text:
Reject conflicting alias names for exported services

📜 Description
A service can be exported over the slice network by creating a ServiceExport object. Such services are accessible through the slice fqdn: ..svc.slice.local. But the users can choose to use a different fqdn by adding alias names to the ServiceExport object. Currently, there is no validation of the alias names. We cannot have conflicting alias names in the sense that the user should not be allowed to set the same alias name different services.
👟 Reproduction steps
Export two services by creating ServiceExport objects. Set the same alias names on both the ServiceExport objects.
The dns resolution of the exported service names will point to incorrect addresses. Service S1 resolution could result in endpoint IP addresses belonging to Service S2.
👍 Expected behavior
The alias names need to be validated and admission of ServiceExport objects with conflicting alias names should be rejected.
👎 Actual Behavior
ServiceExport objects for different services but with same alias names are allowed to be created.
🐚 Relevant log output
No response
Version
No response
🖥 What operating system are you seeing the problem on?
No response
✅ Proposed Solution
No response
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find any similar issue

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I am researching on the issue and will come up with an approach soon.
Can you please assign this to me?

A High-Level Approach to Resolve the Issue

Implement a validating webhook for ServiceExport object (slice/reconciler.go) for create,update,patch verbs.
The Webhook will fetch all the existing ServiceExport objects in the namespace. Write a utility function GetAllServiceExport.
Verify the alias names in spec.aliases field of the ServiceExport object do not have conflicting names with other existing ServiceExport objects in the same namespace.
Allow the request if there is no such conflict otherwise deny the request.
Write the relevant test cases as well.

@narmidm @bharath-avesha Please take a look.

@soharab-ic the approach looks good. Only correction is: On point 3, you will have to look for all service export objects for the slice, not just the same namespace. You could use the namespace labels added by worker-operator to get all namespaces belonging to the slice.

Thanks for the feedback @bharath-avesha

authors: bharath-avesha soharab-ic

repo: kubeslice/worker-operator


text:
helm升级到2.5.1 报错

命令：
helm upgrade notification-manager   --set kubesphere.enabled=true --set notificationmanager.sidecar.tenant.resources.limits.cpu=500m --set notificationmanager.sidecar.tenant.resources.limits.memory=500Mi --set notificationmanager.sidecar.tenant.resources.requests.cpu=500m --set notificationmanager.sidecar.tenant.resources.requests.memory=500Mi --set operator.containers.proxy.image.repo=harbor-k8s.net/kubesphere/kube-rbac-proxy --set operator.containers.operator.image.repo=harbor-k8s.net/kubesphere/notification-manager-operator  --set notificationmanager.image.repo=harbor-k8s.net/kubesphere/notification-manager --set notificationmanager.sidecar.image.repo=harbor-k8s.net/kubesphere/notification-tenant-sidecar   -n kubesphere-monitoring-system  ./notification-manager.tgz

错误：
Error: UPGRADE FAILED: cannot patch "notification-manager" with kind NotificationManager: NotificationManager.notification.kubesphere.io "notification-manager" is invalid: [spec.sidecars.tenant.name: Required value, spec.sidecars.tenant.type: Required value]

sidecar => sidecars

还是没明白，values 里面定义的就是sidecar，notificationmanager.yaml引用的也是sidecar，报错的信息是spec.sidecars.tenant.name需要这个值。notificationmanager.yaml中这一段已经定义了
  {{- if .Values.kubesphere.enabled }}
  sidecars:
    tenant:
  {{- if .Values.kubesphere.image }}
      image: {{ include "global.imageRegistry" . }}{{ .Values.kubesphere.image }}
  {{- else }}
      image: {{ include "global.imageRegistry" . }}{{ .Values.notificationmanager.sidecar.image.repo }}:{{ .Values.kubesphere.version }}
  {{- end }}
      name: tenant
      type: kubesphere
      resources:
        limits:
          cpu: {{ .Values.notificationmanager.sidecar.tenant.resources.limits.cpu }}
          memory: {{ .Values.notificationmanager.sidecar.tenant.resources.limits.memory }}
        requests:
          cpu: {{  .Values.notificationmanager.sidecar.tenant.resources.requests.cpu }}
          memory: {{  .Values.notificationmanager.sidecar.tenant.resources.requests.memory }}
  {{- end }}

helm   dry-run 的结果部分内容：
  sidecars:
    tenant:
      image: harbor-k8s.net/kubesphere/notification-tenant-sidecar:v3.2.0
      name: tenant
      type: kubesphere
      resources:
        limits:
          cpu: 500m
          memory: 500Mi
        requests:
          cpu: 500m
          memory: 500Mi

我的升级步骤是：

apply bundle.yaml 文件
执行上述helm升级。
现在我已经通过卸载notification-manager和删除相关crd，直接使用helm  安装成功。关于升级的问题，还是希望得到解答。

authors: wadeLouis wanjunlei

repo: kubesphere/notification-manager


text:
fix some typo and update README.md

remove references to outdated documents from  README.md
Signed-off-by: Duan Jiong djduanjiong@gmail.com

/lgtm

/lgtm
/approve

authors: FeynmanZhou duanjiong zheng1

repo: kubesphere/porter


text:
Adjust wmware provider page to new insecure feture

a. Add the new insecure option to the vmware provider page
b. add a CA cert input as text (like in ovirt) for the vmware provider page

Refs:
https://issues.redhat.com/browse/MTV-468
https://issues.redhat.com/browse/MTV-469

Refs: https://issues.redhat.com/browse/MTV-468 https://issues.redhat.com/browse/MTV-469

See #191 that correlated to MTV-468


text:
:feet: Enable hiding the Welcome card within the Overview page

Reference: #800
This enhancement includes the following changes (similar to the cluster admin->home -> overview -> Getting started resources hiding option):

Add a tooltip with help text next to the Welcome title.
Add a kebab menu with an option to hide the Welcome card.
Add a button with a label for restore the Welcome card back
Locally persist this option in browser local storage.

Future enhancements:

Unified all plugin user settings by using a common component.
Support backend K8s user settings as done in the console.

Screenshots

@yaacov all comments were applied including combining the load settings into the context hook.


text:
vela 获取vele core版本时为空？

问题： 一台linux 主机上安装的有vela bin进制命令工具，一个可连接k8s集群的conf文件，查看 k8s集群上vela core版本时，没有获取到版本号？
vela CLI 版本： v1.5.3

Have you installed the vela-core in that cluster?

问题已处理

How do you fix it?

authors: chivalryq limary wonderflow

repo: kubevela/kubevela


text:
Fix: hidden platformID

Signed-off-by: Zhiyu Wang zhiyuwang.newbis@gmail.com
Description of your changes

Fixes #
I have:

[ ] Read and followed KubeVela's contribution process.
[ ] Related Docs updated properly. In a new feature or configuration option, an update to the documentation is necessary.
[ ] Run make reviewable to ensure this PR is ready for review.
[ ] Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

Special notes for your reviewer

discussed offline and will use another way to fix


text:
CNV-38883: Update the link to Activation key doc

📝 Description
Fixes:
https://issues.redhat.com/browse/CNV-38883
Fix the broken Read more link to the documentation about activation key for automatic subscription of RHEL VirtualMachines. Use the newer working link:
https://access.redhat.com/documentation/en-us/red_hat_insights/1-latest/html/remote_host_configuration_and_management/activation-keys_intro-rhc
🎥 Screenshots
Clicking on Read more:

Before:

After:

@avivtur @metalice @pcbailey @upalatucci @vojtechszocs please review

/retest

authors: hstastna upalatucci

repo: kubevirt-ui/kubevirt-plugin


text:
chore: add ownerReference param to modify-data-object task

What this PR does / why we need it:
chore: add ownerReference param to modify-data-object task
This commit adds new param setOwnerReference to modify-data-object tasks. If set to true, the data object will have OwnerReference by TaskRun pod.
Release note:
chore: add ownerReference param to modify-data-object task

/retest

repo: kubevirt/kubevirt-tekton-tasks


text:
Use builder from quay

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

NONE

/test pull-kvp-functional-test

https://github.com/kubevirt/kubevirt-velero-plugin/pull/49 should handle ginkgo err

/test pull-kvp-functional-test

/lgtm
/approve

/lgtm

authors: akalenyu brybacki

repo: kubevirt/kubevirt-velero-plugin


text:
Add necessary fields for performance tuning

As a user and operator I expect that KubeVirt allows me to tune my VMs in order to meet the performance of other KVM based hypervisors.

Requirements:

[ ] Update requirements based on references below

References

https://www.ovirt.org/develop/release-management/features/virt/high-performance-vm/
https://www.ovirt.org/blog/2017/10/introducing-high-performance-vms/
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/virtual_machine_management_guide/#Configuring_High_Performance_Virtual_Machines_Templates_and_Pools (paywalled)

I created the list of things that we need to enable or disable:

Enable L3 cache - what downsides this feature has, why does not enable it by default
The best performance increasement will have a VM that uses cores from the same socket
Enable Headless Mode - we need to disable graphical and video devices
Disable USB devices
Disable Smart Card device - IIRC we do not have this device so nothing need to do from our side.
Enable Virtio serial console
Enable CPU passthrough
Disable memory balloon device
Enable usage of IO threads - what downsides this feature has, why does not set it by default to 1.
CPU pinning and NUMA pinning - currently not supported by us, but I hope in the near future we will have CPU pinning
some additional work on a disk device - set cache to none, set io to threads
enable virtio-rng device - we have the separate issue for it
disable watchdog device

For the most part of things that I specified above we do not have API on the frontend side, so we can not specify it under VM preset.
@fabiand @rmohr @michalskrivanek Do we want to introduce API for each small feature or maybe do we want to introduce something similar to Ovirt VM profile to set only relevant profile and under the hood we will set all small features for the VM?

@cynepco3hahue I'm volunteering to help implementing this feature if you want

my 2c about the implementation: IMHumbleO all of the above should be hidden behind a single tunable setting (AFAIK kubevirt already has ways to do most of the relevant settings) like the ovirt vm profiles, to be later moved in the virtuned/libvirt-profiles.

Enable Headless Mode - we need to disable graphical and video devices

We can add a autoattachGraphicsDevice boolean field. Maybe starting with an annotation to gather feedback. That might be something more users care about, to save ram without going for full performance.

Disable USB devices
Disable Smart Card device - IIRC we do not have this device so nothing need to do from our side.
Enable Virtio serial console
Enable CPU passthrough
Disable memory balloon device

Do we have that by default? We don't have ballooning right now. I would make sure it is not added by default at this moment.

Enable usage of IO threads - what downsides this feature has, why does not set it by default to 1.
CPU pinning and NUMA pinning - currently not supported by us, but I hope in the near future we will have CPU pinning
some additional work on a disk device - set cache to none, set io to threads

I guess that we want to expose the cache directly? Afaik it depends on a huge amount of factors from your host if "none" is the fastest?

enable virtio-rng device - we have the separate issue for it

Yes, we can definitely do that always as far as I remember.

disable watchdog device

Not there by default, so not an issue.

Disable USB devices

We could do that right now and thinking about adding them the right way once we support attaching stuff to them.

Disable Smart Card device - IIRC we do not have this device so nothing need to do from our side.
Enable Virtio serial console

Hm, that depends on the fact if the guest supports virtio or not. Is that even important? Does having a compatible console attached slowing down the vm already?

Enable CPU passthrough

Here I still wonder if host-model makes any sense at all and if we should not just use passthrough. According to e.g. https://wiki.openstack.org/wiki/LibvirtXMLCPUModel, it does neither guarantee a sane cpu configuration, nor migratability.

@fromanirh Hi, and thanks for the proposal. IMHO I do not have much to do here, because

@stu-gott works on IO threads
@vladikr works on CPU pinning
@petrkotas works on virtio-rng

So here we just need to decide what approach we prefer, to use profiles or create separate API fields for every needed feature(it more customizable than profile). Ovirt has profiles, but still, you have the API for each separate feature(except L3 cache IIRC). Also, we need to decide if we want to enable part of the features for the regular VM's as well:

L3 cache
IO threads 1

@cynepco3hahue ack

We can add autoattachGraphicsDevice boolean field. Maybe starting with an annotation to gather feedback. That might be something more users care about, to save ram without going for full performance.

Do you mean to use annotation instead of API field?

Do we have that by default? We don't have ballooning right now. I would make sure it is not added by default at this moment.

Yes we have it by default, I think if you do not specify model to be none, libvirt set it by default to virtio
<memballoon model='virtio'>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </memballoon>

I guess that we want to expose the cache directly? Afaik it depends on a huge amount of factors from your host if "none" is the fastest?

I checked Ovirt disk parameters(none means that it does not caching on the host), so it possible that it does not suite good for all cases, @aglitke maybe do you know which option is best from performance perspective, will <driver name="qemu" type="raw" io="threads" cache="none"/> suite well for most cases?

Not there by default, so not an issue.

Good for us :smile:

We could do that right now and thinking about adding them the right way once we support attaching stuff to them.

Will create a PR to disable all not used devices.

Hm, that depends on the fact if the guest supports virtio or not. Is that even important? Does having a compatible console attached slowing down the vm already?

@fromanirh Maybe you can answer it, I do not sure what performance impact it will have.

Here I still wonder if host-model makes any sense at all and if we should not just use passthrough. According to e.g. https://wiki.openstack.org/wiki/LibvirtXMLCPUModel, it does neither guarantee a sane cpu configuration, nor migratability.

I think when a user does not specify host-passthrough or specific CPU model, it just means that he does not really care about CPU flags, so when libvirt will mask part of features after the migration, it also does not matter for him.
IMHO because of it host-model still the best option for the default value, from one side it provides a pretty good approximation to host CPU and from another side, it does not prevent migration.

Hm, that depends on the fact if the guest supports virtio or not. Is that even important?
Does having a compatible console attached slowing down the vm already?
@fromanirh Maybe you can answer it, I do not sure what performance impact it will have.
AFAIK the footprint in terms of CPU and memoru of a console device, either serial or virtio, is negligible, and we need it anyway to offer a mean to connect to the VM :)

for console devices, virtio is the default, but as rmohr pointed out, requires drivers from the guest. For Linux should be no issue, for windows we need it. For the maximum compatibility we should use the serial emulation.

@fromanirh Thanks for the information, will use serial emulation.

@fromanirh I see that we anyway do not use virtio console
    <serial type='unix'>
      <source mode='bind' path='/var/run/ovirt-vmconsole-console/40195fba-1894-4641-9033-3ac9b99287d2.sock'/>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
      <alias name='serial0'/>
    </serial>
    <console type='unix'>
      <source mode='bind' path='/var/run/ovirt-vmconsole-console/40195fba-1894-4641-9033-3ac9b99287d2.sock'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>

so no need to change it.
We can consider to expose two consoles one serial emulation and another one virtio serial console.

@cynepco3hahue indeed, it seems you are OK already. I think two consoles are overkill - if memory serves well we never encountered a case on which it was worth adding two, in oVirt.
IOW, I think that the "console" item is pretty much OK already, no extra work seems to be needed.

the only drawback of serial was that it's buggy:) for OSes where we have drivers(like Linux) we should go with virtio. For random stuff, BSD, Windows (if someone finds that useful at all) "serial" could be good enough
As for two consoles - I do not see a reason why to limit it to one at spec level really. It can be useful to define more, albeit rarely.

@michalskrivanek Do you have some examples of buggy behavior, because currently all our VM's uses the serial console and I did not see any problems with it.

Everything except for numa has been merged. Thus resolving this issue as DONE.
NUMA will be tracked separately.

authors: cynepco3hahue fabiand fromanirh michalskrivanek rmohr

repo: kubevirt/kubevirt