jiebi/CodeConvo huggingface dataset:
Change:
This started after was merged. The HPA test started being very flaky since then: https://k8s- The HPA test in containerd e2e become even more flaky since then with the same failure pattern: https://k8s-
I think this is probably /priority critical-urgent Release team hasn't looked close enough at this issue as we've been trying to clear other issues in front of it. If we crack those and this is unrelated root cause, then this one's going to be a release blocker.
It's going to be supremely hard to debug this unless we have logs from metrics-server and/or snapshots of the HPA over time. I'm trying to reproduce on a local cluster, but so far, the test passes consistently. did you manage to reproduce locally?
is there any way to grab logs of pods from a testing cluster?
you probably want to save it as part of the artifacts?
yeah, what's the process for that?
somewhere along
See for an attempt at debugging this.
can we provide the data is looking for? we're seeing this quite often.
ack, more logs would be helpful. Currently trying to get usable logs off the CI with the aforementioned PR, but I keep making minor mistakes in the log collection script :-/. It seems to repro every few runs though, so with any luck I'll see it again soon.
Got a WIP fix up: Need to do one more tweak before merge.
Re-running tests with the above PR, if they succeed I'll merge and get someone to do a build when the people capable of running builds are on next.
status check? I'm worried this is a 1.12 blocker and need to make a call by end of day today regarding delaying the release.
According to our testing, metrics-server 0.3.1 seems to have fixed it - thank you

Discussion:
apiVersion: extensions/v1beta1 kind: Deployment metadata: <del> name: metrics-server-v0.3.0 </del> <ins> name: metrics-server-v0.3.1 </ins> namespace: kube-system labels: k8s-app: metrics-server kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile <del> version: v0.3.0 </del> <ins> version: v0.3.1 </ins> spec: selector: matchLabels: k8s-app: metrics-server <del> version: v0.3.0 </del> <ins> version: v0.3.1 </ins> template: metadata: name: metrics-server labels: k8s-app: metrics-server <del> version: v0.3.0 </del> <ins> version: v0.3.1 </ins> annotations: scheduler.alpha.kubernetes.io/critical-pod: '' seccomp.security.alpha.kubernetes.io/pod: 'docker/default'

serviceAccountName: metrics-server containers: - name: metrics-server <del> image: k8s.gcr.io/metrics-server-amd64:v0.3.0 </del> <ins> image: k8s.gcr.io/metrics-server-amd64:v0.3.1 </ins> command: - /metrics-server - --metric-resolution=30s

- --memory={{ base_metrics_server_memory }} - --extra-memory={{ metrics_server_memory_per_node }}Mi - --threshold=5 <del> - --deployment=metrics-server-v0.3.0 </del> <ins> - --deployment=metrics-server-v0.3.1 </ins> - --container=metrics-server - --poll-period=300000 - --estimator=exponential
Change:
Is this a BUG REPORT or FEATURE REQUEST?: kind bug What happened: After execute kubeadm init during kube-proxy pod initialization there is CrashLoopBackOff error all the time Logs from pod: [centos ~]$ kubectl logs kube-proxy-8gs45 -n kube-system What you expected to happen: kube-proxy pod run properly How to reproduce it (as minimally and precisely as possible): follow instruction: try to execute: Environment: Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools:Others:
/sig network
I have exactly the same problem with the 1.12.0-beta.1. Does kube-proxy really need access to /proc/sys/* in this case?
Same problem with Ubuntu
Does that mean kube-proxy can only be run outside of container?
/sig cluster-lifecycle
/milestone v1.12
Looks like docker inspect shows masked and read-only paths (looking at ) even when the pod is
It being close to release, since this is not urgent, please save this for 1.13! /milestone clear /milestone v1.13
/milestone v1.13
/priority critical-urgent /milestone v1.12 Sorry the activity and urgency is reflected in the PR :)
welp! sorry about that!
I'm still seeing this on RC1, did this land before the release was cut? /cc
update from :
I just verified on release-1.12 branch and it's good.

Discussion:
hostConfig.SecurityOpt = append(hostConfig.SecurityOpt, "no-new-privileges") } <del> hostConfig.MaskedPaths = sc.MaskedPaths hostConfig.ReadonlyPaths = sc.ReadonlyPaths </del> <ins> if !hostConfig.Privileged { hostConfig.MaskedPaths = sc.MaskedPaths hostConfig.ReadonlyPaths = sc.ReadonlyPaths } </ins> return nil }

func TestModifyHostConfig(t *testing.T) { setNetworkHC := &dockercontainer.HostConfig{} <ins> // When we have Privileged pods, we do not need to use the // Masked / Readonly paths. </ins> setPrivSC := &runtimeapi.LinuxContainerSecurityContext{} setPrivSC.Privileged = true <ins> setPrivSC.MaskedPaths = []string{"/hello/world/masked"} setPrivSC.ReadonlyPaths = []string{"/hello/world/readonly"} </ins> setPrivHC := &dockercontainer.HostConfig{ Privileged: true, } <ins> unsetPrivSC := &runtimeapi.LinuxContainerSecurityContext{} unsetPrivSC.Privileged = false unsetPrivSC.MaskedPaths = []string{"/hello/world/masked"} unsetPrivSC.ReadonlyPaths = []string{"/hello/world/readonly"} unsetPrivHC := &dockercontainer.HostConfig{ Privileged:    false, MaskedPaths:   []string{"/hello/world/masked"}, ReadonlyPaths: []string{"/hello/world/readonly"}, } </ins> setCapsHC := &dockercontainer.HostConfig{ CapAdd:  []string{"addCapA", "addCapB"}, CapDrop: []string{"dropCapA", "dropCapB"},

expected: setPrivHC, }, { <ins> name:     "container.SecurityContext.NoPrivileges", sc:       unsetPrivSC, expected: unsetPrivHC, }, { </ins> name: "container.SecurityContext.Capabilities", sc: &runtimeapi.LinuxContainerSecurityContext{ Capabilities: inputCapabilities(),
Change:
What happened: When a dry run request is made to a modifying endpoint, and the dry-run alpha feature is disabled, it returns the error message "dryRun is not supported yet" This was true in 1.11, but in 1.12, since the feature is in alpha now, the message should say something like "the dryRun alpha feature is disabled" /kind bug /sig api-machinery

Discussion:
func DeleteCollection(r rest.CollectionDeleter, checkBody bool, scope RequestScope, admit admission.Interface) http.HandlerFunc { return func(w http.ResponseWriter, req *http.Request) { if isDryRun(req.URL) && !utilfeature.DefaultFeatureGate.Enabled(features.DryRun) { <del> scope.err(errors.NewBadRequest("dryRun is not supported yet"), w, req) </del> <ins> scope.err(errors.NewBadRequest("the dryRun alpha feature is disabled"), w, req) </ins> return }

defer trace.LogIfLong(500 * time.Millisecond) if isDryRun(req.URL) && !utilfeature.DefaultFeatureGate.Enabled(features.DryRun) { <del> scope.err(errors.NewBadRequest("dryRun is not supported yet"), w, req) </del> <ins> scope.err(errors.NewBadRequest("the dryRun alpha feature is disabled"), w, req) </ins> return }
Change:
They should be consistent with all other commands that allow multiple arguments (since they already allow label selectors). should cordon all of them, not return an error.
Hi , can I take this if no one has been working on it?
Please also refer . These two and should take multiple arguments as it is very common to get subset of nodes in this way . So it would be very nice if these would work:

Discussion:
if len(args) > 0 && len(o.Selector) > 0 { return cmdutil.UsageErrorf(cmd, "error: cannot specify both a node name and a --selector option") } <del> if len(args) > 0 && len(args) != 1 { return cmdutil.UsageErrorf(cmd, fmt.Sprintf("USAGE: %s [flags]", cmd.Use)) } </del> o.DryRun = cmdutil.GetDryRunFlag(cmd)

arg:         "bar", expectFatal: true, }, <ins> { description: "cordon for multiple nodes", node:        node, expected:    cordoned_node, cmd:         NewCmdCordon, arg:         "node node1 node2", expectFatal: false, }, { description: "uncordon for multiple nodes", node:        cordoned_node, expected:    node, cmd:         NewCmdUncordon, arg:         "node node1 node2", expectFatal: false, }, </ins> } for _, test := range tests {

Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { m := &MyReq{req} switch { <ins> case m.isFor("GET", "/nodes/node1"): fallthrough case m.isFor("GET", "/nodes/node2"): fallthrough </ins> case m.isFor("GET", "/nodes/node"): return &http.Response{StatusCode: 200, Header: cmdtesting.DefaultHeader(), Body: cmdtesting.ObjBody(codec, test.node)}, nil case m.isFor("GET", "/nodes/bar"): return &http.Response{StatusCode: 404, Header: cmdtesting.DefaultHeader(), Body: cmdtesting.StringBody("nope")}, nil <ins> case m.isFor("PATCH", "/nodes/node1"): fallthrough case m.isFor("PATCH", "/nodes/node2"): fallthrough </ins> case m.isFor("PATCH", "/nodes/node"): data, err := ioutil.ReadAll(req.Body) if err != nil {

saw_fatal = true panic(e) }) <del> cmd.SetArgs([]string{test.arg}) </del> <ins> cmd.SetArgs(strings.Split(test.arg, " ")) </ins> cmd.Execute() }()
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: when the node lost connection with master , using 'kubectl describe node' find the NodePIDPressure is false , no switch to unknown. What you expected to happen: PIDPressure Unknown Fri, 14 Sep 2018 05:13:09 +0800 Fri, 14 Sep 2018 05:13:53 +0800 NodeStatusUnknown Kubelet stopped posting node status. How to reproduce it (as minimally and precisely as possible): stop kubelet, wait the node Notready check the node status 'kubectl describe node' Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig node

Discussion:
v1.NodeOutOfDisk, v1.NodeMemoryPressure, v1.NodeDiskPressure, <ins> v1.NodePIDPressure, </ins> // We don't change 'NodeNetworkUnavailable' condition, as it's managed on a control plane level. // v1.NodeNetworkUnavailable, }

LastHeartbeatTime:  metav1.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), LastTransitionTime: fakeNow, }, <ins> { Type:               v1.NodePIDPressure, Status:             v1.ConditionUnknown, Reason:             "NodeStatusNeverUpdated", Message:            "Kubelet never posted node status.", LastHeartbeatTime:  metav1.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), LastTransitionTime: fakeNow, }, </ins> }, }, },

LastHeartbeatTime:  metav1.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), // should default to node creation time if condition was never updated LastTransitionTime: metav1.Time{Time: metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC).Add(time.Hour)}, }, <ins> { Type:               v1.NodePIDPressure, Status:             v1.ConditionUnknown, Reason:             "NodeStatusNeverUpdated", Message:            "Kubelet never posted node status.", LastHeartbeatTime:  metav1.Date(2012, 1, 1, 0, 0, 0, 0, time.UTC), // should default to node creation time if condition was never updated LastTransitionTime: metav1.Time{Time: metav1.Date(2015, 1, 1, 12, 0, 0, 0, time.UTC).Add(time.Hour)}, }, </ins> }, Capacity: v1.ResourceList{ v1.ResourceName(v1.ResourceCPU):    resource.MustParse("10"),
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: https://k8s- https://k8s-
/assign /priority critical-urgent /kind failing-test cc
/cc this is the symptom you said had an internal fix coming by end of week (ie: today)?
No this is purely oss
cc

Discussion:
import ( "fmt" <ins> "time" </ins> . "github.com/onsi/ginkgo" . "github.com/onsi/gomega"

volType := pattern.VolType if r.pvc != nil || r.pv != nil { <del> By("Deleting pv and pvc") if errs := framework.PVPVCCleanup(f.ClientSet, f.Namespace.Name, r.pv, r.pvc); len(errs) != 0 { framework.Failf("Failed to delete PVC or PV: %v", utilerrors.NewAggregate(errs)) </del> <ins> switch volType { case testpatterns.PreprovisionedPV: By("Deleting pv and pvc") if errs := framework.PVPVCCleanup(f.ClientSet, f.Namespace.Name, r.pv, r.pvc); len(errs) != 0 { framework.Failf("Failed to delete PVC or PV: %v", utilerrors.NewAggregate(errs)) } case testpatterns.DynamicPV: By("Deleting pvc") // We only delete the PVC so that PV (and disk) can be cleaned up by dynamic provisioner if r.pv.Spec.PersistentVolumeReclaimPolicy != v1.PersistentVolumeReclaimDelete { framework.Failf("Test framework does not currently support Dynamically Provisioned Persistent Volume %v specified with reclaim policy that isnt %v", r.pv.Name, v1.PersistentVolumeReclaimDelete) } err := framework.DeletePersistentVolumeClaim(f.ClientSet, r.pvc.Name, f.Namespace.Name) framework.ExpectNoError(err, "Failed to delete PVC %v", r.pvc.Name) err = framework.WaitForPersistentVolumeDeleted(f.ClientSet, r.pv.Name, 5*time.Second, 5*time.Minute) framework.ExpectNoError(err, "Persistent Volume %v not deleted by dynamic provisioner", r.pv.Name) default: framework.Failf("Found PVC (%v) or PV (%v) but not running Preprovisioned or Dynamic test pattern", r.pvc, r.pv) </ins> } }
Change:
This is related to and , but these issues contain several different bugs, so I am creating a new one. Steps to reproduce: must be a symlink somewhere else. If you don't have a symlink, then it's a different bug. a pod with ConfigMap volume with SubPath: (the pod should run just fine) -The pod is Terminating forever From the logs: You can see there is no "Unmounting /var/lib/kubelet/pods/-ba83-11e8-983c-/volume-subpaths/vol/busybox/0", so kubelet did not even try to unmount it. Environment: Kubernetes version 1.9.x (and today's master). /kind bug /sig storage another subpath bug :-)
Posted , kubelet gets confused by /var/lib/kubelet being a symlinks and it looks for /var/lib/kubelet/pods/... in /proc/mounts instead of target of the symlink.

Discussion:
// It is more extensive than IsLikelyNotMountPoint // and it detects bind mounts in linux func IsNotMountPoint(mounter Interface, file string) (bool, error) { <ins> // Resolve any symlinks in file, kernel would do the same and use the resolved path in /proc/mounts resolvedFile, err := mounter.EvalHostSymlinks(file) if err != nil { return true, err } </ins> // IsLikelyNotMountPoint provides a quick check // to determine whether file IS A mountpoint <del> notMnt, notMntErr := mounter.IsLikelyNotMountPoint(file) </del> <ins> notMnt, notMntErr := mounter.IsLikelyNotMountPoint(resolvedFile) </ins> if notMntErr != nil && os.IsPermission(notMntErr) { // We were not allowed to do the simple stat() check, e.g. on NFS with // root_squash. Fall back to /proc/mounts check below.

return notMnt, mountPointsErr } for _, mp := range mountPoints { <del> if mounter.IsMountPointMatch(mp, file) { </del> <ins> if mounter.IsMountPointMatch(mp, resolvedFile) { </ins> notMnt = false break }
Change:
The current node e2e tests include images using Docker 1.11.x to , with the pending PR to test 18.06 () We should update the images to drop older docker versions. I think we can start by getting rid of 1.11 and 1.12, so that we still have three minor versions tested: , , and 1.13.x /cc (for cos and ubuntu)
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/assign Yang, could you take a look? Thanks

Discussion:
FakeMemoryCapacity     = 4026531840 FakeKernelVersion      = "3.16.0-0.bpo.4-amd64" FakeContainerOsVersion = "Debian GNU/Linux 7 (wheezy)" <del> FakeDockerVersion      = "1.5.0" </del> <ins> FakeDockerVersion      = "1.13.1" </ins> ) var _ cadvisor.Interface = new(Fake)

const ( // https://docs.docker.com/engine/reference/api/docker_remote_api/ <del> // docker version should be at least 1.11.x MinimumDockerAPIVersion = "1.23.0" </del> <ins> // docker version should be at least 1.13.1 MinimumDockerAPIVersion = "1.26.0" </ins> // Status of a container returned by ListContainers. StatusRunningPrefix = "Up"

const ( // Notice that if someday we also have minimum docker version requirement, this should also be updated. <del> fakeDockerVersion = "1.11.2" </del> <ins> fakeDockerVersion = "1.13.1" </ins> fakeImageSize = 1024
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: since we use to run our end to end tests despite nominally being a unit test framework, all tests are "slow test" in the log output due to being greater than the current threshold (default appears to be 5 seconds). What you expected to happen: We should set the threshold to something we consider to be reasonable for an end to end test. What that is might need some thought. /sig testing brought up by
ginkgo does have a we could try setting this in a job and see how it works out before we try to recommend one more generally. WDYT?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-lifecycle stale /help 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
This could be as simple as editing:
I can make the change..

Discussion:
--cluster-monitoring-mode="${KUBE_ENABLE_CLUSTER_MONITORING:-standalone}"  --prometheus-monitoring="${KUBE_ENABLE_PROMETHEUS_MONITORING:-false}"  --dns-domain="${KUBE_DNS_DOMAIN:-cluster.local}"  <ins> --ginkgo.slowSpecThreshold="${GINKGO_SLOW_SPEC_THRESHOLD:-300}"  </ins> ${KUBE_CONTAINER_RUNTIME:+"--container-runtime=${KUBE_CONTAINER_RUNTIME}"}  ${MASTER_OS_DISTRIBUTION:+"--master-os-distro=${MASTER_OS_DISTRIBUTION}"}  ${NODE_OS_DISTRIBUTION:+"--node-os-distro=${NODE_OS_DISTRIBUTION}"}
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The log from kubelet service: 07:41:58. 4036 ] Configure resource-only container "" with memory limit: 0 Environment: Kubernetes version (use ):v1.10.1 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig kubelet cc
/sig node /area kubelet

Discussion:
func createCgroupManager(name string) (*fs.Manager, error) { var memoryLimit uint64 memoryCapacity, err := getMemoryCapacity() <del> if err != nil || memoryCapacity*dockerMemoryLimitThresholdPercent/100 < minDockerMemoryLimit { </del> <ins> if err != nil { glog.Errorf("Failed to get the memory capacity on machine: %v", err) } else { memoryLimit = memoryCapacity * dockerMemoryLimitThresholdPercent / 100 } if err != nil || memoryLimit < minDockerMemoryLimit { </ins> memoryLimit = minDockerMemoryLimit } glog.V(2).Infof("Configure resource-only container %q with memory limit: %d", name, memoryLimit)
Change:
I propose we add guidance on how to run tests for a PR in the PR template. I am a new contributor and took me much (much!) looking around to find testing instructions. It seems that page contains everything one needs to know about testing. I think it is very fitting to have it included in the template, as a one of the last check items. I propose the template be changed from this: this: /kind documentation
/sig docs
I agree with you.
/sig contributor-experience cc:

Discussion:
1. If this is your first time, read our contributor guidelines https://git.k8s.io/community/contributors/guide#your-first-contribution and developer guide https://git.k8s.io/community/contributors/devel/development.md#development-guide 2. Please label this pull request according to what type of issue you are addressing, especially if this is a release targeted pull request. For reference on required PR/issue labels, read here: https://git.k8s.io/community/contributors/devel/release.md#issue-kind-label <del> 3. If you want *faster* PR reviews, read how: https://git.k8s.io/community/contributors/guide/pull-requests.md#best-practices-for-faster-reviews 4. Follow the instructions for writing a release note: https://git.k8s.io/community/contributors/guide/release-notes.md 5. If the PR is unfinished, see how to mark it: https://git.k8s.io/community/contributors/guide/pull-requests.md#marking-unfinished-pull-requests </del> <ins> 3. Ensure you have added or ran the appropriate tests for your PR: https://git.k8s.io/community/contributors/devel/testing.md 4. If you want *faster* PR reviews, read how: https://git.k8s.io/community/contributors/guide/pull-requests.md#best-practices-for-faster-reviews 5. Follow the instructions for writing a release note: https://git.k8s.io/community/contributors/guide/release-notes.md 6. If the PR is unfinished, see how to mark it: https://git.k8s.io/community/contributors/guide/pull-requests.md#marking-unfinished-pull-requests </ins> --> **What type of PR is this?**
Change:
When the kubelet first starts the folllowing error is emitted to the logs This is because the relist has not yet run which results in a duration that is just the time since the zero time instant () xref /sig node
/assign
/approve /lgtm
help if i approve the pr and not the issue ;-)

Discussion:
func (g *GenericPLEG) Healthy() (bool, error) { relistTime := g.getRelistTime() <ins> if relistTime.IsZero() { return false, fmt.Errorf("pleg has yet to be successful") } </ins> elapsed := g.clock.Since(relistTime) if elapsed > relistThreshold { return false, fmt.Errorf("pleg was last seen active %v ago; threshold is %v", elapsed, relistThreshold)

func TestHealthy(t *testing.T) { testPleg := newTestGenericPLEG() <ins> // pleg should initially be unhealthy </ins> pleg, _, clock := testPleg.pleg, testPleg.runtime, testPleg.clock ok, _ := pleg.Healthy() <del> assert.True(t, ok, "pleg should be healthy") </del> <ins> assert.False(t, ok, "pleg should be unhealthy") </ins> // Advance the clock without any relisting. clock.Step(time.Minute * 10)

clock.Step(time.Minute * 1) ok, _ = pleg.Healthy() assert.True(t, ok, "pleg should be healthy") <ins> // Advance by relistThreshold without any relisting. pleg should be unhealthy // because it has been longer than relistThreshold since a relist occurred. clock.Step(relistThreshold) ok, _ = pleg.Healthy() assert.False(t, ok, "pleg should be unhealthy") </ins> } func TestRelistWithReinspection(t *testing.T) {