jiebi/CodeConvo huggingface dataset:
Change:
srcdir=$(dirname ${src}) srcthing=$(basename ${src}) mkdir -p ${GCS_STAGE}/${dst} <del> tar c -C ${srcdir} ${srcthing} | tar x -C ${GCS_STAGE}/${dst} </del> <ins> "${TAR}" c -C ${srcdir} ${srcthing} | "${TAR}" x -C ${GCS_STAGE}/${dst} </ins> done }

Discussion:
Since I've been having troubles with installation, I've digged a bit and found out that the permissions inside Kubernetes tarballs changed between 0.16.0 and 0.17.0. I've downloaded both tarballs, extracted them into separate directories and then extracted the Kubernetes server tarballs. This is what I get: I suppose, there has been a concious decision to restrict the world's access to those binaries. However, this breaks the installation routine mentioned above and probably makes life a bit more difficult in several other places. I'd be thankful for a correction if this wasn't intended or a pointer to the appropriate commit it this is legit -- I'd correct the installation.
assigning this to you to decide who the eventual assignee should be :)
Any news on this front? 0.20.1 is still restricted.
Apologies for the issue. It wasn't intentional -- likely an artifact of build scripts being run by different people? I'll check out 0.20.2 as I build it to make sure it has the right perms.
Apologies, but 0.20.2 didn't include fixed permissions. I now understand the issue, : "make release" builds a tarball using the permissions on files in your local git tree. I had "umask 027" set when I cloned, so those in-the-repo files had no world-readable perms. Setting "umask 022" before running "make release" is not enough -- it has to be part of creating the local tree when cloning. I'll update instructions and the next release (20.3 or 21.0) should fix this issue. And longer term, we need to put a bit more effort into releasing from a known-good environment and not rely on a developer's workstation's idiosyncrasies -- sorry this bit you.
I can't repro Trying again a different way, but I don't think the umask before clone should do anything (in particular, umasks aren't "sticky" on files, they're sticky to processes.)
And let's pretend on my personal fork isn't woefully out of date (who uses master on their personal fork? I should really just delete that that thing.) Comment updated.
Ah, I see the problem now.

works fine for the server tar, but the full tar also packages examples, etc., and for that, tar tends to just pick up the permissions of the git tree. Got it.
I'll take this. I'm going to write a script to build official bits, and this is easy enough to fix along the way.
Seems not fixed as of Kubernetes 1.0.7
sorry about that. is doing the 1.1.1 release and has been improving release scripts -- is 1.1.1 good re: permissions?
was not built by .
Reassigning to as release-oncall. Quinton, I can mentor or advise as necessary.
And yeah, is fine: There's no real bug here. There was a process issue that occurred with 1.0.7. We can rebuild the binaries if we need to.
FYI, leaving this issue closed, as per 's comment above. If anyone disagrees, please re-open this issue.
Change:
set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. <del> DEFAULT_OUTPUT_PATH="$PWD/${KUBE_ROOT}/docs/api-reference" </del> <ins> REPO_DIR=${REPO_DIR:-"${PWD}/${KUBE_ROOT}"} DEFAULT_OUTPUT_PATH="${REPO_DIR}/docs/api-reference" </ins> OUTPUT=${1:-${DEFAULT_OUTPUT_PATH}} echo "Generating api reference docs at ${OUTPUT}" V1_PATH="${OUTPUT}/v1/" V1BETA1_PATH="${OUTPUT}/extensions/v1beta1" <del> SWAGGER_PATH="$PWD/${KUBE_ROOT}/api/swagger-spec/" </del> <ins> SWAGGER_PATH="${REPO_DIR}/api/swagger-spec/" </ins> echo "Reading swagger spec from: ${SWAGGER_PATH}"

Discussion:
In the pull request Jenkins, we're running up to 8 instances of verification checks, build, unit tests, integration tests, and e2e tests. Unfortunately, it seems like several of these components were not designed to run simultaneous to other tests on the same machine. In particular, several unit tests seem to write to static file names in /tmp (or equivalent), which is a fairly easy fix. Some of the verification checks and the integration test start up etcd, however, and the etcd helper checks that only a single etcd binary is running on the host (and uses a static port for it). For example: We might be able to fix the etcd issue separately, or we can just figure out how to containerize all of these tests so they can't possibly interfere with each other. Note that we're ignoring the exit status of the verification checks and unit/integration tests right now, so these etcd failures are effectively being ignored (though it is causing us to miss test coverage).
What percentage of tests are failing due to being non-hermetic like this?
I'm not sure about unit tests (I've anecdotally seen just a few fail), but the verification checks are failing fairly regularly, and the integration test is also similarly frequently not running due to this.
To be clear, I'm looking for real numbers, to decide whether it's feasible to temporarily disable a small number of tests until we can hermetify them. Otherwise we need to turn off all unit, integration and verification tests in Jenkins to avoid irritating invalid regression signals. We need to do one or the other this week.
I'll try to dig through the logs, figure out which ones have failed recently, disable them in Jenkins, and see whether the flakes abate.
I just turned off all unit, integration and verification checks in Jenkins, as a temporary measure to unstall the merge-bot.
As a point of information, I just found approximately 20 tests in which use a static tmp path with semi-random filenames which are highly likely to collide. We could keep searching for unit tests that are non-hermetic, but it'd probably be a better investment of time to fix the test infrastructure so test authors don't need to care (and so we don't need to go look at and fix ~2000 test cases).

Another few metrics, using the string "/tmp" as a likely anti-pattern: We'd need to update each of these 23 files to get them to use or if they aren't already.
Created to track cleaning up tempdir usage in unit tests.
cc
Change:
// already effectively nil, no change needed case mungedPodSpec.Affinity == nil && oldNodeAffinity != nil: mungedPodSpec.Affinity = &core.Affinity{NodeAffinity: oldNodeAffinity} // +k8s:verify-mutation:reason=clone <ins> case mungedPodSpec.Affinity != nil && oldPod.Spec.Affinity == nil && mungedPodSpec.Affinity.PodAntiAffinity == nil && mungedPodSpec.Affinity.PodAffinity == nil: // We ensure no other fields are being changed, but the NodeAffinity. If that's the case, and the // old pod's affinity is nil, we set the mungedPodSpec's affinity to nil. mungedPodSpec.Affinity = nil // +k8s:verify-mutation:reason=clone </ins> default: <ins> // The node affinity is being updated and the old pod Affinity is not nil. // We set the mungedPodSpec's node affinity to the old pod's node affinity. </ins> mungedPodSpec.Affinity.NodeAffinity = oldNodeAffinity // +k8s:verify-mutation:reason=clone } }

Discussion:
When a gated pod is created with nil affinity and a user/controller tries to update its nodeAffinity, the validation fails. The pod gets updated with the new affinity as per rules in a pod as in the following using : to update the pod as with: No response <details</details<detailsTested on kind and OpenShift </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling
Change:
Except: 192.168.3.0/24, 192.168.4.0/24 ---------- To Port: <any> (traffic allowed to all ports) <del> To: <any> (traffic not restricted by source) </del> <ins> To: <any> (traffic not restricted by destination) </ins> Policy Types: Ingress, Egress `

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: A NetworkPolicy to allow egress to all Pods should use the term "destination" instead of "source" while example: What you expected to happen: should instead be kubectl describe networkpolicy net-document Name: net-document Namespace: default Created on: 2020-07-15 18:16:46 -0700 PDT Labels: <noneAnnotations: {"apiVersion":"","kind":"NetworkPolicy","metadata":{"annotations":{},"name":"net-document","namespace":"default"},"spe... Spec: PodSelector: app=test-document Allowing ingress traffic: To Port: <any(traffic allowed to all ports) From: <any(traffic not restricted by source) Allowing egress traffic: To Port: 80/TCP To: <any(traffic not restricted by destination) Policy Types: Egress, Ingress `` How to reproduce it (as minimally and precisely as possible): Create a allow-all egress NetworkPolicy and do
/sig network
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig sig-network Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/sig cli As this is something specific from kubectl :)
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cli Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/remove-triage unresolved
Change:
} } <del> func getHostFieldLabel(apiVersion string) string { switch apiVersion { case "v1beta1", "v1beta2": return "DesiredState.Host" default: return "spec.host" } } </del> // nodeEnumerator allows a cache.Poller to enumerate items in an api.NodeList type nodeEnumerator struct { *api.NodeList

Discussion:
My broke it for v1beta3, then fixed it for v1beta3 and broke it for v1beta1. I'm working on a fix.
Honestly I'm very surprised that more people aren't complaining-- integration test logs are full of noise because of this.
Exact text of error log is "Failed to watch *api.Node: field label not supported: "
cc
Change:
RunRC(c, name, ns, "gcr.io/google_containers/pause:go", n) podsLaunched += n glog.Info("Launched %v pods so far...", podsLaunched) <ins> err := DeleteRC(c, ns, name) expectNoError(err) </ins> } }() }

Discussion:
Currently the density tests are ok if all the pods come up eventually. We should verify there are no failure/error events while the pods are coming up. This could indicate issues dealing with the number of pods and should be investigated.
has been merged, and there's already an issue filed for followup actions, so I think we can close this.
Change:
mv "${temp_file}" /etc/kubernetes/manifests } <ins> function start-etcd-empty-dir-cleanup-pod { cp "${KUBE_HOME}/kube-manifests/kubernetes/gci-trusty/etcd-empty-dir-cleanup/etcd-empty-dir-cleanup.yaml" "/etc/kubernetes/manifests" } </ins> # Starts etcd server pod (and etcd-events pod if needed). # More specifically, it prepares dirs and files, sets the variable value # in the manifests, and copies them to /etc/kubernetes/manifests.

Discussion:
I came upon a cluster that had had the namespace code thoroughly exercised. No namespaces currently existed, but many had been created and deleted in the past. Its etcd had lots of empty directories under each resource that had held items when those namespaces were alive (secrets, serviceaccounts, pods...). Do we need to be doing something to clean these empty directories up? It seems like this etcd was consuming a lot of memory.
or might know the answer to this question.
Right. We should delete them. It might get tricky for concurrent cases like A checks if dir is empty, B creates, then A deletes it. What does it look like currently in creating and deleting namespace?
How much memory does a directory entry take? Does it really sound possible to run out of memory while snapshotting on account of too many empty directories?
-- have you guys encountered this? I think you run with more namespaces than we do. But maybe yours are mostly populated?
Yes, we've seen it. c.f.
Approximate memory use we saw from empty dirs:
cc
The patch we debated carrying is here: Our hope was to just wait to etcd v3 where this would not be a problem.
can you link to your clean-up script here?
I needed another PR to run the pod automatically on master.
Change:
By("deleting host1ROPod") framework.ExpectNoError(podClient.Delete(host1ROPod.Name, api.NewDeleteOptions(0)), "Failed to delete host1ROPod") <ins> By("Test completed successfully, waiting for PD to safely detach") waitForPDDetach(diskName, host0Name) waitForPDDetach(diskName, host1Name) </ins> }) It("Should schedule a pod w/ a readonly PD on two hosts, then remove both gracefully. [Slow]", func() {

Discussion:
PD E2E tests have very aggressive clean up routine that does not wait for volumes to safely detached. After the test completes, the test cleanup routine unilaterally detaches the PD (instead of waiting for k8s to do it cleanly). Although this does not cause the test to fail, it results in errors in the kernel logs: We should modify these tests to wait for k8s to safely detach the disk.
Change:
ginkgo.It("should reject a pod with an AppArmor profile", func(ctx context.Context) { status := runAppArmorTest(ctx, f, false, v1.DeprecatedAppArmorBetaProfileRuntimeDefault) <del> expectSoftRejection(status) </del> <ins> expectRejection(status) </ins> }) }) }

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Failures look like started when landed
Change:
# See the OWNERS docs at https://go.k8s.io/owners approvers: <del> - bowei - k82cn </del> <ins> - sig-node-approvers </ins> reviewers: <del> - smarterclayton - ingvagabund - k82cn </del> <ins> - sig-node-reviewers </ins> emeritus_approvers: <ins> - bowei - k82cn </ins> - gmarek <ins> labels: - sig/node </ins>

Discussion:
/kind cleanup /kind documentation /sig scheduling /sig node /sig apps The ownership of controller/nodelifecycle is unclear. The currently has some individual names and no labels, although it gets a sig/apps label from the parent pkg/controller OWNERS. This controller has the following functionality: Add taints based on health of the node (from conditions) Evict Pods based on NoExecute taints. The candidates for long term ownership are: : The ones who introduced it and overall maintain taints and tolerations. : Because it's called "node lifecycle", although this could be a misnomer. : Due to implications to the lifecycle of applications and because they are the main shepherds of kcm. I think it makes the most sense under scheduling, but wanted to gather all stakeholder's feedback.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
cc
cc as original author
I think both scheduling and node can own it, if node is too overwhelmed, sig scheduling makes sense as a home.
Thanks, It would be nice to sort out the ownership. It sounds reasonable for sig-scheduling to own it. /cc
Outcome from SIG Scheduling meeting: As already identified, this controller actually has 2 functionalities. From a technical standpoint, the following ownership makes sense to SIG Scheduling leads: Setting taints based on Node conditions -SIG Node Evicting pods that don't tolerate NoExecute taints -SIG Scheduling This ownership structure can be set-up even before is implemented, as the taint functionality has its own folder. I'll create a PR based on the above. But and please raise any concerns.
+1 on this proposal.
+1 on the proposal - I believe if we were to assign responsibility to who owns node level invariants that apply to workloads, it would be sig-node (they generally own node + pod). pod-safety, for instance, I considered owned by sig-node even though it touches storage, apps, api-machinery, and scheduling because the node owns the pod at the time safety is imposed.
Change:
} func (cd *cinderVolume) GetPath() string { <del> name := cinderVolumePluginName return cd.plugin.host.GetPodVolumeDir(cd.podUID, kstrings.EscapeQualifiedNameForDisk(name), cd.volName) </del> <ins> return getPath(cd.podUID, cd.volName, cd.plugin.host) </ins> } type cinderVolumeUnmounter struct {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug What happened: I am trying to get metrics working. According this there should be support after 1.8 kube. However, I am now using kube 1.10.1 and still I cannot see anything in ? Should these be there or not? What you expected to happen: I except that kubelet should expose prometheus metrics to /metrics path as well. Then it is easy to read with prometheus. How to reproduce it (as minimally and precisely as possible): Create new cinder volume, attach it to pod and try to query result from in kubelet Environment: Kubernetes version (use ): 1.10.1 Cloud provider or hardware configuration: openstack OS (e.g. from /etc/os-release): centos 7 Kernel (e.g. ): Install tools: Others:
cc
/sig storage
Prometheus metrics should be available on default port of Kubelet. Can you try ? If you are on a RBAC enabled cluster (such as openshift) you may have to use token or key to authenticate for fetching metrics.
returns many metrics but there is not things. There is one pod which have cinder volume attached running in that node. So there should be some metrics right?
It appears that Cinder volume plugin does not implement metric interface necessary for getting those stat metrics - This seems like an oversight and is fairly easy to fix. I can help getting the PR merged if you can open it.
/sig openstack
Kubernetes v1.19.16 there is no kubelet_volume* metrics in //metrics how to fix it???
Change:
<ins> /* Copyright 2023 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package main import ( "fmt" "runtime" "go.uber.org/automaxprocs/maxprocs" ) func main() { maxprocs.Set() fmt.Print(runtime.GOMAXPROCS(0)) } </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : should detect the appropriate GOMAXPROCS based off of the cpu limit supplied to the pod. Why is this needed: If not, test failures can occur (e.g. ) where GOMAXPROCS defaults to the number of cpus on the machine, while the cpu limit is actually far less. Too many compile/test processes launch, and any timing tests can become flaky. The end result is that running the test jobs on a node with more CPUs can make it flaky when running the test on a node with fewer CPUs cleanly passes. It's possible to set GOMAXPROCS=cpu limits in test jobs to avoid this, but it would be nicer if would autodiscover and set GOMAXPROCS appropriately.
/sig testing /sig k8s-infra
/transfer kubernetes
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign dims
xref:
This is already done, which is great, but for some more info I did some benchmarking of setting GOMAXPROCs vs not: Pretty substantially better in some cases
Change:
go nc.podController.Run(wait.NeverStop) go nc.daemonSetController.Run(wait.NeverStop) if nc.internalPodInformer != nil { <del> nc.internalPodInformer.Run(wait.NeverStop) </del> <ins> go nc.internalPodInformer.Run(wait.NeverStop) </ins> } // Incorporate the results of node status pushed from kubelet to master.

Discussion:
While following this to setup a kube-mesos integration env on my laptop, I found the default service account and default token are not created when start the cluster. As a result, I can not create a pod or deployment in this environment. Reproduce steps: the latest Mesos code, build and start 1 single master with 1 single agent. the latest Kubernetes code, use to build. the following commands to start apiserver, controller-manager and scheduler respectively: all the components are started, run command and see that there is no default token created for the default namespace. At this moment, run "kubectl create -f " will see the failure of creating a pod.
This introduced to node controller and now when we start a node controller, if is not nil, we will start this Informer controller as well. But the start of the will block main thread from starting other controllers later in the main thread. we can see that in the kube-mesos integration, we started some other controllers, including serviceaccount controller, after we started node controller. I will submit a patch later to run the in a go routine to solve the issue.
Change:
"encoding/json" "fmt" "io/ioutil" <ins> "reflect" </ins> "strings" "testing"

Discussion:
This tree has a commit that demonstrates two obviously different objects that should not pass the semantic DeepEqual but do.
What shall we do with this issue for triage? Labels? Priority?
P2 for when he returns , Satnam Singh wrote:
OK I am now sufficiently worried about this. Fixes incoming.
Change:
import ( "context" <del> "errors" </del> "fmt" <del> "io" "net" </del> "time" "google.golang.org/grpc" grpccodes "google.golang.org/grpc/codes" <del> "google.golang.org/grpc/credentials/insecure" </del> grpcstatus "google.golang.org/grpc/status" "k8s.io/klog/v2"

Discussion:
See comment for details:
/sig node
/area kubelet
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
/triage accepted