jiebi/CodeConvo huggingface dataset:
Change:
// by kubelet-flags. "--feature-gates", framework.TestContext.FeatureGates, "--eviction-hard", "memory.available<250Mi,nodefs.available<10%,nodefs.inodesFree<5%", // The hard eviction thresholds. <ins> "--eviction-minimum-reclaim", "nodefs.available=5%,nodefs.inodesFree=5%", // The minimum reclaimed resources after eviction. </ins> "--v", LOG_VERBOSITY_LEVEL, "--logtostderr", ) // Enable kubenet by default.

Discussion:
Clusters on GCE set eviction thresholds for disk and inodes. Given that reclaiming disk and inodes is slow, we should set minimum reclaim thresholds too. Essentially, set . I assume percentages are supported for min reclaims too. Do we have system tests for min reclaim? cc
I just took a glance at the parser for eviction minimum reclaim, it doesn't look like it tries to parse percentages. can you confirm?
did percentage support, and we did not extend it to min reclaim. It's a good idea to do though. On Tuesday, September 13, 2016, Michael Taufen wrote:
Hmm.. In that case for v1.4, can we set the min reclaim to ? What values are you planning on using in Open Shift ?
This should fix this issue to avoid node condition being flip-flop, but I think it shouldn't block 1.4 release.
More than flip-flop, it will help the node recover from disk pressure condition sooner. , Dawn Chen wrote:
/cc
Spawned to add percentage support for min reclaim. I will follow up with our proposed default for nodefs later
This needs to be triaged as a release-blocker or not for 1.5
can you check if we have set default values for disk and inode based evictions in kubelet? If not, we should add them.
I believe our current default value for the --eviction-hard flag is "memory.available<100Mi", found in Our tests currently run using: "memory.available<250Mi,nodefs.available<10%,nodefs.inodesFree<5%", found in What should I change the default to? This issue is about minimum reclaim, should I look into changing those flags as well?
It doesn't appear that we have defaults for minimum reclaim, should I add minimum reclaim for memory in addition to disk and inodes?
I think GCE defaults do not apply globally, we should change what GCE does, and handle setting global defaults in 1.6.
the global defaults are expected to be based on our OSS tests. Our original plan was to roll out disk eviction by default in v1.5. This is not specific to GCE.
Can you make a call on if this is a blocker or non-blocker for 1.5 by EOD Friday please
Change:
if kubeClient != nil { // TODO: cache.NewListWatchFromClient is limited as it takes a client implementation rather // than an interface. There is no way to construct a list+watcher using resource name. <del> fieldSelector := fields.Set{"metadata.name": hostname}.AsSelector() </del> <ins> fieldSelector := fields.Set{client.ObjectNameField: hostname}.AsSelector() </ins> listWatch := &cache.ListWatch{ ListFunc: func() (runtime.Object, error) { // TODO: Use List() with fieldSelector when it is supported.

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:
}, }, }, <del> Required: []string{"replicas", "availableReplicas"}, </del> <ins> Required: []string{"replicas"}, </ins> }, }, Dependencies: []string{

Discussion:
Looking at the for , it defines as a required attribute. But looking at the of , it states . Should this in fact be a required attribute? I come about this from using , a python package that generates models from the swagger definitions and thus builds a that requires an attribute that is not enabled. That only truly required attributes be required in the swagger definition Reproduction is not applicable as this is an issue with a spec No response Appeared in 1.22 (I believe) and affects current versions. Does not affect 1.21 n/a No response No response No response No response
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
alpha: has that is planned for removal in beta. ( results in fields as non-required in the OpenAPI) beta: removes the this might be a question whether feature gate controlled fields must remain until the feature gate is removed (and how would validation work in that case). ~old feature gates graduations to beta enabled a feature by default.~ a topic related to ? but it does not apply to feature gates. /kind documentation /sig apps
cc (since you are the author)
new fields to existing types must always be marked as +optional, since clients are not required to specify them
please open a PR adding back the +optional tag, regenerate openapi, and open picks back to 1.23 and 1.22
Change:
} <ins> type fakeQueue struct { workqueue.RateLimitingInterface t   time.Duration key interface{} } func (f *fakeQueue) AddAfter(key interface{}, t time.Duration) { f.t = t f.key = key } </ins> // this test will take around 61 seconds to complete func TestController2_updateCronJob(t *testing.T) { cjc := &fakeCJControl{} jc := &fakeJobControl{} type fields struct { <del> queue          workqueue.RateLimitingInterface </del> <ins> queue          *fakeQueue </ins> recorder       record.EventRecorder jobControl     jobControlInterface cronJobControl cjControlInterface

Discussion:
pull-kubernetes-unit TestController2updateCronJob/spec.schedulechanged TestController2_updateCronJob /sig apps /assign
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
This is important to resolve before promotion to v1
looks like the cause was
This function should be related.
Another one:
When the flake happen, there are messages like When the system is overloaded, it would happen. is trying to replace the current queue in tests with a mock.
Yeah, I spoke with to make sure we use a mock of the queue so we only get the most important bit of information ignoring the remaining parts
Change:
if err := addPriorityClasses(ctrl, test.classesAfter); err != nil { t.Errorf("Test %q: unable to add object to informer: %v", test.name, err) } <del> defaultPriority, err = ctrl.getDefaultPriority() </del> <ins> pcName, defaultPriority, err = ctrl.getDefaultPriority() </ins> if err != nil { t.Errorf("Test %q: unexpected error while getting default priority: %v", test.name, err) } <del> if err == nil && defaultPriority != test.expectedDefaultAfter { t.Errorf("Test %q: expected default priority %d, but got %d", test.name, test.expectedDefaultAfter, defaultPriority) </del> <ins> if err == nil && (defaultPriority != test.expectedDefaultAfter || pcName != test.expectedDefaultNameAfter) { t.Errorf("Test %q: expected default priority %s(%d), but got %s(%d)", test.name, test.expectedDefaultNameAfter, test.expectedDefaultAfter, pcName, defaultPriority) </ins> } } }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind cleanup /sig scheduling Description: If Pod did not set , admission controller will set to "default value". If the default value are from default priority class, it's better to also set of pod.
can I take this? /assign
, thanks :) I created a PR for functionality, but that'll be great if you can help add some e2e test for it. I can help to shepherd :)
thanks let me have a try :)
Change:
errCh := decorated2.Do(func() { defer close(executed) if !delegated { <del> t.Fatalf("expected delegated execution") </del> <ins> t.Errorf("expected delegated execution") </ins> } errOnce.Report(expectedErr) })

Discussion:
Can we get this fixed ASAP? Thanks!
yep, thanks for reporting , Brendan Burns wrote:
how reproduceable is this? I have some changes that I think will resolve it but I couldn't reproduce locally even when all my cpu's were pretty tied up and using a high GOMAXPROCS.
flakey label process?
the labelling is due to me failing @ github's label interface. Bulk editing labels removes them if any of the selected things have the label sigh Thanks for the quick fix.
Change:
"k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" <del> "k8s.io/kubernetes/pkg/apis/apps" </del> <ins> extensionsinternal "k8s.io/kubernetes/pkg/apis/extensions" </ins> "k8s.io/kubernetes/test/e2e/framework" imageutils "k8s.io/kubernetes/test/utils/image"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug We can see all related with test failed. and so on. I think it maybe relate with PR and . What happened: Always fails. What you expected to happen: Pass all.
/cc PTAL. Thanks.
Why did the not pass the test but was still merged?
/priority important-soon /kind e2e-test-failure
/area platform/gce
Looks like the fix is in
is not a blocking / required test (for merge) currently IIRC, kubernetes/kubernetes uses the "submit-queue" which will only pay attention to some tests.
i think this is true, as confirmed by the current state of this PR: it fails the test, but the CI says instead of is there are way to see which tests would cause a ?
off the top of my head the definitive way is this list: but note that is working on moving us to in the nearish future, and every other kubernetes repo besides this one is either not using merge automation or is using , which behaves differently and has seperate config integrated with the rest of test-infra.
thanks for the details! :+1:
Change:
"containers": [ { "name": "cluster-autoscaler", <del> "image": "gcr.io/google_containers/cluster-autoscaler:v0.5.0", </del> <ins> "image": "gcr.io/google_containers/cluster-autoscaler:v0.5.1", </ins> "command": [ "./run.sh", "--kubernetes=http://127.0.0.1:8080?inClusterConfig=f",

Discussion:
On some occasions Cluster Autoscaler may scale up the cluster two times. This results in growing the cluster too large. The size gets back to normal soon but the user will be forced to pay for the unneeded node for 10min/1h, depending on the cloud provider. cc:
Please provide more information.
Imagine that you have just created a pod that cannot be scheduled. CA expands one of the migs to accommodate it. Just when the node arrives there is a brief moment when the pod is still pending (scheduler didn't retry it yet) but the node is available. Scale up is over. Pod is pending. So we might try to scale up again, which would be incorrect. To protect against such situations we run a simulated scheduling on all nodes. If any node can accommodate any of the pending pods then the pod is not pending and should not trigger a scale up. After a scale up we create "virtual" nodes inside CA so that we don't scale up again for the same pods. Once the node arrives its virtual placeholder is deleted. And, if I'm correct, we have a bug here. A node with node condition ready=true but with non ready network is considered as fully started but broken. Its virtual placeholder is gone so we trigger scale up again. Seconds later the network arrives and the scale up appears to be non-needed. I'm testing right now a 10 line fix for this issue. After the fix is merged I would like to bump CA version in 1.6 as having the old code would impact all of the current CA users on GCE and GKE (and possibly on other cloud providers too).
is this a regression in cluster autoscaler for 1.6, or did the same behavior exist in 1.5?
It is a regression. Doesn't happen always (depends on the network setup timings) but when it does it is quite confusing.
Change:
allErrs = append(allErrs, apivalidation.ValidateObjectMeta(&obj.ObjectMeta, false, ValidateThirdPartyResourceName, field.NewPath("metadata"))...) versions := sets.String{} <ins> if len(obj.Versions) == 0 { allErrs = append(allErrs, field.Required(field.NewPath("versions"), "must specify at least one version")) } </ins> for ix := range obj.Versions { version := &obj.Versions[ix] if len(version.Name) == 0 {

Discussion:
FYI. Currently the field of TPR is marked as which is wrong, actually if you try to create a TPR with empty versions, it will cause api server panic. Versions should be necessary field of TPR, we should validate this somehow.
Change:
{ node: api.Node{ ObjectMeta: metav1.ObjectMeta{ <ins> Name:   "foo10", Labels: map[string]string{"node-role.kubernetes.io/master": "", "kubernetes.io/role": "node", "kubeadm.alpha.kubernetes.io/role": "node"}, }, }, status: "Unknown,Master", }, { node: api.Node{ ObjectMeta: metav1.ObjectMeta{ Name:   "foo11", Labels: map[string]string{"kubernetes.io/role": "node", "kubeadm.alpha.kubernetes.io/role": "node"}, }, }, status: "Unknown,Node", }, { node: api.Node{ ObjectMeta: metav1.ObjectMeta{ </ins> Name:   "foo12", Labels: map[string]string{"kubeadm.alpha.kubernetes.io/role": "node"}, }, Status: api.NodeStatus{Conditions: []api.NodeCondition{{Type: api.NodeReady, Status: api.ConditionTrue}}}, }, <del> status: "Ready,node", </del> <ins> status: "Ready,Node", </ins> }, }

Discussion:
/kind bug What happened: doesn't show role Workaround: What you expected to happen: According to and How to reproduce it (as minimally and precisely as possible): I just deployed a multi master kubernetes environment with kops: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS Install tools: kops, terraform
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig cli
I don't think this is a bug. The node role label is not used by kubeadm anymore. Related codes have been changed in by
Hi Thanks for the quick reply I'm actually using the as you can see in the workaround above. I'm not using kubeadm role label.
Your favorite topic came up again. Hi I do think this is a bug. As said, kubectl shouldn't show anything based on the old kubeadm master label, but it should probably on the label, but absolutely on the label. cc as you have opinions on this as well cc
Change:
```console [12:54:41] $ ./cluster/kubectl.sh describe pod simmemleak-hra99 <del> Name:               simmemleak-hra99 Namespace:          default Image(s):           saadali/simmemleak Node:               kubernetes-minion-tf0f/10.240.216.66 Labels:             name=simmemleak Status:             Running </del> <ins> Name:                           simmemleak-hra99 Namespace:                      default Image(s):                       saadali/simmemleak Node:                           kubernetes-minion-tf0f/10.240.216.66 Labels:                         name=simmemleak Status:                         Running </ins> Reason: Message: <del> IP:             10.244.2.75 Replication Controllers:    simmemleak (1/1 replicas created) </del> <ins> IP:                             10.244.2.75 Replication Controllers:        simmemleak (1/1 replicas created) </ins> Containers: simmemleak: Image:  saadali/simmemleak Limits: <del> cpu:      100m memory:       50Mi State:      Running Started:      Tue, 07 Jul 2015 12:54:41 -0700 Ready:      False Restart Count:  5 </del> <ins> cpu:                      100m memory:                   50Mi State:                      Running Started:                  Tue, 07 Jul 2015 12:54:41 -0700 Last Termination State:     Terminated Exit Code:                1 Started:                  Fri, 07 Jul 2015 12:54:30 -0700 Finished:                 Fri, 07 Jul 2015 12:54:33 -0700 Ready:                      False Restart Count:              5 </ins> Conditions: Type      Status Ready     False

Discussion:
Problem When a container is killed and restarted because, for example, it hit memory limits, the output only shows an increasing but no reason for why the container was killed: We can find the reason by inspecting the pod object ( shows as with ): Suggested Solution Modify to print termination reason, if available.
When this merges, need to update Search for in that doc.
Solved with .
Change:
}) /* <del> Testname: var-expansion-subpath-test-writes Description: Verify that a subpath expansion can be used to write files into subpaths. 1.	valid subpathexpr starts a container running 2.	test for valid subpath writes 3.	successful expansion of the subpathexpr isn't required for volume cleanup </del> <ins> Release : v1.19 Testname: VolumeSubpathEnvExpansion, subpath test writes Description: Verify that a subpath expansion can be used to write files into subpaths. 1.	valid subpathexpr starts a container running 2.	test for valid subpath writes 3.	successful expansion of the subpathexpr isn't required for volume cleanup </ins> */ <del> ginkgo.It("should succeed in writing subpaths in container [sig-storage][Slow]", func() { </del> <ins> framework.ConformanceIt("should succeed in writing subpaths in container [sig-storage][Slow]", func() { </ins> podName := "var-expansion-" + string(uuid.NewUUID()) containerName := "dapi-container"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind api-change /sig storage /sig node /sig testing Description: Promote e2e tests for VolumeSubpathEnvExpansion to Conformance as it is GA approved. Related Issues: GA Upgrade: Feature Request: KEP:
/assign
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
Change:
<ins> /* Copyright 2018 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 kubelet const ( NetworkNotReadyErrorMsg = "network is not ready" ) </ins>

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pods are synchronized by kubelet before network is ready. Synchronization in such case fails and pod is synchronized after 10 seconds. What you expected to happen: Kubelet should wait until network is ready before starting synchronizing pods. How to reproduce it (as minimally and precisely as possible): Configure cluster with Cluster Autoscaler enabled. Start pod so cluster is scaled up. In logs you might find following error: E0907 13:18:49. 972 ] Error syncing pod xxxxxx ("xxxxxxxxx(xxxxxxxxxxx)"), skipping: network is not ready: [runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: Kubenet does not have netConfig. This is most likely due to lack of PodCIDR] Environment: Build from HEAD Cloud provider or hardware configuration: GKE
/kind bug /sig node
Change:
ginkgo.It("should never report success for a pending container", func() { ginkgo.By("creating pods that should always exit 1 and terminating the pod after a random delay") <del> var reBug88766 = regexp.MustCompile(`ContainerCannotRun.*rootfs_linux.go.*kubernetes.io~secret.*no such file or directory`) </del> <ins> var reBug88766 = regexp.MustCompile(`rootfs_linux.*kubernetes.io~secret.*no such file or directory`) </ins> var ( lock sync.Mutex

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-e2e-gce Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: Triage board shows flakes here spiked dramatically on 3/4 /sig node /priority critical-urgent /milestone v1.18
are you able to assist if this is related to recent topology work?
sure, I'll take a look
is this the test you just in ?
As mentioned above, this is a new test that was just , and the test sometimes fails. I don't see that any of the recent topology manager changes would cause these failures. I'll be happy to help out and dig more if or others think otherwise.
This is me, the bugs are untriaged containerd / Kubelet failures with low occurrence rates that this test now exposes. Investigating.
still flaking in non-dockershim environments: pod pod-submit-status-0-14 on node kind-worker2 container unexpected exit code 128: start=1970-01-01 00:00:00 +0000 UTC end=2020-03-06 16:16:54 +0000 UTC reason=StartError message=failed to create containerd task: OCI runtime create failed: starting container process caused " container init caused " mounting "/var/lib/kubelet/pods/-819e-4840-8369-" to rootfs "" at "" caused "stat /var/lib/kubelet/pods/-819e-4840-8369- no such file or directory""": unknown `
Different reason this time. Will continue to enumerate failure modes.
Change:
} else { klog.V(4).Infof("running pod %q is pending termination", podPair.RunningPod.ID) } <del> return true </del> <ins> return </ins> } <del> return false </del> <ins> // Limit to one request per pod pk.podKillingCh <- podPair </ins> } // Close closes the channel through which requests are delivered

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: Right after calling , returns false even the pod is not killed yet. What you expected to happen: In kubelet, after is complete, the pod should be pending termination or be killed. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Related to Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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 node /assign
Change:
} } sortObjects(assumedClaims) <del> stripObjects(assumedClaims) </del> return assumedClaims }

Discussion:
pull-kubernetes-unit dynamicresources unknown multiple failures in tests as seen in n/a /sig scheduling
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
probably cc
/assign
DeepCopy missing here: