text:
CephFS Provisioner Input/Output Error

We are having issues with the cephfs provisioner against a few of our kube clusters:
The Provisioner runs correctly and I am able to create a PVC and mount it in my container but when i perform any operations against the mount I am presented with an I/O error.
kubectl exec -it test-pod touch /mnt/test --namespace=sre touch: cannot touch '/mnt/test': Input/output error
The behavior is visible outside the container as well, this is on a node with the cephfs pool mounted within the directories the provisioner created:
ls: cannot access /data/cephfs/volumes/kubernetes/kubernetes-dynamic-pvc-3041dba2-9415-11e7-862f-169051d230b2: Input/output error
total 0
drwxr-xr-x 1 root root 1 Sep  7 21:40 .
drwxr-xr-x 1 root root 2 Sep  7 21:40 ..
d????????? ? ?    ?    ?            ? kubernetes-dynamic-pvc-3041dba2-9415-11e7-862f-169051d230b2

[root@ceph-client001 tmysliwiec]# ls -la /data/cephfs/volumes/kubernetes/kubernetes-dynamic-pvc-3041dba2-9415-11e7-862f-169051d230b2
ls: cannot access /data/cephfs/volumes/kubernetes/kubernetes-dynamic-pvc-3041dba2-9415-11e7-862f-169051d230b2: Input/output error

I'm able to perform operations agains the cephfs everywhere else, and the cluster has been healthy and running mounts on tons of other non-kubernetes nodes. Not sure what would cause this behavior. Let me know if theres anything i can do to resolve this, thanks in advance!

I also got the same error, more details as below:
$ kubectl describe po/fs-mount-pod
...
Events:
  FirstSeen	LastSeen	Count	From			SubObjectPath	Type		Reason			Message
  ---------	--------	-----	----			-------------	--------	------			-------
  41s		41s		1	default-scheduler			Normal		Scheduled		Successfully assigned fs-mount-pod to node4
  41s		41s		1	kubelet, node4				Normal		SuccessfulMountVolume	MountVolume.SetUp succeeded for volume "default-token-txx5l"
  41s		8s		7	kubelet, node4				Warning		FailedMount		MountVolume.SetUp failed for volume "pvc-a45a87c3-95e1-11e7-b116-448a5b81d4bd" : CephFS: mount failed: mount failed: exit status 5
Mounting command: mount
Mounting arguments: 172.20.3.92:6789,172.20.3.93:6789,172.20.3.95:6789:/volumes/kubernetes/kubernetes-dynamic-pvc-a468a609-95e1-11e7-a436-fa8092874d5d /var/lib/kubelet/pods/1eeb3320-95e2-11e7-b116-448a5b81d4bd/volumes/kubernetes.io~cephfs/pvc-a45a87c3-95e1-11e7-b116-448a5b81d4bd ceph [name=kubernetes-dynamic-user-a468a63c-95e1-11e7-a436-fa8092874d5d,secret=AQBZwbRZtOLULhAAiFMjKIb8Q35OlS1cpJaSrw==]
Output: mount error 5 = Input/output error

@kairen the mount completes successfully on my end, the I/O errors are when I try to read/write to the mount dir. Historically when i've seen mount error 5 with ceph it was the result of a failure to access your MDS servers. check if you can reach them from within your container.

I'm experiencing the same error as @kairen - externally from K8s I can mount all of the directory tree but not the final kubernetes-dynamic-pvc-... directory.  Ubuntu 16.04, Kernel 4.4.0

@tmysl @playworker can you mount manually the top level directory, i.e.
mount -o ceph 172.20.3.92:6789,172.20.3.93:6789,172.20.3.95:6789:/volumes/ /mnt -o name=kubernetes-dynamic-user-a468a63c-95e1-11e7-a436-fa8092874d5d,secret=AQBZwbRZtOLULhAAiFMjKIb8Q35OlS1cpJaSrw==

@rootfs yes I can, same with the /volumes/kubernetes directory, it's only the final kubernetes-dynamic-pvc-... directory that I can't mount manually

@playworker there is a known limitation 3rd bullet here
I haven't tested newer kernel yet

Thanks @rootfs, I'm not particularly familiar with CephFS - what does the 3rd bullet mean?  It reads to me like it's has security implications rather than functional implications.
I guess we're talking about this limitation:  "Currently each Ceph user created by the provisioner has allow r MDS cap to permit CephFS mount."?

see "Path Restriction" here

@rootfs I'm sorry, I still don't understand why you think that each user being given the "allow r" MDS cap limitation is the cause of my issue.  The mount command has the user specified, when the provisioner created that user I assume they have been given the "allow r" capability and therefore should be able to mount the path specified?

@playworker can you post your ceph auth for user kubernetes-dynamic-user-a468a63c-95e1-11e7-a436-fa8092874d5d

My particular issue was to do with namespace support in the CephFS kernel driver, this wasn't introduced until kernel versions 4.7/4.8 (not sure exactly which), upgrading the Kubernetes workers to kernel version 4.10 has fixed the problem - thanks for your help everyone :)

Thanks Guys for all your comments - we were indeed running on centos 7/kernel 3.10.* - upon upgrading the kernel to mainline on one node and setting up a taint & toleration we were able to get the provisioner and accompanying test-pod to mount and allow us to manipulate the dir.

I tried to update my ubuntu's kernel from 4.4.0 to 4.10.0 (sudo apt install linux-image-4.10.0-28-generic) and after a reboot, the error is gone, everything's works fine from now on :)

I also encountered this problem, but I don't know how to solve this problem. Is it necessary to upgrade the ceph version to mimic? I am using "quay.io/external_storage/cephfs-provisioner:latest", I see someone modifying cephfs_provisoner.py to remove the namespace part, I don't know if it can be solved, and I don't know how to modify this image

@tmysl Hello, can you tell me the specific steps? Thank you

Upgrade the linux kernel to 4.10 and above or upgrade the ceph to mimic version

Already upgrade ceph to mimic,but no help.
ceph version
ceph version 13.2.1 (5533ecdc0fda920179d7ad84e0aa65a127b20d77) mimic (stable)
i will try upgrade the kernel to 4.10 now.

@kinzess how about the result now?

@majorinche first i upgrade my centos7 kernel from  3.10.* to 4.17.(kernel-ml-4.17.14-1.el7.elrepo.x86_64.rpm), all PGs lost.
then upgrade to 4.18.(kernel-ml-4.18.3-1.el7.elrepo.x86_64.rpm), all PGs back.
everything works fine now.

ok, i just add -disable-ceph-namespace-isolation=true in the deployment, Input/output error just gone
- args:
- '-id=cephfs-provisioner-1'
- '-disable-ceph-namespace-isolation=true'
command:
- /usr/local/bin/cephfs-provisioner

@majorinche   my 'Input/output error'  just gone, using your way. thanks you very much!!!

authors: Adriien-M chenqiao3199 kairen kinzess ktpktr0 majorinche playworker rootfs tmysl

repo: kubernetes-incubator/external-storage


text:
nfs-client-provisioner fix #5

fixes #5

CLA signed

oh yeah and please also add an OWNERS file to the nfs-client directory with your name in it like this: https://github.com/kubernetes-incubator/external-storage/blob/master/ceph/cephfs/OWNERS

CLA truely signed

@wongma7 owners added

Thank you, merging.
I'm not 100% sure the repo shouldn't look something like this:
nfs
  client (this provisioner)
  ??? (the existing ganesha server+client one)

But we can figure that out later.

source: gharchive/pull-request

license_type: permissive

license_source: bigquery


text:
[WIP] Update playbooks to support new netchecker

Netchecker is rewritten in Go lang with some new args instead of env variables. Also netchecker-server no longer requires kubectl container. Updating playbooks accordingly.

ci check this

Rebased, updated container names to a proper ones. Removing WIP

Thank you @adidenko, a great update!

authors: adidenko bogdando

repo: kubernetes-incubator/kargo


text:
Readme typo batched -> batchd

Readme typo batched -> batchd

signed

repo: kubernetes-incubator/kube-arbitrator

license_source: github-api


text:
IAMManagedPolicyController too permissive

Our security team has flagged our kube-aws IAM policies as problematic, because all actions, on all resource, are permitted for ec2 and elastic load balancing. Is there an easy way to audit the calls made, so the actions can be scaled back to only those needed?
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "ec2:*",
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": "elasticloadbalancing:*",
            "Resource": "*",
            "Effect": "Allow"
        },

/remove-lifecycle rotten

source: gharchive/issue

repo: kubernetes-incubator/kube-aws


text:
Enable leader election in csi components

Settings are adapted from kubernetes-sigs/azuredisk-csi-driver#224
Refactored chart image references

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

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

Fixes #
Special notes for your reviewer:
Release note:

@bcho e2e CI test is ready, could you rebase? Thanks.

@bcho e2e CI test is ready, could you rebase? Thanks.

Sure, I will have a look later today

/ok-to-test

/ok-to-test

authors: andyzhangx bcho

repo: kubernetes-sigs/blobfuse-csi-driver


text:
Tests/Account & Domain Isolation and More Domain/Account Tests

Issue #, if available:
N/A
Description of changes:
Adds Domain/Account/User creation and cleanup on unit test runs.
The unit tests now still only take about 15 seconds, but now they run in a domain with UUID that is cleaned up afterwards. This allows test isolation and helps to guarantee failed test cleanup.
In doing so I've also managed to turn enable about 40+ unit tests that were skipped in the pipeline previously.
Sigh, and now they're still skipped since we don't yet have an ACS instance to hit.
I labeled the integ tests and filtered them in the makefile for now.
Testing performed:
More than before!

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Codecov Report

Merging #121 (80fde6f) into main (eb51b18) will decrease coverage by 0.11%.
The diff coverage is 25.00%.

@@            Coverage Diff             @@
##             main     #121      +/-   ##
==========================================
- Coverage   29.00%   28.88%   -0.12%
==========================================
  Files          27       27
  Lines        2179     2167      -12
==========================================
- Hits          632      626       -6
+ Misses       1473     1466       -7
- Partials       74       75       +1

Impacted Files
Coverage Δ

pkg/cloud/isolated_network.go
32.32% <0.00%> (-1.30%)
:arrow_down:

pkg/cloud/client.go
26.47% <50.00%> (ø)

pkg/cloud/instance.go
79.11% <0.00%> (-0.89%)
:arrow_down:

controllers/cloudstackcluster_controller.go
47.47% <0.00%> (-0.05%)
:arrow_down:

controllers/cloudstackzone_controller.go
0.00% <0.00%> (ø)

controllers/cloudstackmachine_controller.go
0.00% <0.00%> (ø)

controllers/cloudstackaffinitygroup_controller.go
0.00% <0.00%> (ø)

...ontrollers/cloudstackisolatednetwork_controller.go
0.00% <0.00%> (ø)

...ollers/cloudstackmachinestatechecker_controller.go
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

@maxdrib I just fixed up that last skipped test. It's still slow even with the force stop. We don't run integs in the Pipeline atm anyway, so it is what it is I suppose. Please mark lgtm if you approve. Thanks!

/lgtm

authors: codecov-commenter maxdrib rejoshed


text:
E2e/create complex test case

Issue #, if available:
Description of changes:
Running all e2e test cases takes a little less than 3 hours which is too long. This PR creates a new test case covering multiple existing test cases + new test case for multi-endpoint feature via a complex cluster spec.
Existing test cases
- When testing app deployment to the workload cluster [TC1][PR-Blocking]
- When testing multiple CPs in a shared network with kubevip
- When testing with custom disk offering
- When testing subdomain
- When testing affinity group (anti)
- When testing affinity group (pro)

New test cases
- Multi endpoints

Running this new test case takes about 16 mins vs. 49 mins taken running the existing test cases individually.
Testing performed:
make run-e2e
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@wongni any updates on this test case PR. I see it's still in draft status.
If you are ready for review I can look it over. Just let me know. : )

Closing as needs rebase and we do not have time to complete this test.

authors: rejoshed wongni


text:
Fix to broken simple-cluster

Signed-off-by: Dan Finneran dan@thebsdbox.co.uk
Currently the supplied example will result in an error due to spec.versions.kublet missing from a machine configuration.
As shown below:
$ kubectl apply -f ./examples/simple-cluster.yaml
cluster.cluster.k8s.io/my-cluster unchanged
machine.cluster.k8s.io/worker unchanged
The Machine "my-control-plane" is invalid: []: Invalid value: map[string]interface {}{"apiVersion":"cluster.k8s.io/v1alpha1", "kind":"Machine", "metadata":map[string]interface {}{"annotations":map[string]interface {}{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"cluster.k8s.io/v1alpha1\",\"kind\":\"Machine\",\"metadata\":{\"annotations\":{},\"labels\":{\"cluster.k8s.io/cluster-name\":\"my-cluster\",\"set\":\"controlplane\"},\"name\":\"my-control-plane\",\"namespace\":\"default\"},\"spec\":{\"providerSpec\":{},\"versions\":{\"controlPlane\":\"v1.14.2\"}}}\n"}, "creationTimestamp":"2019-08-13T14:23:45Z", "generation":2, "labels":map[string]interface {}{"cluster.k8s.io/cluster-name":"my-cluster", "set":"controlplane"}, "name":"my-control-plane", "namespace":"default", "resourceVersion":"1113", "uid":"f5352c0c-bdd5-11e9-b8b1-0242ac110003"}, "spec":map[string]interface {}{"providerSpec":map[string]interface {}{}, "versions":map[string]interface {}{"controlPlane":"v1.14.2"}}}: validation failure list:
spec.versions.kubelet in body is required

What this PR does / why we need it:
The current example results in an error provisioning the various machine specs, this tiny pr adds the missing kubelet info required to deploy.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.
Release note:

NONE

/ok-to-test
/lgtm
/assign @chuckha
This will likely need to be backported to the release-0.1 branch

/approve

authors: chuckha detiber thebsdbox


text:
Validate subnamespace anchors on update (backporting to v1.0 branch)

Now that labels and annotations can be added to subnamespace anchors, these should now also be validated when they are updated.
Tested: before this change on K8s 1.16 I was able to modify the labels on subnamespace anchors without any validation running. With this change my modification is now validated and blocked.

/lgtm
/approve

authors: adamdougal erikgb

repo: kubernetes-sigs/hierarchical-namespaces


text:
Add managed-by label similar to the proposed on in Job

What would you like to be added:
A managed-by label to follow up on https://github.com/kubernetes/enhancements/pull/4370
Why is this needed:
MultiKueue support

https://github.com/kubernetes-sigs/jobset/pull/407
/assign @trasc

/close
#407 is now merged

authors: ahg-g kannon92 trasc

repo: kubernetes-sigs/jobset


text:
add user documentation for secureboot signing

Add some (basic) documentation for how to use kmod signing within kmm
This covers the build-and-sign, and the sign-prebuilt-image use cases

(Sorry for being annoying)
Can you please add the PR description to be part of the commit message?

/ok-to-test

After Yoni's prompting I have added a second doc for the build and sign case, including a description of the intermediate image name we're creating (with extra elements appended to the tag).  Hopefully yhis is now at least enough to get started with testing signing.

/status in-progress

After doing some testing with Costi I think I need to add a page about creating the signing keys and their secrets, and some other clarifications, plus all the stuff above means this is Work In Progress more comments are welcome but at the moment this is not ready for merging

/hold

@iranzo Do you know why Netify is failing on this PR? I don't see any log for some reason.

@ybettan 4:53:16 PM: WARNING -  Documentation file 'secureboot/index.md' contains a link to 'secureboot/secureboot-issues.md' which is not found in the documentation files.

Thanks. Which one of the jobs are you opening? For me it is just "loading" the logs forever.

I did open the deploy/netlify one

https://app.netlify.com/sites/kubernetes-sigs-kmm/deploys/638e13d78a9ed90008677020#L116

OK. Seems like I just needed to log in, otherwise, it just shown loading signal for ever.

/retest

/lgtm
/assign @qbarrand

/lgtm

/approve

authors: chr15p iranzo qbarrand ybettan


text:
Inaccurate totalResource in proportion plugin

In proportion plugin,  the totalResource is the sum of Allocatable of all the nodes:
for _, n := range ssn.Nodes {
	pp.totalResource.Add(n.Allocatable)
}

Then totalResource will be divided into the deserved attr of each queue.
However,  in the cluster there are some pods that occupy resources, which should be subtracted from totalResource, since these resources do not belong to any queue.

/kind bug
/priority important-soon

makes sense to me :)

repo: kubernetes-sigs/kube-batch


text:
Fix kube master hostname check for multicluster hostnames

In image/wrapkubeadm, there's a test for whether a node is kubernetes master. The current test looks for a fixed name of "kube-master":
is_master=
if [[ "$(hostname)" = kube-master ]]; then
  is_master=y
fi

But the hostname for a kube master in a multicluster config wont match the expected kube-master:
root@kube-master-cluster-20:/usr/local/bin# echo $(hostname)
kube-master-cluster-20
root@kube-master-cluster-20:/usr/local/bin#

This check for master should be:
is_master=
if [[ "$(hostname)" == kube-master* ]]; then
  is_master=y
fi

Where this is used:
  if [[ ${is_master} ]]; then
    dind::frob-cluster
  fi

Fixes Issue #218

/lgtm  Good catch, as in multi-cluster mode it will not correctly match the kube-master naming for clusters that have a non-zero cluster ID (e.g. are not the first cluster).

/lgtm

/approve

authors: leblancd lukaszo pmichali

repo: kubernetes-sigs/kubeadm-dind-cluster


text:
Make AppDir and AppImage the default for linux

Add AppDir files to the tarball so that is possible to run.
AppRun  .DirIcon  minikube-gui  minikube-gui.desktop  minikube.png  usr/
Create an AppImage to get an all-in-one similar to the dmg.
minikube-gui-linux.AppImage
Closes #49

Uses:

https://github.com/probonopd/linuxdeployqt

See also:

https://docs.appimage.org/packaging-guide/manual.html

@medyagh can we test this, to see if the linuxdeployqt program is installed by default or needs adding ?

No such luck: /bin/sh: 2: linuxdeployqt: not found
So we need to download and install it, I suppose...

curl -LO https://github.com/probonopd/linuxdeployqt/releases/download/continuous/linuxdeployqt-continuous-x86_64.AppImage
sudo install linuxdeployqt-continuous-x86_64.AppImage /usr/local/bin/linuxdeployqt

@medyagh try again ? added a commit to install the missing linuxdeployqt program

https://github.com/jurplel/install-qt-action/issues/204

ping @spowelljr

@afbjorklund is the test/build happy now?

Looks happy:

Was just to chmod +x and run, all dependencies bundled within the single file:
minikube-gui-linux.AppImage

There is some extra file though, "Minikube--x86_64.AppImage" - it looks like some kind of leftover
I think it was supposed to have the version in the filename but it looks like VERSION is empty ?

inikube--x86_64.AppImage" - it looks like some kind of leftover
I think it was supposed to have the version in the filename but it looks like VERSION is empty ?

not sure, can we merge this PR now ?

It seems like VERSION is not set for the PR, but only for the release builds - should be OK to merge

Added support for adwaita-qt, so that one can use adwaita or adwaita-dark styles...
Previous error message:
QApplication: invalid style override passed, ignoring it.
    Available styles: Windows, Fusion

light

dark

The installation ended up in some weird place, so it didn't make into the tarball:
-- Installing: /home/runner/work/minikube-gui/minikube-gui/bin/adwaita-qt-1.4.2/dest/usr/lib/x86_64-linux-gnu/libadwaitaqtpriv.so.1
-- Installing: /home/runner/work/minikube-gui/minikube-gui/bin/adwaita-qt-1.4.2/dest/usr/lib/x86_64-linux-gnu/libadwaitaqt.so.1
-- Installing: /home/runner/work/minikube-gui/minikube-gui/bin/adwaita-qt-1.4.2/dest/home/runner/work/minikube-gui/Qt/5.15.2/gcc_64/plugins/styles/adwaita.so

cp adwaita-qt-1.4.2/dest/usr/lib/x86_64-linux-gnu/libadwaitaqt.so.1 usr/lib

cp adwaita-qt-1.4.2/dest/usr/lib/x86_64-linux-gnu/libadwaitaqtpriv.so.1 usr/lib

cp adwaita-qt-1.4.2/dest/usr/lib//qt5/plugins/styles/adwaita.so usr/plugins/styles
cp: cannot stat 'adwaita-qt-1.4.2/dest/usr/lib//qt5/plugins/styles/adwaita.so': No such file or directory

Need to configure that, so that it installs into some sane place (and not in homedir)

Linux looks good now.

authors: afbjorklund medyagh

repo: kubernetes-sigs/minikube-gui


text:
[VC] proposal: kubectl vc command line tool

Motivation
super cluster admin managed all of the virtual clusters. They usually switch between different vc. First find the kubeconfig, then switch to this cluster. We need a command line tool to manage multi clusters.
Proposal
kubectl vc create xxx
create a virtual cluster and waiting it to be running. export kubeconfig to specific path.
kubectl vc delete xxx
delete a virtual cluster
kubectl vc config -n $vc_cr_ns $vc_cr_name
switch to a vc kubeconfig
kubectl vc -n $vc_cr_ns $vc_cr_name xxx
switch to a vc context and do normal kubectl command

@Fei-Guo @charleszheng44

This is going to be very useful!
A few comments:
kubectl vc config -n $vc_cr_ns $vc_cr_name will be optional if we have kubectl vc -n $vc_cr_ns $vc_cr_name xxx been available.
We can combine "-n $vc_cr_ns $vc_cr_name" to a single "vcfullname" as input so the cmd can be as simple as
Kubectl vc admin1/vc-sample1 get pod -A

+1 for the vc subcommand :+1:

This was something I have been thinking about too! I had originally considered extending vcctl, but I like the idea of a kubectl plugin!

/close

authors: Fei-Guo charleszheng44 salaxander zhuangqh

repo: kubernetes-sigs/multi-tenancy


text:
[HNC] Is it possible for controllers to watch subnamespace resources?

My org may consider to use HNC to resolve hierarchical namespace challenges. We have some controllers and want to install them in every subnamespace and make sure every user has their own control plane.
We want deploy controller in every subnamespace and only watch events at subnamespace level. is it impossible?  Seems sub namespace it is backed by Kubernetes namespace. We think it's possible to change controller to watch to the sub namespace?
kubernetes

org A namespace (real namespace)

userA namespace (subnamespace)
userB namespace (subnamespace)

org B namespace (real namespace)

That would have to depend on the controller you're installing. I believe
the Go clients can set up watches on individual namespaces, and since HNC
subnamespace are simply K8s namespaces, that will work. However, the
controller has to be designed to be configurable so that it can set up the
watch on the correct namespace.
It's not possible to watch a tree of namespaces, since trees are HNC-only
concepts while "watching" is a core K8s concept. So in your example, you
would be able to put a watch on userA or orgB and it would work the way
you expect. But if you put a watch on orgA, it would only watch that one
namespace, and not its subnamespaces. (Technically, the controller could be
upgraded to understand HNC hierarchies and create watches on all descendant
namespaces, but that's only feasible if you own the controller or if the
controller author loves HNC).
Does this make sense?
On Mon, Nov 23, 2020 at 12:49 AM Jiaxin Shan notifications@github.com
wrote:

My org may consider to use HNC to resolve hierarchical namespace
challenges. We have some controllers and want to install them in every
subnamespace and make sure every user has their th
We want deploy controller in every subnamespace and only watch events at
subnamespace level. I think this is impossible?
kubernetes

org A namespace (real namespace)

userA namespace (subnamespace) ->
userB namespace (subnamespace)

org B namespace (real namespace)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/multi-tenancy/issues/1286, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AE43PZERGKMKFSNBDQ7XJ73SRHZU3ANCNFSM4T7A4KQA
.

@adrianludwin

Technically, the controller could be upgraded to understand HNC hierarchies and create watches on all descendant namespaces, but that's only feasible if you own the controller or if the controller author loves HNC

Got it. That means for most of the controllers, they can only watch leaf node in the hierarch if we don't make extra changes.
To enable watch for other nodes (namespaces like orgA), we probably can change controller logic to use HNC client to read leafs nodes recursively and filter out all the namespaces under orgA. Then controller can register to watch events of these namespaces. I will try to do some POC for my controllers and report it back.
To make it generic enough, I think once HNC graduates, it would be great to add these logics to NewFiltersSharedInformerFactory and controller will have out-of-box support

Assuming the namespace is called "org-a", all namespaces in its tree will
have the "org-a.tree.hnc.x-k8s.io/depth" label present, so that's a good
way of selecting subtrees. There's no need for a recursive search.
Sadly, NewFiltersSharedInformerFactory  doesn't appear to support filtering
by labels today, but this would be a more extensible method of adding
support than direct HNC integration IMO.
On Mon, Nov 23, 2020 at 7:05 PM Jiaxin Shan notifications@github.com
wrote:

@adrianludwin https://github.com/adrianludwin
Technically, the controller could be upgraded to understand HNC
hierarchies and create watches on all descendant namespaces, but that's
only feasible if you own the controller or if the controller author loves
HNC
Got it. That means for most of the controllers, they can only watch leaf
node in the hierarch if we don't make extra changes.
To enable watch for other nodes (namespaces like orgA), we probably can
change controller logic to use HNC client to read leafs nodes recursively
and filter out all the namespaces under orgA. Then controller can register
to watch events of these namespaces. I will try to do some POC for my
controllers and report it back.
To make it generic enough, I think once HNC graduates, it would be great
to add these logics to NewFiltersSharedInformerFactory and controller
will have out-of-box support
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-sigs/multi-tenancy/issues/1286#issuecomment-732496544,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE43PZBY4CAJWYBBQGHUTA3SRL2DFANCNFSM4T7A4KQA
.

I'm closing this since it's sadly not feasible today, but if NewFiltersSharedInformerFactory adds label filtering we could revisit this. Please ping me again if you'd like to discuss this further!
/close

authors: Jeffwan adrianludwin


text:
Generate event for exceptions

If the reconciler cannot parse the selector annotation to a valid
selector, we record an event so that the user will get notified.
Tested:
$ k create ns a
$ k hns create a1 -n a
$ k delete validatingwebhookconfigurations.admissionregistration.k8s.io hnc-validating-webhook-configuration
$ k create role test -n a --verb=update --resource=deployments
$ k annotate role test -n a "propagate.hnc.x-k8s.io/none"="**foo"
$ k get event -n a
LAST SEEN   TYPE      REASON                OBJECT      MESSAGE
41s         Warning   CannotParseSelector   role/test   invalid propagate.hnc.x-k8s.io/none value: strconv.ParseBool: parsing "**foo": invalid syntax

Fix #1165

/assign @yiqigao217
/assign @adrianludwin

/lgtm
/approve
/hold
/assign @rjbez17

AFAIR there are more places to surface the error event than just 1 place?

Oh good point. Maybe this logic should be moved into selectors.ShouldPropagate() so that we don't miss another place like this?

AFAIR there are more places to surface the error event than just 1 place?

Oh good point. Maybe this logic should be moved into selectors.ShouldPropagate() so that we don't miss another place like this?

selectors doesn't have an eventRecorder. This is actually the only place that we call shouldPropagate() in the reconciler, the other places are in the validator

/lgtm
/hold cancel

authors: GinnyJI adrianludwin rjbez17


text:
hack: bump ko to 0.11.2

Diff:

https://github.com/google/ko/compare/v0.9.3...v0.11.2

Signed-off-by: Arnaud Meukam ameukam@gmail.com

cc @BenTheElder

/hold

https://github.com/google/ko/releases v0.10.0 has a lot of changes, the rest is largely dep updates and fixes for go 1.18
still reading v0.10 log

/lgtm
/approve
/hold cancel

authors: BenTheElder ameukam

repo: kubernetes-sigs/oci-proxy


text:
Failed to get pods metric value: unable to get metric DCGM_FI_DEV_FB_USED_AVG: no metrics returned from custom metrics API

What happened?:
I am constantly having this with one of my service hpa which is configured to scale based on custom metrics. Sometime hpa shows able to scale to True and able to get custom metrics most of the time not. Because of that hpa is not able to scale down the pods.
This our hpa description for one of the affected service.
Affected service hpa description:
  Type            Status  Reason               Message
  ----            ------  ------               -------
  AbleToScale     True    SucceededGetScale    the HPA controller was able to get the target's current scale
  ScalingActive   False   FailedGetPodsMetric  the HPA was unable to compute the replica count: unable to get metric DCGM_FI_DEV_FB_USED_AVG: no metrics returned from custom metrics API
  ScalingLimited  False   DesiredWithinRange   the desired count is within the acceptable range

While the other service using same hpa configuration not showing this error while describing its hpa.
This hpa description from another service.
Running service hpa:
This is a Random behaviour we observed in both services that sometime its able to collect custom metric and sometime not.
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True   ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric DCGM_FI_DEV_FB_USED_AVG

What did you expect to happen?:
Expect the same behaviour of prometheus adapter and hpa among the services if using same configuration for both services.
Please provide the prometheus-adapter config:

prometheus-adapter config

prometheus:
    url: http://prometheus-kube-prometheus-prometheus.monitoring.svc.cluster.local
    port: 9090
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

rules:
  default: false
  custom:
    - seriesQuery: 'DCGM_FI_DEV_GPU_UTIL{exported_namespace!="", exported_container!="", exported_pod!=""}'
      name:
        as: "DCGM_FI_DEV_GPU_UTIL_AVG"
      resources:
        overrides:
          exported_namespace: {resource: "namespace"}
          exported_pod: {resource: "pod"}
          exported_container: {resource: "pod"}
      metricsQuery: 'avg by (exported_namespace, exported_pod) (round(avg_over_time(DCGM_FI_DEV_GPU_UTIL{exported_pod!="",exported_container!=""}[1m])))'
    - seriesQuery: 'DCGM_FI_DEV_FB_USED{exported_namespace!="", exported_container!="", exported_pod!=""}'
      name:
        as: "DCGM_FI_DEV_FB_USED_AVG"
      resources:
        overrides:
          exported_namespace: {resource: "namespace"}
          exported_pod: {resource: "pod"}
          exported_container: {resource: "pod"}
      metricsQuery: 'avg by (exported_namespace, exported_pod) (round(avg_over_time(DCGM_FI_DEV_FB_USED{exported_pod!="",exported_container!=""}[1m])))'
    - seriesQuery: 'DCGM_FI_DEV_GPU_UTIL{exported_namespace!="",exported_container!="",exported_pod!=""}'
      name:
        as: "DCGM_FI_DEV_GPU_UTIL_MIN"
      resources:
        overrides:
          exported_container: {resource: "service"}
          exported_namespace: {resource: "namespace"}
          exported_pod: {resource: "pod"}
      metricsQuery: min by (exported_namespace, exported_container) (round(min_over_time(<<.Series>>[1m])))
    - seriesQuery: 'DCGM_FI_DEV_GPU_UTIL{exported_namespace!="",exported_container!="",exported_pod!=""}'
      name:
        as: "DCGM_FI_DEV_GPU_UTIL_MAX"
      resources:
        overrides:
          exported_container: {resource: "service"}
          exported_namespace: {resource: "namespace"}
          exported_pod: {resource: "pod"}
      metricsQuery: max by (exported_namespace, exported_container) (round(max_over_time(<<.Series>>[1m])))

When checking if metrics exist or not, got this response:

 kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1 | jq -r . | grep DCGM_FI_DEV_FB_USED_AVG
      "name": "pods/DCGM_FI_DEV_FB_USED_AVG",
      "name": "namespaces/DCGM_FI_DEV_FB_USED_AVG",

Please provide the HPA resource used for autoscaling:

HPA yaml

HPA yaml for both service is here:
Not Working one:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: serviceA-memory-utilization-hpa
  namespace: development
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name:  serviceA
  minReplicas: 1
  maxReplicas: 2
  metrics:
  - type: Pods
    pods:
      metric:
        name: DCGM_FI_DEV_FB_USED_AVG
      target:
        type: AverageValue
        averageValue: 20000

Working One:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: serviceB-memory-utilization-hpa
  namespace: common-service-development
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name:  serviceB
  minReplicas: 1
  maxReplicas: 2
  metrics:
  - type: Pods
    pods:
      metric:
        name: DCGM_FI_DEV_FB_USED_AVG
      target:
        type: AverageValue
        averageValue: 20000

Please provide the HPA status:
We observed these events in both services time to time, also sometime it is able to collect the metric for ServiceB
but not for serviceA most of the time.
Events:
  Type     Reason                        Age                 From                       Message
  ----     ------                        ----                ----                       -------
  Warning  FailedComputeMetricsReplicas  26m (x12 over 30m)  horizontal-pod-autoscaler  invalid metrics (1 invalid out of 1), first error is: failed to get pods metric value: unable to get metric DCGM_FI_DEV_FB_USED_AVG: no metrics returned from custom metrics API
  Warning  FailedGetPodsMetric           22s (x74 over 30m)  horizontal-pod-autoscaler  unable to get metric DCGM_FI_DEV_FB_USED_AVG: no metrics returned from custom metrics API

And it is the HPA status, it seems it is able to get the memory utilization, but while we describe hpa we observed issues as stated earlier that hpa is unable to collect metrics neither trigger scaling activity.
serviceA-memory-utilization-hpa      Deployment/serviceA            19675/20k   1         2         1          14m
serviceB-memory-utilization-hpa      Deployment/serviceB             19675/20k   1         2         2          11m

Please provide the prometheus-adapter logs with -v=6 around the time the issue happened:

prometheus-adapter logs

Anything else we need to know?:
Environment:

prometheus-adapter version: prometheus-adapter-3.2.2        v0.9.1

prometheus version: kube-prometheus-stack-56.6.2    v0.71.2

Kubernetes version (use kubectl version): Client Version: v1.28.3-eks-e71965b
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.26.12-eks-5e0fdde

Cloud provider or hardware configuration: AWS EKS

Other info:

/cc @CatherineF-dev
/assign @dgrisonnet
/triage accepted

Starting from v0.11.0, the file corresponding to this link does not exist, which may be the cause

Just curious, How does the raw data from prometheus for DCGM_FI_DEV_GPU_UTIL{} look like?

Just curious, How does the raw data for DCGM_FI_DEV_GPU_UTIL{} from prometheus look like?

something like this @dvp34

authors: aurifolia dashpole durga-hp durprasa mayyyyying saad946

repo: kubernetes-sigs/prometheus-adapter


text:
make all fails

What happened:
I have forked the repo and try to run make and it failed.
What you expected to happen:
make to succeed
How to reproduce it (as minimally and precisely as possible):
make all
mkdir -p build
go build -ldflags '-s -w -linkmode external -extldflags "-static" -X sigs.k8s.io/security-profiles-operator/internal/pkg/version.buildDate='2021-01-12T16:15:06Z' -X sigs.k8s.io/security-profiles-operator/internal/pkg/version.gitCommit=c7f337312e70b657af8e8c51b9310c47ea74f2a7 -X sigs.k8s.io/security-profiles-operator/internal/pkg/version.gitTreeState=clean -X sigs.k8s.io/security-profiles-operator/internal/pkg/version.version=0.3.0-dev' -tags 'netgo osusergo' -o build/security-profiles-operator ./cmd/security-profiles-operator
# github.com/containers/common/pkg/seccomp
../../../../pkg/mod/github.com/containers/common@v0.29.0/pkg/seccomp/supported.go:38:12: undefined: unix.Prctl
../../../../pkg/mod/github.com/containers/common@v0.29.0/pkg/seccomp/supported.go:38:23: undefined: unix.PR_GET_SECCOMP
../../../../pkg/mod/github.com/containers/common@v0.29.0/pkg/seccomp/supported.go:40:13: undefined: unix.Prctl
../../../../pkg/mod/github.com/containers/common@v0.29.0/pkg/seccomp/supported.go:40:24: undefined: unix.PR_SET_SECCOMP
../../../../pkg/mod/github.com/containers/common@v0.29.0/pkg/seccomp/supported.go:40:45: undefined: unix.SECCOMP_MODE_FILTER
make: *** [build/security-profiles-operator] Error 2

Anything else we need to know?:
A better contributing guide would be helpful. I will do a PR to bootstrap when I can get past this.
Environment:

Cloud provider or hardware configuration:
OS (e.g: cat /etc/os-release): osx
Kernel (e.g. uname -a):
Others:

Here are Github actions run for osx which has the same issue https://github.com/naveensrinivasan/security-profiles-operator/runs/1698062285?check_suite_focus=true

Here are Github actions run for osx which has the same issue https://github.com/naveensrinivasan/security-profiles-operator/runs/1698062285?check_suite_focus=true


text:
Reuse original gpg key for Ubuntu e2e tests

What type of PR is this?
/kind failing-test
What this PR does / why we need it:
The issue seems to be resolved and therefore we can move back to use the original remote key.
Which issue(s) this PR fixes:

None
Does this PR have test?
None

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

None

Codecov Report

Merging #1507 (1256928) into main (2ad15b7) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1507   +/-   ##
=======================================
  Coverage   43.85%   43.85%
=======================================
  Files          51       51
  Lines        5724     5724
=======================================
  Hits         2510     2510
  Misses       3093     3093
  Partials      121      121

authors: codecov-commenter saschagrunert


text:
docs: pin to CRD manifests to v0.1.0

What type of PR is this?

/kind documentation
What this PR does / why we need it:
Pins the manifests being pulled to v0.1.0. This ensures that any problematic changes in the master branch do not affect end users immediately.
Which issue(s) this PR fixes:

Fixes #502
Does this PR introduce a user-facing change?:

NONE

Thanks!
/lgtm

authors: hbagdi robscott

repo: kubernetes-sigs/service-apis


text:
Can't register any broker, the webhook request times out

Bug Report
What happened: I've installed the catalog chart but I can't register any broker. I've tried with both a custom broker and ups-broker. This is the error no matter how I try it (both with svcat and YAML)
Error: register request failed (Internal error occurred: failed calling webhook "mutating.clusterservicebrokers.servicecatalog.k8s.io": Post "https://catalog-catalog-webhook.catalog.svc:443/mutating-clusterservicebrokers?timeout=30s": context deadline exceeded)

What you expected to happen: Being able to register the broker
How to reproduce it (as minimally and precisely as possible):
helm install catalog ./catalog-0.3.1.tgz --namespace catalog
helm install ups-broker ./ups-broker-0.3.1.tgz --namespace ups-broker
svcat register ups-broker --url http://ups-broker-ups-broker.ups-broker --scope cluster

Anything else we need to know?:
Environment:

Kubernetes version (use kubectl version): 1.20 via k3s versoin v1.20.0+k3s2

service-catalog version: 0.3.1

Cloud provider or hardware configuration:

Do you have api aggregation enabled?

Do you see the configmap in kube-system? Yes, I can see extension-apiserver-authentication
Does it have all the necessary fields? Yes

kubectl get cm -n kube-system extension-apiserver-authentication -o yaml and look for requestheader-XXX fields
This is what I get:

  apiVersion: v1
  data:
    client-ca-file: |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----
    requestheader-allowed-names: '["system:auth-proxy"]'
    requestheader-client-ca-file: |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----
    requestheader-extra-headers-prefix: '["X-Remote-Extra-"]'
    requestheader-group-headers: '["X-Remote-Group"]'
    requestheader-username-headers: '["X-Remote-User"]'
  kind: ConfigMap
  metadata:
    creationTimestamp: "2020-12-31T19:24:17Z"
    managedFields:
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        f:data:
          .: {}
          f:client-ca-file: {}
          f:requestheader-allowed-names: {}
          f:requestheader-client-ca-file: {}
          f:requestheader-extra-headers-prefix: {}
          f:requestheader-group-headers: {}
          f:requestheader-username-headers: {}
      manager: k3s
      operation: Update
      time: "2020-12-31T19:24:17Z"
    name: extension-apiserver-authentication
    namespace: kube-system
    resourceVersion: "28"
    uid: a96a8b17-1665-42e5-af65-e25508e8c857

Install tools:

Did you use helm? What were the helm arguments? Did you --set any extra values? I've changed the image urls adding -arm64 in values.yml, directly inside the chart package.

  helm install catalog ./catalog-0.3.1.tgz --namespace catalog
  helm install ups-broker ./ups-broker-0.3.1.tgz --namespace ups-broker
  svcat register ups-broker --url http://ups-broker-ups-broker.ups-broker --scope cluster

Are you trying to use ALPHA features? Did you enable them? No

I have checked the broker ups-broker is live and reachable via DNS from the catalog namespace. For instance I can k exec -ti dnsutils -n catalog -- wget --header="X-Broker-API-Version: 2.16" -O - http://ups-broker-ups-broker.ups-broker/v2/catalog

I have checked the broker ups-broker is live and reachable via DNS from the catalog namespace. For instance I can k exec -ti dnsutils -n catalog -- wget --header="X-Broker-API-Version: 2.16" -O - http://ups-broker-ups-broker.ups-broker/v2/catalog

Okay I was able to solve the issue, it was an issue in my node hosting the catalog. I noticed the node wasn't able to send back the responses to the master because it was missing the ip route to handle packets with master's IP. The flannel.1 interface was missing for the master IP.
These are the steps I've taken to debug. Your issue might be different, but I hope this helps:

Check if the pods are running okay, both using kubectl and reading the logs
Check if the services are reachable by DNS from other pods in the namespace. Dump TCP packets flowing through the network device responsible for the k8s networking. In my case it's flannel and I dumped all TCP packets going in/out flannel.1. You can filter by source IP or host IP. You should see TCP packets going in/out when a request reaches the catalog service.
Check if the master can reach the catalog service by DNS or by using the service ClusterIP.

In my case I noticed that the master was able to send the packet to the service but I only saw Start packets, without ACK or anything going back to the master. That's when I got suspicious and I noticed the missing network interface for the master. Re-installing the cluster and rebooting solved the issue.

Okay I was able to solve the issue, it was an issue in my node hosting the catalog. I noticed the node wasn't able to send back the responses to the master because it was missing the ip route to handle packets with master's IP. The flannel.1 interface was missing for the master IP.
These are the steps I've taken to debug. Your issue might be different, but I hope this helps:

Check if the pods are running okay, both using kubectl and reading the logs
Check if the services are reachable by DNS from other pods in the namespace. Dump TCP packets flowing through the network device responsible for the k8s networking. In my case it's flannel and I dumped all TCP packets going in/out flannel.1. You can filter by source IP or host IP. You should see TCP packets going in/out when a request reaches the catalog service.
Check if the master can reach the catalog service by DNS or by using the service ClusterIP.

In my case I noticed that the master was able to send the packet to the service but I only saw Start packets, without ACK or anything going back to the master. That's when I got suspicious and I noticed the missing network interface for the master. Re-installing the cluster and rebooting solved the issue.

repo: kubernetes-sigs/service-catalog


text:
Make the metrics port configurable

This PR is a

[ ] Feature Implementation
[ ] Bug Fix
[ ] Documentation

What this PR does / why we need it:
Webhooks uses sigs.k8s.io/controller-runtime/pkg/manager module that by default binds 8080 port to expose metrics. I need to use host network for webhooks and this port is already occupied. that's why I need to make it configurable.
Please leave this checklist in the PR comment so that maintainers can ensure a good PR.
Merge Checklist:

[ ] New feature

[ ] Tests
[ ] Documentation

[ ] SVCat CLI flag
[ ] Server Flag for config

[ ] Chart changes
[ ] removing a flag by marking deprecated and hiding to avoid
breaking the chart release and existing clients who provide a
flag that will get an error when they try to update

/assign @piotrmiskiewicz
CI pipeline fail and I don't know why. @piotrmiskiewicz can you help me?

ci isn't running because you haven't signed the CLA for contributing to Kubernetes. Additionally, I don't think we let people insert random copyright into our projects, you have to contribute under the guidelines for contributing to Kubernetes

authors: jberkhahn shiresky


text:
move testing from jenkins to prow

Is this a request for help?: Yes? (ish)

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

/kind bug
Version of Helm and Kubernetes: n/a
Which chart: n/a
What happened: The Google test-infra team's Jenkins is going away in favor of Prow which has less maintenance and runs / tests on Kubernetes natively https://github.com/kubernetes/test-infra/issues/3778, this repo is one of the last places Jenkins-based presubmits still run for.
What you expected to happen: These tests should be able to run in a kubernetes pod on prow which has better integration for e2e testing etc.
How to reproduce it (as minimally and precisely as possible): n/a
Anything else we need to know: I'm willing to help with this, but I'd rather not have to do everything (I at least would like help knowing what environment / binaries the presubmit depends on) and Jenkins is going away soon.

Ideally both the presubmit and periodic/CI/postsubmit jobs should be moved, but the presubmit Jenkins will be going away before the CI Jenkins.

@BenTheElder Is there documentation on how to migrate this?

@mattfarina I don't think there is any in particular, it's just adding a new prow job (which there are docs for) that runs the same tests in a new environment. For some of the other repos we definitely can't have a guide because someone along the way setup snowflake VMs just for those jobs...
If someone can tell me what the job needs at runtime I can work on creating jobs for it if nobody else does first.
It doesn't take long to switch to a prow job but we need an image / pod that will provide the right tools etc and since Jenkins jobs typically weren't containerized I don't know what this repo uses.

@BenTheElder The entry point for Jenkins is https://github.com/kubernetes/charts/blob/master/test/e2e.sh. You'll notice it runs another one of the scripts from within a container.
If you beat us to it that would be great. Being that it's the holidays it might take us a few weeks to jump on this. Is that ok?
cc: @viglesiasce
/lifecycle hold

Thanks.

If you beat us to it that would be great. Being that it's the holidays it might take us a few weeks to jump on this. Is that ok?

I'm not personally planning to turn off anything, but I know we'd like to get rid of Jenkins sooner rather than later just to reduce the number of things we maintain. Nearly everything runs on kubernetes now. I'll try to get back to this one soon myself.

/close
There hasn't been any Jenkins for a long time, but charts does have Prow job(s) on kubernetes.

authors: BenTheElder mattfarina

repo: kubernetes/charts


text:
[stable/nginx-ingress] 0.12.2 externalTrafficPolicy not applied

Is this a request for help?:
yes
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

Version of Helm and Kubernetes:
helm version
Client: v2.8.2
Server: v2.8.0
kubectl version
Client Version: v1.9.5
Server Version: v1.9.4-gke.1
Which chart:
stable/nginx-ingress: 0.12.2
What happened:
When setting controller.service.externalTrafficPolicy = Local, the service spec.externalTrafficPolicy is still defaulted to "Cluster"
What you expected to happen:
the service spec.externalTrafficPolicy is should be "Local"
How to reproduce it (as minimally and precisely as possible):
Create config file (updating loadBalancerIP and Source Range to appropriate values):
# /tmp/values.yml
rbac:
  create: true
controller:
  ingressClass: nginx-static-find-jobs
  replicaCount: 2
  config:
    http-redirect-code: "301"
    body-size: "64m"
    server-name-hash-bucket-size: "256"
    large-client-header-buffers: "8 32k"
  stats:
    enabled: true
  service:
    externalTrafficPolicy: Local
    loadBalancerIP: x.x.x.x
    loadBalancerSourceRanges:
      - 10.0.0.0/8

helm install --name {{ ingress.name }} nginx-ingress --namespace=stage -f /tmp/values.yml
Anything else we need to know:
Running on Google Cloud GKE

I noticed when using 0.14 image and new chart version, it seems to work, so issue can be closed if someone else confirms?


text:
Fix elasticsearch quoting

There were some constraints added in the Kubernetes 1.4 release that caused quoted integers to be rejected when an integer is expected. This fixes those issues in the elasticsearch chart.

@k8s-bot e2e test this

@k8s-bot e2e test this


text:
[stable/dokuwiki] Bump dokuwiki version to 20160626a-r7

Contains fix for https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5340

@k8s-bot ok to test

authors: andresbono viglesiasce


text:
[Cinder CSI] ExpandVolume will eventyally change Microversion to 3.42

What happened:
As all CSI calls can be called simultaneously by multiple threads you should never modify global objects like os.blockstorage. As eventually some thread will fetch the temporary change as initial and then save it later. So then the "temporary" change will become permanent.
If special client is needed it should be created for that call so that parallel calls would not mess up each others.
Anything else we need to know?:
It was implement in https://github.com/kubernetes/cloud-provider-openstack/pull/620
and "fixed" in https://github.com/kubernetes/cloud-provider-openstack/pull/786
/kind bug

@mape90 I'm confused , as per issue description , it already says fixed in #786 , so what else is expected ?

@ramineni it is "fixed" because the fix do not actually fix anything. It fixes the problem when you only execute one resize action at time. However in real environments you will eventually have multiple simultaneous resize actions and each thread will modify the same object and that cause race condition where the temporary value is stored as initial. That fix just isn't thread safe.
Also as it changes global object it will have affect to all other actions that are done during that resize action. It could be fixed by just adding lock so that only one thread can access it by any time. However this defeats the purpose of having multiple threads.
So if that micro version change is needed it is safer to do it in own client object. It will have small performance hit as you need to reauthenticate  against the API but it would not them mess up any other actions that would be simultaneously be made.

@mape90 Thanks for detail info. Got it.

@mape90 thanks for the bug report, I totally missed this case.
from my point of view there can be at least four kinds of fix:

set permanent minimal microversion during the initialization
create a deep copy of the client during the resize action
create a client from the global authed provider client for each resize action (NewBlockStorageV3)
modify gophercloud to support calls with a microversion as a parameter

each of the solution have pros and cons. @ramineni , @mape90 do you have other suggestions?

@kayrus how the version is set initially for the client? Is just gophercloud hardcoded thing or is it determined during authentication?
Also is is common that you can resize with this microversion, but then other calls will fail using this microversion?
If it just everything works or nothing works then global override flag is best option as then behavior is deterministic. Then we could just check the microversion and report that resize isn't supported.
If openstack allows certain operations with this microversion and fails with others then separate global object is good option.

@mape90 initially microversion is not set, because most of the standard operations don't require it. However it must be set for live resize operations. Also you have to remember that some later microversions can remove functionality, which was supported in earlier microversions.
Supported microversions can be checked during the client initialization, but unfortunately this feature is supported only for limited resource types in gophercloud.

authors: kayrus mape90 ramineni

repo: kubernetes/cloud-provider-openstack


text:
hyper: filter images with image name

The hyper ImageList API does not support filter format
name@tag. Just filter with image name.
Fixes #286

This change is

CI would pass when combined with #291
see https://travis-ci.org/bergwolf/frakti/builds/340075484

This commit has been added into #291, so closed.

authors: bergwolf k8s-reviewable resouer

repo: kubernetes/frakti


text:
Add gzip compression for kafka sinks

Currently kafka sends events and metrics uncompressed, which causes huge sizes.

This change is

I signed it!

repo: kubernetes/heapster


text:
indicate the status of this repo

I believe this project is no longer in active development, yet it still serves certain purpose. We should indicate whatever is the case in the readme and repo description, so that it's clear to a newcomer what this is.
cc @roberthbailey @timothysc

AFAIK the main purpose of this project is to enable end to end testing of kubeadm (since kubeadm itself doesn't provision infrastructure). Other than that, it isn't being actively maintained and once kubeadm has a different solution for e2e tests we plan to archive it.

the easiest way would be to change the repo description in the lines of:
(NOTE: This project is deprecated and used only for kubeadm e2e tests) {concise,reliable,cross-platform} turnup of Kubernetes clusters

Is there any plan for something different?

https://github.com/kubernetes-sigs/cluster-api

/lifecycle frozen

Does this describe the current state well enough https://github.com/kubernetes/kubernetes-anywhere/pull/577?

Closing the issue since the repo is being archived: https://github.com/kubernetes/org/issues/1812

authors: errordeveloper luxas neolit123 nikhita roberthbailey thockin

repo: kubernetes/kubernetes-anywhere


text:
Seccomp support isn't documented

I didn't find anything except proposal about supporting seccomp profiles.

@php-coder have you been able to use seccomp with Kubernetes. It doesn’t seem like the feature has been implemented and released yet.

@ahmetb No, I didn't use it. But because it's undocumented how it's supposed that user will know about it? The only way at present is to reading sources.

@php-coder :wave: Thanks for opening this issue. Because support for seccomp remains proposed but not implemented, I'm going to close this issue until it's actionable for docs.

Another attempt:
/reopen

So far there is only how to control it's usage with PSP: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp I'm not sure whether it's enough or not.

Let's keep this open.
/remove-lifecycle stale

authors: ahmetb php-coder tengqm zacharysarah


text:
cl2/density: add pod-affinty workload to scheduler suite

What type of PR is this?
/kind feature
What this PR does / why we need it: This PR adds the pod-affinity test to the suite of scheduler benchmark(s) we have.
Which issue(s) this PR fixes:
Related to https://github.com/kubernetes/perf-tests/issues/1414
Special notes for your reviewer: No.
Does this PR introduce a user-facing change?:
NONE

/sig scheduling
/sig testing
/cc @ahg-g @mm4tt

I've tested this locally with my personal cluster to make sure everything looks correct, but I don't think my local throughput/latency metrics will be useful to anyone as I'm temporarily using a real cluster to test with instead of kubemark (because my kubemark set up broke for some reason).

Added the vanilla workload to the suite for two reasons:

Everything else is kept constant if we use the scheduler suite instead of a separate job for the vanilla workload (even though the two jobs are very similar right now).
Convenience: it's easier to switch between different workloads whilst maintaining the same metrics in perf-dash if the job name doesn't have to change (changing job name resets other dropdowns).

Added the vanilla workload to the suite for two reasons:

Everything else is kept constant if we use the scheduler suite instead of a separate job for the vanilla workload (even though the two jobs are very similar right now).
Convenience: it's easier to switch between different workloads whilst maintaining the same metrics in perf-dash if the job name doesn't have to change (changing job name resets other dropdowns).

for 5k runs this may not be cheap though, but differing to Matt on this.
/lgtm from the scheduler

Added the pod topology spreading workload as well. Re-pasting the commit message:
cl2/density: add pod topology spread workload to scheduler suite

This pod topology spread workload uses the hostname as the topology key
create a spreading deployment with a max skew of 1. This is effectively
a round-robin.

The hostname was used as the topology key due to the lack of a better
label. Ideally, I would've wanted to benchmark zone spreading with
topology.kubernetes.io/zone as the topology key, but since all Kubemark
kubemark nodes have identical labels except for kubernetes.io/hostname,
this is the only viable option. In the future, we can look into the
following options to make this more even representative of a real
workload:

1. Make Kubemark hollow nodes be actually present in different GCP
   zones, thereby guaranteeing that each node has a different
   topology.kubernetes.io/zone.
2. Set a dummy label on hollow nodes to be used as the spreading
   topology key at Kubemark cluster creation time. This would probably
   be a kubetest change.
3. Allow setting and clearing node labels as a part of clusterloader.

I think (3) is the cleanest option if we end up doing this, but whether
or not setting node labels is within the scope of clusterloader is
debatable.

Scheduling 1000 saturation pods onto a personal cluster, I've verified that spreading works as expected -- after scheduling each pod, the difference between the maximum and minimum number of pods running on each node is never greater than 1 (except for once or twice, but that's expected due to ScheduleAnyway).

/test pull-perf-tests-verify-lint

/lgtm
/approve

authors: adtac ahg-g mm4tt

repo: kubernetes/perf-tests


text:
Fixing dnsperf build

There was a missing library, the libxml2-dev on the build and libcrypto1.0 on the final image. I have also changed a little bit the apk command.
How to replicate the issue ?
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 17.04
Release:	17.04
Codename:	zesty

$ git clone git@github.com:kubernetes/perf-tests.git
$ cd dns/image/
$ make
[some lines omitted]
docker run --rm -v `pwd`/build/src:/src kube-dns-perf-client-build \
	/bin/sh -c "cd /src && ./configure && make -j"
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking for inline... inline
checking for socket in -lsocket... no
checking for inet_ntoa in -lnsl... no
checking for isc-config.sh... /usr/bin/isc-config.sh
checking for socklen_t... yes
checking for sa_len... no
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
configure: creating ./config.status
config.status: creating Makefile
gcc -g -O2 -I/usr/include -D_REENTRANT -D_GNU_SOURCE -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_PTHREAD=1  -c dnsperf.c
gcc -g -O2 -I/usr/include -D_REENTRANT -D_GNU_SOURCE -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_PTHREAD=1  -c datafile.c
gcc -g -O2 -I/usr/include -D_REENTRANT -D_GNU_SOURCE -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_PTHREAD=1  -c dns.c
gcc -g -O2 -I/usr/include -D_REENTRANT -D_GNU_SOURCE -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_PTHREAD=1  -c log.c
gcc -g -O2 -I/usr/include -D_REENTRANT -D_GNU_SOURCE -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_PTHREAD=1  -c net.c
gcc -g -O2 -I/usr/include -D_REENTRANT -D_GNU_SOURCE -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_PTHREAD=1  -c opt.c
gcc -g -O2 -I/usr/include -D_REENTRANT -D_GNU_SOURCE -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_PTHREAD=1  -c os.c
gcc -g -O2 -I/usr/include -D_REENTRANT -D_GNU_SOURCE -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DHAVE_PTHREAD=1  -c resperf.c
In file included from datafile.c:32:0:
util.h:60:0: warning: "LOCK" redefined
 #define LOCK(mutex) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from datafile.c:26:
/usr/include/isc/util.h:90:0: note: this is the location of the previous definition
 #define LOCK(lp) do { \

In file included from datafile.c:32:0:
util.h:67:0: warning: "UNLOCK" redefined
 #define UNLOCK(mutex) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from datafile.c:26:
/usr/include/isc/util.h:101:0: note: this is the location of the previous definition
 #define UNLOCK(lp) do { \

In file included from datafile.c:32:0:
util.h:81:0: warning: "SIGNAL" redefined
 #define SIGNAL(cond) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from datafile.c:26:
/usr/include/isc/util.h:120:0: note: this is the location of the previous definition
 #define SIGNAL(cvp) do { \

In file included from datafile.c:32:0:
util.h:88:0: warning: "BROADCAST" redefined
 #define BROADCAST(cond) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from datafile.c:26:
/usr/include/isc/util.h:113:0: note: this is the location of the previous definition
 #define BROADCAST(cvp) do { \

In file included from datafile.c:32:0:
util.h:95:0: warning: "WAIT" redefined
 #define WAIT(cond, mutex) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from datafile.c:26:
/usr/include/isc/util.h:127:0: note: this is the location of the previous definition
 #define WAIT(cvp, lp) do { \

In file included from resperf.c:66:0:
util.h:60:0: warning: "LOCK" redefined
 #define LOCK(mutex) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from resperf.c:49:
/usr/include/isc/util.h:90:0: note: this is the location of the previous definition
 #define LOCK(lp) do { \

In file included from resperf.c:66:0:
util.h:67:0: warning: "UNLOCK" redefined
 #define UNLOCK(mutex) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from resperf.c:49:
/usr/include/isc/util.h:101:0: note: this is the location of the previous definition
 #define UNLOCK(lp) do { \

In file included from resperf.c:66:0:
util.h:81:0: warning: "SIGNAL" redefined
 #define SIGNAL(cond) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from resperf.c:49:
/usr/include/isc/util.h:120:0: note: this is the location of the previous definition
 #define SIGNAL(cvp) do { \

In file included from resperf.c:66:0:
util.h:88:0: warning: "BROADCAST" redefined
 #define BROADCAST(cond) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from resperf.c:49:
/usr/include/isc/util.h:113:0: note: this is the location of the previous definition
 #define BROADCAST(cvp) do { \

In file included from resperf.c:66:0:
util.h:95:0: warning: "WAIT" redefined
 #define WAIT(cond, mutex) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from resperf.c:49:
/usr/include/isc/util.h:127:0: note: this is the location of the previous definition
 #define WAIT(cvp, lp) do { \

In file included from dnsperf.c:75:0:
util.h:60:0: warning: "LOCK" redefined
 #define LOCK(mutex) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from dnsperf.c:55:
/usr/include/isc/util.h:90:0: note: this is the location of the previous definition
 #define LOCK(lp) do { \

In file included from dnsperf.c:75:0:
util.h:67:0: warning: "UNLOCK" redefined
 #define UNLOCK(mutex) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from dnsperf.c:55:
/usr/include/isc/util.h:101:0: note: this is the location of the previous definition
 #define UNLOCK(lp) do { \

In file included from dnsperf.c:75:0:
util.h:81:0: warning: "SIGNAL" redefined
 #define SIGNAL(cond) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from dnsperf.c:55:
/usr/include/isc/util.h:120:0: note: this is the location of the previous definition
 #define SIGNAL(cvp) do { \

In file included from dnsperf.c:75:0:
util.h:88:0: warning: "BROADCAST" redefined
 #define BROADCAST(cond) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from dnsperf.c:55:
/usr/include/isc/util.h:113:0: note: this is the location of the previous definition
 #define BROADCAST(cvp) do { \

In file included from dnsperf.c:75:0:
util.h:95:0: warning: "WAIT" redefined
 #define WAIT(cond, mutex) do {      \

In file included from /usr/include/isc/magic.h:14:0,
                 from /usr/include/isc/buffer.h:100,
                 from dnsperf.c:55:
/usr/include/isc/util.h:127:0: note: this is the location of the previous definition
 #define WAIT(cvp, lp) do { \

dns.c: In function 'name_fromstring':
dns.c:187:2: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
  isc_buffer_init(&buffer, str, len);
  ^~~~~~~~~~~~~~~
dnsperf.c: In function 'print_statistics':
dnsperf.c:352:28: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'isc_uint64_t {aka long long unsigned int}' [-Wformat=]
    printf("#histogram %u %lu\n", i, stats->rtt_histogram[i]);
                            ^
ar rv libperf.a datafile.o dns.o log.o net.o opt.o os.o
a - datafile.o
ar: creating libperf.a
a - dns.o
a - log.o
a - net.o
a - opt.o
a - os.o
ranlib libperf.a
gcc  resperf.o  libperf.a  -L/usr/lib -lbind9 -ldns -lcrypto -lisccfg -lisc -ldl -lcap -lpthread -lxml2 -L/lib -lz -lm  -lm -o resperf
/usr/lib/gcc/x86_64-alpine-linux-musl/6.4.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lxml2
collect2: error: ld returned 1 exit status
make: *** [Makefile:32: resperf] Error 1
make: *** Waiting for unfinished jobs....
Makefile:37: recipe for target 'build/src/dnsperf' failed
make: *** [build/src/dnsperf] Error 2

@bowei

/lgtm

/approve

authors: bowei gmarek migueleliasweb


text:
Kubernetes Third-Party Security Audit for 2021-22 (tracking issue)

Tracking issue for the Kubernetes third-party security audit for 2021:

[X] Create RFP

[X] Audit scope
[X] Finalize dates: RFP opening and closing dates, question period, vendor selection
[X] Complete question period and publish questions & replies to RFP

[x] Vendor assessment

[x] Assemble vendor assessment group
[x] Create private Google group

[x] Release vendor selection
[x] Publish findings

/sig security
/label external-audit

These things take time, triage-bot.
/remove-lifecycle stale
Although, given the bleed-over, the this could be renamed * for 2022.

/retitle Kubernetes Third-Party Security Audit for 2021-22 (tracking issue)

/remove-lifecycle stale

/remove-lifecycle stale

/remove-lifecycle rotten

/remove-lifecycle stale

This issue is complete :tada: with the merge of PR https://github.com/kubernetes/sig-security/pull/87
and publishing of the CNCF blog https://www.cncf.io/blog/2023/04/19/new-kubernetes-security-audit-complete-and-open-sourced/
/close

Findings published at https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes v1.24 Final Report.pdf

authors: PurelyApplied PushkarJ reylejano

repo: kubernetes/sig-security


text:
Document previous learning sessions in SIG Security Tooling

Description

Create a markdown table that lists all the learning sesions here: https://www.youtube.com/playlist?list=PLrQN4xC6U5D9I0LGJxZuXbfvi1qwPqcim to celebrate past presenters and encourage new speakers!

Please note some of these are working session and some are learning sessions. For more context, refer the meeting minutes page: https://docs.google.com/document/d/1_Rn7S8UPMtXdu6EDl4_L2Ogb433z7hlxPs7El8TfNNg/edit

The markdown file learning-sessions.md can exist under this directory https://github.com/kubernetes/sig-security/tree/main/sig-security-tooling

Pre-requisites
Somebody working on this would need:

Basic markdown skills or desire to learn them
Become a member of https://groups.google.com/g/kubernetes-sig-security to access the meeting minutes

Format

date
topic
speaker
link

02-21-2022
Learning session template
Goose geese
youtube.url

/sig security
/kind cleanup

/good-first-issue
/help wanted

/assign @chetak123

Hey @mhammadsaani I am working on this issue (actually I was AFK for few days due to some personal work), and I will be making PR soon.

@chetak123 - is this issue closed by #47 ?

authors: PushkarJ cailynse chetak123


text:
Translate concepts/services-networking/dns-pod-service in Korean

This is a Feature Request

What would you like to be added

Translate concepts/services-networking/dns-pod-service in Korean
Why is this needed
concepts/services-networking/dns-pod-service is not yet translated in Korean
Comments

Page to update : https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

/language ko
/assign

/kind feature
/priority backlog

authors: purelledhand sftim

repo: kubernetes/website


text:
[zh] Concept files to sync for 1.22

(1) Secret Rewriting
32	26	content/zh/docs/concepts/configuration/secret.md

(2) Pod Security Standards Revision
376	184	content/zh/docs/concepts/security/pod-security-standards.md

(3) Persistent Volume
125	40	content/zh/docs/concepts/storage/persistent-volumes.md

(4) Flow Control
83	53	content/zh/docs/concepts/cluster-administration/flow-control.md

(5) Workload Controllers
4	3	content/zh/docs/concepts/workloads/controllers/cron-jobs.md
35	22	content/zh/docs/concepts/workloads/controllers/daemonset.md
29	15	content/zh/docs/concepts/workloads/controllers/statefulset.md
2	2	content/zh/docs/concepts/workloads/controllers/replicaset.md
55	22	content/zh/docs/concepts/workloads/controllers/job.md

(6) Policies

20	14	content/zh/docs/concepts/policy/resource-quotas.md
13	6	content/zh/docs/concepts/policy/pid-limiting.md
50	10	content/zh/docs/concepts/policy/pod-security-policy.md

(7) Pods

13	3	content/zh/docs/concepts/workloads/pods/pod-lifecycle.md
2	2	content/zh/docs/concepts/workloads/pods/disruptions.md
7	4	content/zh/docs/concepts/workloads/pods/init-containers.md
4	116	content/zh/docs/concepts/workloads/pods/ephemeral-containers.md
14	2	content/zh/docs/concepts/workloads/pods/_index.md

(8) Service

14	5	content/zh/docs/concepts/services-networking/network-policies.md
0	1	content/zh/docs/concepts/services-networking/endpoint-slices.md
44	10	content/zh/docs/concepts/services-networking/service.md
6	1	content/zh/docs/concepts/services-networking/ingress.md
16	3	content/zh/docs/concepts/services-networking/dns-pod-service.md

(9) Scheduling

**removed**	content/zh/docs/concepts//scheduling-eviction/eviction-policy.md
1	1	content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
9	9	content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md
2	2	content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
27	26	content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md
19	6	content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md
2	2	content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md
2	2	content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md

(10) Storage

33	4	content/zh/docs/concepts/storage/storage-classes.md
25	48	content/zh/docs/concepts/storage/volumes.md

(11) Basic Objects

17	2	content/zh/docs/concepts/containers/images.md
4	4	content/zh/docs/concepts/containers/runtime-class.md
13	2	content/zh/docs/concepts/overview/working-with-objects/names.md
1	1	content/zh/docs/concepts/overview/working-with-objects/field-selectors.md
4	5	content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
5	0	content/zh/docs/concepts/overview/working-with-objects/annotations.md
2	2	content/zh/docs/concepts/overview/working-with-objects/labels.md

(12) Cluster Admin

5	1	content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
3	1	content/zh/docs/concepts/security/overview.md
1	1	content/zh/docs/concepts/architecture/cloud-controller.md
60	2	content/zh/docs/concepts/architecture/nodes.md
1	1	content/zh/docs/concepts/cluster-administration/manage-deployment.md
**removed**	content/zh/docs/concepts//cluster-administration/kubelet-garbage-collection.md
5	2	content/zh/docs/concepts/cluster-administration/logging.md
**removed**	content/zh/docs/concepts//workloads/controllers/garbage-collection.md

(13) k8s Extension

11	2	content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
2	2	content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
3	3	content/zh/docs/concepts/extend-kubernetes/operator.md

/language zh
/help

/triage accepted

@mengjiao-liu @zhangguanzhang @kerthcet @rudeigerc @hide-in-code @able8 @jaronnie @keashem @loufenghua @chenxuc @howieyuen @dcoliversun @liuxu623 @eatjeff @liutaot @gaoguangze111 @buptliuwei @HongjiangHuang @zhiguo-lu @timyinshi

I want to try this aspect of synchronous scheduling.
(9) Scheduling

**removed**	content/zh/docs/concepts//scheduling-eviction/eviction-policy.md
1	1	content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md
9	9	content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md
2	2	content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
27	26	content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md
19	6	content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md
2	2	content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md
2	2	content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md

part 1：https://github.com/kubernetes/website/pull/29823

(3) Persistent Volume https://github.com/kubernetes/website/pull/30002

(4) is already updated to latest version.
see https://github.com/kubernetes/website/pull/29866

I might need help getting these PR merged. (reviewed by @tengqm, need another LGTM)
(2) #29996
(3) #30002
And these ones need to be reviewed:
(5) #30014
(6) #30015
(7) #30032
(11) #30037

We have completed this umbrella issue!!! A big thank you to y'all!
/close

authors: howieyuen mayocream mengjiao-liu tengqm


text:
Interactive Tutorial - Exploring Your App

In module 3 interactive terminal does not create any pod.
kubectl get pods returns : No resources found in default namespace.
kubectl describe pods returns : No resources found in default namespace.

it is working as expected.

Hello, Unfortunatly I still get the same problem.  MVH / Best regardsTel: +46 (0) 723 41 99 77 From: TamilselvanSent: den 8 februari 2023 05:01To: kubernetes/websiteCc: mkhaledi; AuthorSubject: Re: [kubernetes/website] Interactive Tutorial - Exploring Your App (Issue #39327) it is working as expected.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

The same issue is also mentioned here - https://github.com/kubernetes/website/issues/38323
/triage duplicate

/language en

/close
Won't fix because we're removing Katacoda.

authors: mkhaledi tamilselvan1102 tengqm


text:
Change approvers to reviewers in front matter

This is a...

[x] Feature Request
[ ] Bug Report

Problem:
In several topics, in the front matter, we have an approvers list. But we want to restrict our approvers list to people in sig-docs-maintainers. And we the people who are automatically suggested as approvers to be restricted to those in sig-docs-maintainers.
Here's an example:
In #7439, we have this suggestion for an approver:
"To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: enisoc
Assign the PR to them by writing /assign @enisoc in a comment when ready."
How is it that enisoc was suggested as an approver?
I suspect it's because enisoc is listed as an aprover in the front matter of custom-resources.md.

title: Custom Resources
approvers:

enisoc
deads2k

Here's another example in #7445:
"We suggest the following additional approvers: davidopp, jbeda, jcbsmpsn, justinsb, lavalamp, liggitt, nikhiljindal, random-liu, thockin
Assign the PR to them by writing /assign @davidopp @jbeda @jcbsmpsn @justinsb @lavalamp @liggitt @nikhiljindal @random-liu @thockin in a comment when ready."
Proposed Solution:
In the front matter, change the name of the list from approvers to reviewers.
Page to Update:
Many pages in the kubernetes.io site.
Go to /docs. grep -r approvers

/assign @steveperry-53
/cc @heckj
/cc @chenopis
/cc @Bradamant3

https://github.com/kubernetes/website/pull/8644 is still open.
/remove-lifecycle stale


text:
zh-trans: batch add examples/admin/ yaml files

Relates to https://github.com/k8smeetup/website-tasks/issues/1344

/lgtm


text:
Modify #16415, #16417 korean docs.

This is a backport for #16467

/reopen

@gochist Thank you !
/lgtm
/approve

authors: gochist seokho-son


text:
zh-trans: blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md

zh-trans: blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md
https://github.com/k8smeetup/website-tasks/issues/3666

/review

@xichengliudui @yuxiaobo96 感谢你们的review，我已经修改到最新版本。

/lgtm
/approve

@xichengliudui 可以帮我检查下为什么构建测试会失败吗，我已经修改过了。

/lgtm

authors: Aresforchina tanjunchen xichengliudui yuxiaobo96


text:
Document new API Priority and Fairness metrics

This PR documents the additions made in  https://github.com/kubernetes/kubernetes/pull/91177 and also brushes up the descriptions of some of the older metrics.

The force-push to 800a602e3 fixes a couple of speling misteaks.

@MikeSpreitzer

Would it be possible to get a technical lgtm from @kubernetes/sig-api-machinery-api-reviews ?

@joelbyronbarker : thanks for the review.  I have revised accordingly.

tech
/lgtm

Thanks!
/lgtm
/approve

authors: MikeSpreitzer jimangel lavalamp


text:
Translate docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes/ into Japanese. #23525

Translate docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes/ into Japanese

/assign @nasa9084

/cc @bells17

/approve

/lgtm


text:
support reserved pid for kube and system

support reserved pid for kube and system.
reference：https://kubernetes.io/docs/concepts/policy/pid-limiting/#node-pid-limits

Hi @Cweiping
These are generated documents. Has the equivalent change already been made upstream?
(if you're not sure what that question means, that's OK - we can explain in more detail if it's not clear)

@sftim kubelet doc has been maintained manually since they changed their intialization code a long time ago.

/lgtm

/approve

authors: Cweiping sftim tengqm


text:
Updating runAsNonRoot support for Windows

Signed-off-by: Mark Rossetti marosset@microsoft.com
In v1.20 support for runAsNonRoot on Windows was added to the kubelet.
This PR updates documentation to reflect those changes.
I am also fixing a few minor typos.
/sig windows

Preview of updated page:
https://deploy-preview-30256--kubernetes-io-main-staging.netlify.app/docs/setup/production-environment/windows/intro-windows-in-kubernetes/
This PR has an lgtm and approve from SIG Windows
and also an lgtm from SIG Docs
/lgtm
/approve

authors: marosset reylejano


text:
[zh-cn] Update security/windows-security.md

/approve
/lgtm

authors: howieyuen yanrongshi


text:
Code style requests and limits for apt read

Readability changes for emphasis on requests and limits rather than resource type.

I'm closing this PR since the original text is favored over the changes in this PR
/close

authors: kalyanidani reylejano


text:
[es] Add content/es/docs/concepts/security/pod-security-policy.md

Related the issue https://github.com/kubernetes/website/issues/13948
cc: @electrocucaracha

/lgtm


text:
[ko] Replace deprecated fullversion shortcode for Korean

This PR is to handle the sub-task for Korean in #41005

/assign

/lgtm
/approve

authors: seokho-son ysyukr


text:
[zh] Fix note shortcode rendering in list

Fix shortcode rendering in list, about #44163
Fix list numbers.

See Preview - note.
Compare with current version.


text:
[zh-cn] sync configure-liveness-readiness-startup-probes.md

content/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md

/lgtm
/approve


text:
Add note to PDB about the defaulting behavior change

Ad a note to PDB creation task about the behavior change regarding minAvailable field.
Ref: kubernetes/kubernetes#53047

This change is

Close this one, will resubmit to release-1.9 branch.


text:
bug: cannot install OTP for multiple different WDS

Describe the bug
can only install one OTP per environment - here is what happens when you try for more than 1
install OTP for wds1
helm --kube-context=wds0 install ocm-transport-plugin oci://ghcr.io/kubestellar/ocm-transport-plugin/chart/ocm-transport-plugin --namespace default --create-namespace --version 0.1.2 --set transport_cp_name=its1 --set wds_cp_name=wds1
install OTP for wds0
helm --kube-context=wds0 install ocm-transport-plugin1 oci://ghcr.io/kubestellar/ocm-transport-plugin/chart/ocm-transport-plugin --namespace default --create-namespace --version 0.1.2 --set transport_cp_name=its1 --set wds_cp_name=wds0
Pulled: ghcr.io/kubestellar/ocm-transport-plugin/chart/ocm-transport-plugin:0.1.2
Digest: sha256:e58fb2882d2e3c39de6959b2a02490b537622a6f93e011ed5a298c52c5f11a8e
Error: INSTALLATION FAILED: Unable to continue with install: ClusterRole "transport-controller-role" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "ocm-transport-plugin1": current value is "ocm-transport-plugin"

as you can see, I changed the name of the release here. context is wds0 (the host)
(not supposed to work I guess - but for completeness) if I try to install in context of wds1 for wds1, I get this
helm --kube-context=wds1 install ocm-transport-plugin oci://ghcr.io/kubestellar/ocm-transport-plugin/chart/ocm-transport-plugin --namespace default --create-namespace --version 0.1.2 --set transport_cp_name=its1 --set wds_cp_name=wds1
Pulled: ghcr.io/kubestellar/ocm-transport-plugin/chart/ocm-transport-plugin:0.1.2
Digest: sha256:e58fb2882d2e3c39de6959b2a02490b537622a6f93e011ed5a298c52c5f11a8e
Error: INSTALLATION FAILED: 3 errors occurred:
        * namespaces "wds1-system" not found
        * namespaces "wds1-system" not found
        * namespaces "wds1-system" not found

please advise - unable to proceed with MCAD and MCC due to this bug
Steps To Reproduce
can only install one OTP per environment - here is what happens when you try for more than 1
install OTP for wds1
helm --kube-context=wds0 install ocm-transport-plugin oci://ghcr.io/kubestellar/ocm-transport-plugin/chart/ocm-transport-plugin --namespace default --create-namespace --version 0.1.2 --set transport_cp_name=its1 --set wds_cp_name=wds1
install OTP for wds0
helm --kube-context=wds0 install ocm-transport-plugin1 oci://ghcr.io/kubestellar/ocm-transport-plugin/chart/ocm-transport-plugin --namespace default --create-namespace --version 0.1.2 --set transport_cp_name=its1 --set wds_cp_name=wds0
Pulled: ghcr.io/kubestellar/ocm-transport-plugin/chart/ocm-transport-plugin:0.1.2
Digest: sha256:e58fb2882d2e3c39de6959b2a02490b537622a6f93e011ed5a298c52c5f11a8e
Error: INSTALLATION FAILED: Unable to continue with install: ClusterRole "transport-controller-role" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "ocm-transport-plugin1": current value is "ocm-transport-plugin"

as you can see, I changed the name of the release here. context is wds0 (the host)
please advise
Expected Behavior
OTP helm install should work for multiple
Additional Context
No response

@clubanderson PR https://github.com/kubestellar/ocm-transport-plugin/pull/10 fixes a bug in naming conflicts for cluster-level resources when using multiple WDS

@clubanderson I believe there is also a usage issue. The 2 heml command should

target the same --kube-context, e.g. kubeflex-kind or the root OCP context, not the wds0 and wds1 CPs
the 2 helm chatys should be named differently
the namespace can be shared and left as default asn you are already doing

In summery, once the PR above is implemented, your new commands should be:
helm --kube-context=<cluster context, not CP> upgrade --install wds0-ocm-transport-plugin ocm-transport-plugin oci://ghcr.io/kubestellar/ocm-transport-plugin/chart/ocm-transport-plugin --version 0.1.x --set transport_cp_name=its1 --set wds_cp_name=wds0

helm --kube-context=<cluster context, not CP> upgrade --install wds1-ocm-transport-plugin ocm-transport-plugin oci://ghcr.io/kubestellar/ocm-transport-plugin/chart/ocm-transport-plugin --version 0.1.x --set transport_cp_name=its1 --set wds_cp_name=wds1

wds0 is the core/hub, so it is interchangeable.
I can do the different names, but it requires more customization on my part.
I hope this fix covers the clusterscoped - it looks like it will with the unique naming.
Thank you

@francostellari fix is merged and a new OTP with the updated chart was released - v0.1.3.

@clubanderson if you don't want to keep track of the additional naming of the charts, you can use --generate-name instead of giving a name to the charts

Scenario 2 should also exercise this. I will try it.

I succeeded in running Scenarios 1 and 2 in https://github.com/kubestellar/kubestellar/blob/233f8dde6250e7ff0e10fd778a7d5cbaa9850896/docs/content/direct/examples.md , modified to say export OCM_TRANSPORT_PLUGIN=0.1.3.

yes, I did as well - thank you. The '--generate-name' does not allow me to track the exact instance and therefore makes it impossible to delete or upgrade this chart.
Need another way to install the OTP. I would have hoped the OTP would have somehow been installed in the WDS itself and not in the core. I understand why this is not possible, but the OTP is "owned by" or "associated with" the WDS.

Oh! Scenario 2 does not test that wds1 is still functional after creating wds2. I see that indeed there is just one chart instance ("release").
bash-3.2$ helm --kube-context kind-kubeflex list -A
NAME                	NAMESPACE      	REVISION	UPDATED                                	STATUS  	CHART                          	APP VERSION
kubeflex-operator   	kubeflex-system	1       	2024-04-04 16:24:38.800388 -0400 EDT   	deployed	kubeflex-operator-v0.5.0       	v0.5.0
kubestellar         	wds1-system    	1       	2024-04-04 20:29:24.394069838 +0000 UTC	deployed	controller-manager-chart-0.21.2	0.21.2
kubestellar         	wds2-system    	1       	2024-04-04 16:43:17.253156 -0400 EDT   	deployed	controller-manager-chart-0.21.2	0.21.2
ocm-transport-plugin	default        	2       	2024-04-04 16:42:03.080885 -0400 EDT   	deployed	ocm-transport-plugin-0.1.3     	0.1.3
postgres            	kubeflex-system	1       	2024-04-04 16:23:47.848258 -0400 EDT   	deployed	postgresql-13.1.5              	16.0.0
vcluster            	imbs1-system   	1       	2024-04-04 20:26:20.25819501 +0000 UTC 	deployed	vcluster-0.16.4                	0.16.4

I am surprised that the chart instance is going into the namespace named default.

If I understand correctly, @clubanderson was able to have two instances of this chart, one for each of two WDSes, by adding --namespace ${wds_name}-system to his helm commands. The chart itself qualifies every object's namespace/name with the WDS name, the only problem was the collision of the Helm "release" objects.

I wondered what would go wrong if https://github.com/kubestellar/ocm-transport-plugin/blob/main/chart/templates/controller.yaml#L20 were updated by replacing every occurrence of {{.Values.wds_cp_name}} with {{.Release.Namespace}}.
I found two potentially troubling uses of wds_cp_name:

https://github.com/kubestellar/ocm-transport-plugin/blob/7a69bcd1d7d8f9fb933a9bf4acaa94821b9144dc/chart/templates/controller.yaml#L116 and
https://github.com/kubestellar/ocm-transport-plugin/blob/7a69bcd1d7d8f9fb933a9bf4acaa94821b9144dc/chart/templates/controller.yaml#L138

It turns out that the transport controller uses the --wds-name only as a source of strings that distinguish controllers for different WDSes; these strings can be anything (that does not violate name length, character set, or syntax concerns) that varies from WDS to WDS, it does not actually have to be the WDS name.
The use in the call to the get-kubeconfig.sh script is more troubling. It actually needs to be the name of the WDS. This chart currently asserts that the relevant host cluster namespace for a given WDS is <WDS name>-system. If we can take that as fixed, then we can write a bit of template logic that extracts the WDS name from that namespace name.

@clubanderson can you please clarify if this was closed by my explanation of helm usage and the fix introduced to chart 0.1.3 by PR https://github.com/kubestellar/ocm-transport-plugin/pull/10

@clubanderson this step will not be needed anymore when I have a chance to update kubestellar PCH

@francostellari before 0.1.3, OTP would not install. Since 0.1.3, installation succeeds, but the issue here remains.

@clubanderson can we close this issue since #2038 is resolved ?

All set here I think

authors: MikeSpreitzer clubanderson francostellari nirrozenbaum pdettori

repo: kubestellar/kubestellar


text:
🌱 Add E2E test scenarios manipulating object label

Summary
This PR extends the ginkgo E2E test with a scenario that flaps the workload object label matched by the BindingPolicy, checking that the object is removed from and then restored to the WECs.
Related issue(s)
Fixes #

/cc @effi-ofer
/cc @pdettori
/cc @ezrasilvera
@cwiklik

/approve


text:
Set the storage mapping source title for OpenShift

Fixes: #691
Set the storage mapping source title, in case the source provider type is OpenShift, to 'Source storage classes'.
In addition, add 'storage classes' mapping for legacy empty state messages, for keeping code persistency.
Screenshot:

@yaacov @ahadas should we backport to v2.5 or wait with that for now?

should we backport to v2.5 or wait with that for now?

it's a small safe fix, i will backport it

I hope the current build that doesn't include this fix will be the last one for 2.5.0 but makes sense to backport in case we'll have another build and anyway, the branch for 2.5.1 will be created from release-v2.5.0

@yaacov done: https://github.com/kubev2v/forklift-console-plugin/pull/693

authors: ahadas sgratch yaacov