jiebi/CodeConvo huggingface dataset:
Change:
} return nil } <ins> // parseKVLines parses output that looks like lines containing "<key>: <val>" // and returns <val> if <key> is found. Otherwise, it returns the empty string. func parseKVLines(output, key string) string { delim := ":" key = key + delim for _, line := range strings.Split(output, "n") { pieces := strings.SplitAfterN(line, delim, 2) if len(pieces) != 2 { continue } k, v := pieces[0], pieces[1] if k == key { return strings.TrimSpace(v) } } return "" } </ins>

Discussion:
, func restartNodes, assumes that MIG rolling update on GCE will cause node restart. However, there is a feature of MIG rolling update (currently broken) that skips update if the new instance template is the same as the old one. The feature is supposed to work quite soon, so the test will not test anything (reboot will not be performed). A workaround may be to create an identical instance template with a different name. By the way, the current name is misleading. It should be . cc
Hi Marek, Was this changed recently? When we tried this originally it worked. Now, I just tried doing a rolling update to the same template, and it immediately fails with status "PAUSED" and status message "Errors: unknown". The name was chosen to attempt to be future-provider-agnostic, though I agree is better.
Actually, I'm trying it now, and it definitely sometimes works (recreates the instances). If this functionality isn't expected to work (or isn't supported) we can switch this to the equivalent MIG recreate-nodes call. I'll do this.
I've heard that some two months ago MIG update would not recreate new nodes if the template was the same. Then they changed it and instances were recreated (this is when you wrote the test). I think it is considered a bug. And they are going to fix this bug quite soon. So in a week or two (or maybe more - I don't know their release cycle), instances will not be recreated. (sorry for incomprehensible description of this issue - I'm correcting it now).
, I think your error is not related to MIG update - currently instances should be recreated (i.e. the error in MIG rolling update is not fixed). The error may be fixed around Monday (but maybe later - even 2 weeks).
Ack—thanks for the extra detail! I'll just switch this test to and we can stop worrying about the timing. We'll switch this in GKE too. Thanks again, I really appreciate you filing this!
(And by switch I mean just turn off self-upgrades.)
is this v1?
The referenced PR was a refactoring and Github got a bit confused. This issue isn't closed.

I don't think we need a test to recreate the MIG before v1.0 (although if it gets done before the freeze I don't see why we wouldn't merge it).
I'm leaving the project, so reassigning to... Have fun!
/sig testing
Fixed forever ago. /close
Change:
} }) <del> ginkgo.It("should not set default value if no default IngressClass", func() { </del> <ins> ginkgo.It("should not set default value if no default IngressClass [Serial]", func() { </ins> ingressClass1, err := createIngressClass(cs, "ingressclass1", false, f.UniqueName) framework.ExpectNoError(err) defer deleteIngressClass(cs, ingressClass1.Name)

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: gce-master-scale-correctness Which test(s) are flaking: [sig-network] Ingress API should support creating Ingress API operations [Conformance] Testgrid link: https://k8s- Reason for failure: Anything else we need to know: /kind flake /sig scalability /sig network /cc
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
this is caused by the issue described in a different test is creating a default ingressclass, which breaks creation of ingress objects if there was already a default ingressclass set up in the cluster /assign
this should resolve the issue:
I take it back, looks like the conformance test is also creating default ingressclass objects... it should not fix in
Change:
} for i, tc := range tests { <del> t.Run(string(i), func(t *testing.T) { </del> <ins> t.Run(strconv.Itoa(i), func(t *testing.T) { </ins> roleBinding, err := tc.options.createRoleBinding() if err != nil { t.Errorf("unexpected error:n%#vn", err)

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which test(s) are failing: Since when has it been failing: since upgrading golang: Reason for failure: Since Go 1.15, type casting from int to string using is not allowed, output: Anything else we need to know: related links: golang/go golang/go
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
the fix should be straight forward, so I can create a pull request to fix this. /sig testing /sig cli /assign
/assign
Change:
gvr("flowcontrol.apiserver.k8s.io", "v1beta2", "prioritylevelconfigurations"): { Stub:             `{"metadata": {"name": "conf3"}, "spec": {"type": "Limited", "limited": {"assuredConcurrencyShares":3, "limitResponse": {"type": "Reject"}}}}`, ExpectedEtcdPath: "/registry/prioritylevelconfigurations/conf3", <ins> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta3", "PriorityLevelConfiguration"), </ins> }, // --

Discussion:
adds new version for in 1.26. For 1.26, we are setting the storage version to because vN-1 understands that level. In 1.27, we should change the storage version from to .
/sig api-machinery
/cc
/cc
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Change:
fs.StringVar(&c.HairpinMode, "hairpin-mode", c.HairpinMode, "How should the kubelet setup hairpin NAT. This allows endpoints of a Service to loadbalance back to themselves if they should try to access their own Service. Valid values are "promiscuous-bridge", "hairpin-veth" and "none".") fs.Int32Var(&c.MaxPods, "max-pods", c.MaxPods, "Number of Pods that can run on this Kubelet.") <del> fs.StringVar(&c.PodCIDR, "pod-cidr", c.PodCIDR, "The CIDR to use for pod IP addresses, only used in standalone mode.  In cluster mode, this is obtained from the master. For IPv6, the minimum length of the cluster or pod CIDR is /66.") </del> <ins> fs.StringVar(&c.PodCIDR, "pod-cidr", c.PodCIDR, "The CIDR to use for pod IP addresses, only used in standalone mode.  In cluster mode, this is obtained from the master. For IPv6, the maximum number of IP's allocated is 65536") </ins> fs.Int64Var(&c.PodPidsLimit, "pod-max-pids", c.PodPidsLimit, "<Warning: Alpha feature> Set the maximum number of processes per pod.") fs.StringVar(&c.ResolverConfig, "resolv-conf", c.ResolverConfig, "Resolver configuration file used as the basis for the container DNS resolution configuration.")

Discussion:
/kind bug What happened: The kubelet command option description for pod-cidr shows the following "For IPv6, the minimum length of the cluster or pod CIDR is /66" however, this /66 restriction was removed with PR What you expected to happen: The command option should not display this restriction. How to reproduce it (as minimally and precisely as possible): 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:
/assign rpothier
/sig node
Change:
docker_pull( name = "debian-iptables-amd64", <del> digest = "sha256:bfc7cc030258f53495b5dacf1e1d750db9b8687577a8648a3c8e245f8d7d2c52",  # v7 </del> <ins> digest = "sha256:bc20977ac38abfb43071b4c61c4b7edb30af894c05eb06758dd61d05118d2842",  # v7 </ins> registry = "gcr.io", repository = "google-containers/debian-iptables-amd64", )

Discussion:
A number of addon images have CVEs that have been fixed in the upstream base images. We should update these images before the final 1.7 release. cc
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/cc
cc
The new image appears to have removed . I'm not sure if this was expected, but it caused at least fluentd to stop working on COS (). This might also affect kubeproxy, which uses (a derivative of ).
also the metadata-proxy, prometheus-to-sd, the fluentd-event-exporter, and ip-masq-agent.
anything more to do for this issue?
yes, I need to get merged and update those images again. I also need to bump a few other images (dns and ip-masq-agent).
should be the last update needed.
Change:
* [kubectl](kubectl.md)	 - kubectl controls the Kubernetes cluster manager <del> ###### Auto generated by spf13/cobra at 2015-07-16 22:39:16.132838722 +0000 UTC </del> <ins> ###### Auto generated by spf13/cobra at 2015-08-01 00:12:16.314376117 +0000 UTC </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->

Discussion:
The current documentation is very vague and doesn't explain what can be updated in this way. Can I rename or stop the pod, change number of replicas in RC etc. For example it seems to be impossible to change pod name:
cc
After an in person discussion with we think the docs should point people to the swagger-ui to find if a field is mutable. I'll add this point into the docs.
Change:
$(warning ***** finding all +k8s:deepcopy-gen tags) endif DEEPCOPY_DIRS := $(shell                                <del> grep -l '+k8s:deepcopy-gen=' $(ALL_K8S_TAG_FILES)   </del> <ins> grep --color=never -l '+k8s:deepcopy-gen=' $(ALL_K8S_TAG_FILES)   </ins> | xargs -n1 dirname                             | sort -u                                       )

Discussion:
Using the grep from OSX, fails when GREPOPTIONS/GREPCOLOR is set as shown below (). Workaround : unset GREPOPTIONS/GREPCOLOR Note that using GNU grep using brew install will show that GREPOPTIONS shows immediately that GREP_OPTIONS may be interfering with make ()
oh, here's badly manged conversion-
Will look, thanks. For make-related bugs, please @ me directly.
Will do. thanks
This breaks building kubernetes inside Alpine Linux:
I'm pressing more and more on the idea that the only supported build is the dockerized build. Trying to accomodate every random environment is just too taxing. , Marc Villacorta wrote:
I agree with We can support the stuff in to run on mac to get you dockerized but everything else is only supported in there. I've worked around a few BSD/OSX things in but it isn't fun. We should try to keep that stuff isolated.
I agree, with the usual caveat that we need to be doing all of the build in one container with as little as possible happening outside. OS X tends to have old and broken versions of important programs, which is terrible. We discussed setting up CI for it but it's not going to happen in the near term. Alpine/Busybox purposefully omit features from their versions for good reasons, but it's still more work to support than it's worth.
Ok, I will re-think my workflow.
How did you find yourself building in Alpine, in I may ask? , Marc Villacorta wrote:
nothing is forcing me to use Alpine I just like the distro. I run stuff on CoreOS and my aim is to solve the build-deliver-run pipeline with a single small container. By the way, I have the problem installing the GNU package :-)
Change:
// RemoveStatusCondition removes the corresponding conditionType from conditions. // conditions must be non-nil. func RemoveStatusCondition(conditions *[]metav1.Condition, conditionType string) { <del> if conditions == nil { </del> <ins> if conditions == nil || len(*conditions) == 0 { </ins> return } newConditions := make([]metav1.Condition, 0, len(*conditions)-1)

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 --Attempting to remove a status condition from an already empty slice panics. An empty slice should be removed (i.e. removed idempotently) and without panicking. Originally found with , reproduced with ( at the time of writing) Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g: ): Pop!OS 20.04 LTS Kernel (e.g. ): Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig api-machinery
cc
/assign
/triage accepted
Change:
len(nodes.Items)) } <del> ips := e2enode.CollectAddresses(nodes, v1.NodeInternalIP) </del> type NodeInfo struct { node   *v1.Node name   string nodeIP string } <ins> var family v1.IPFamily if framework.TestContext.ClusterIsIPv6() { family = v1.IPv6Protocol } else { family = v1.IPv4Protocol } ips := e2enode.GetAddressesByTypeAndFamily(&nodes.Items[0], v1.NodeInternalIP, family) </ins> clientNodeInfo := NodeInfo{ node:   &nodes.Items[0], name:   nodes.Items[0].Name, nodeIP: ips[0], } <ins> ips = e2enode.GetAddressesByTypeAndFamily(&nodes.Items[1], v1.NodeInternalIP, family) </ins> serverNodeInfo := NodeInfo{ node:   &nodes.Items[1], name:   nodes.Items[1].Name, <del> nodeIP: ips[1], </del> <ins> nodeIP: ips[0], </ins> } // Create a pod to check the conntrack entries on the host node

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: sig-network-kind-ipvs,dual,master sig-network-kind-ipvs,IPv6,master Which test(s) are failing: [x] KubeProxy should set TCP CLOSE_WAIT timeout [x] Conntrack should be able to preserve UDP traffic when server pod cycles for a NodePort Service [x] KubeProxy should resorve connection reset issue (tracking in ) Since when has it been failing: Oct 28 Testgrid link: sig-network-kind-ipvs,dual,master  Reason for failure: Both appear to be failing on missing conntrack entries ex. Anything else we need to know:
/sig network /cc /assign
I'm spinning up a kind cluster with ipv6+ipvs to see if I can replicate this test locally
/triage accepted
heh, the job was not running it, it started to run when we changed the tag I meant this test and the PR where we renamed the kube-proxy test
this one has an issue already open, and I have a PR for fixing it
reached out to me on Slack and we identified as the high priority. I have tested this locally and it fails on both IPTables and IPVS kind clusters locally. I'm digging through the cluster logs now.
I' ve logging to conntrack with level v4 recently just for these problems, try to bump your kube-proxy logging to v4
seems that there are less test failures on the IPv6 jobs, let's keep watching them :eyes: However, the dual-stack jobs are legit failures, basically because on dualstack clusters, the node has 2 internal IPs, and those tests use the internal IP for asserting some operations, and the problem is that they are picking the internalIP of the wrong IP family, hence the test fails The solution should be to add the InernalIp correspoding to the cluster primary IP familty, you can obtain it with but it seems that we have to modify the function or add a new one that returns the nodes and the corresponding ips
Hey Thanks for all the help, will look into the areas of the code and try to bump the logging.
Change:
} // We want to add the pod to the model iff the bind succeeds, but we don't want to race <del> // with any deletions, which happen asyncronously. </del> <ins> // with any deletions, which happen asynchronously. </ins> s.config.Modeler.LockedAction(func() { bindingStart := time.Now() err := s.config.Binder.Bind(b)

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [] Container Runtime blackbox test on terminated container should report termination message from log output if TerminationMessagePolicy FallbackToLogsOnError is set [NodeConformance] Since when has it been failing: Failing under PR Testgrid link: Reason for failure: Unable to match the inconsistent termination message with an expected value. Anything else we need to know: <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test
/sig testing /area conformance
Just for quick update. From the latest of PR , following points are observed from - PASSING under local cluster (hack/local-up-) tmp-node-e2e--coreos-beta-1883-1-0-v20180911 tmp-node-e2e--cos-stable-60-9592-84-0 tmp-node-e2e--cos-stable-63--71-0 FAILING under tmp-node-e2e--ubuntu-gke-1604-xenial-v20170420-1
Seeking attention from for troubleshooting issue. test is running successful on various platforms but not able to retrieve test's execution logs in kubelet's log. Tried investigating issue (ref ) from various execution platform where test is successful but couldn't find sufficient log entries. Seeking SIG help to troubleshoot test failure observed in PR
there are two problems here: 1) so far the broken tests never get run because a bug in the test code (this explains why pull-kubernetes-node-e2e never fails on our PRs), which should be fixed by . 2) With , I can reproduce your problem, and verify that the ubuntu image used in our test is broken. We will update the ubuntu image.
Thanks for looking into this long-awaited issue.
Change:
"k8s.io/apimachinery/pkg/util/wait" federationapi "k8s.io/kubernetes/federation/apis/federation/v1beta1" fedclientset "k8s.io/kubernetes/federation/client/clientset_generated/federation_clientset" <del> "k8s.io/kubernetes/pkg/api" </del> "k8s.io/kubernetes/pkg/api/v1" kubeclientset "k8s.io/kubernetes/pkg/client/clientset_generated/clientset" <ins> "k8s.io/kubernetes/pkg/cloudprovider" </ins> "k8s.io/kubernetes/test/e2e/common" "k8s.io/kubernetes/test/e2e/framework" fedframework "k8s.io/kubernetes/test/e2e_federation/framework"

Discussion:
In federation tests, if we observe the build logs. we see cleaning up LoadBalancer from cloud provider seems not working. It has 2 effects: delays the tests by waiting to delete but always returns error. so we waste like 5 minutes. maybe we are leaking the LoadBalancer in the project.
we can see these errors in every build. but just for reference here are some build logs https://k8s-
cc
All the errors in logs are . It doesn't necessarily indicate we are leaking resource, just now we must have clusterID initialized before calling EnsureLoadBalancerDeleted(). Would be better to not call this function directly in e2e test :)
Federation cleanup should use the same implementation as non-federated e2e test:
function looks like only specific to GCE. in future we would run the e2e tests in AWS too. it would be better to use generic functions if any.
using is working for us. here is the test logs https://k8s-
EnsureLoadBalancerResourcesDeleted() actually cleans up nothing, it only lists forwarding rules and probably logging :)
Change:
expansionFailed expansionFailedOnController expansionFailedOnNode <ins> expansionFailedMissingStagingPath </ins> ) const (

Discussion:
When a pod is quickly deleted and re-created on a node, it may not be necessary to unstage the volume and in which case only node-publish is called for the volume. When this happens - stagepath won't be set for RPC call because volume was not staged even though, volume does have capability. We should try and fix this behaviour so that - nodestagepath is always set in RPC call. We should try and fix this behaviour so that - nodestagepath is always set in RPC call. Quickly delete and recreate a pod No response master Any No response_ <details</details<details</details<details</details
/sig storage /triage accepted
Change:
}, } <del> time.Sleep(10 * time.Millisecond) if receivedCount != 1 { t.Errorf("Expected 1 call but got %v", receivedCount) </del> <ins> select { case <-received: case <-time.After(10 * time.Millisecond): t.Errorf("Expected 1 call but got 0") </ins> } // Test error case fakeEtcd.WatchInjectError <- fmt.Errorf("Injected error") <del> time.Sleep(10 * time.Millisecond) </del> // Did everything shut down? if _, open := <-fakeEtcd.WatchResponse; open {

Discussion:
Detected by
Create a Pod as follows: Name: jenkins Using image: jenkins In a new Kubenetes namespace named website-frontend kubectl create ns website-frontend apiVersion: v1 kind: Pod metadata: name: jenkins namespace: website-frontend spec: containers: name: jenkins image: jenkins kubectl create -f
Change:
devID1 := parseLog(f, pod1.Name, pod1.Name, deviceIDRE) gomega.Expect(devID1).To(gomega.Not(gomega.Equal(""))) <del> v1alphaPodResources, err := getV1alpha1NodeDevices() </del> <ins> v1alphaPodResources, err = getV1alpha1NodeDevices() </ins> framework.ExpectNoError(err) <del> v1PodResources, err := getV1NodeDevices() </del> <ins> v1PodResources, err = getV1NodeDevices() </ins> framework.ExpectNoError(err) framework.Logf("v1alphaPodResources.PodResources:%+vn", v1alphaPodResources.PodResources)

Discussion:
Device Plugin [Feature:DevicePluginProbe][NodeFeature:DevicePluginProbe][Serial] DevicePlugin [Serial] [Disruptive] Can schedule a pod that requires a device It appears a bit flaky on testgrid, but more recently been failing more often No response example - No response /sig node
/cc
/triage accepted /assign /priority important-soon
I ran this test locally 15 times back to back and did not run into this failure. The test passed locally. I suspect this to be a case where pod cleanup is not happening properly. In this test, we are relying on the number of PodResources and based on the error it looks like we have an addtional pod running other than the two expected pods (device plugin pod and test pod requesting device) but can't be 100% sure because we don't have enough logs to support that claim. Going to add more logs to expose output obtained from the podresource API endpoint.
Change:
Failf("got unexpected len(Status.LoadBalancer.Ingresss) for NodePort service: %v", service) } ingress2 := service.Status.LoadBalancer.Ingress[0] <del> // TODO: This is a problem on AWS; we can't just always be changing the LB Expect(ingress1).To(Equal(ingress2)) </del> <ins> // TODO: Fix the issue here: https://github.com/GoogleCloudPlatform/kubernetes/issues/11002 if providerIs("aws") { // TODO: Make this less of a hack (or fix the underlying bug) time.Sleep(time.Second * 120) service, err = waitForLoadBalancerIngress(c, serviceName, ns) Expect(err).NotTo(HaveOccurred()) // We don't want the ingress point to change, but we should verify that the new ingress point still works ingress2 = service.Status.LoadBalancer.Ingress[0] Expect(ingress1).NotTo(Equal(ingress2)) } else { Expect(ingress1).To(Equal(ingress2)) } </ins> By("hitting the pod through the service's updated NodePort") testReachable(ip, nodePort2)

Discussion:
Currently, when we change a service with a LoadBalancer, we will often delete the load balancer and create a new one. If possible, we should not do that: on GCE it may involve temporary service disruption, although the new LB has the same IP. On AWS a new ELB is created with a different DNS name, so the user must update their DNS settings. (We have a PR that fixes this , but it is post-v1; I am filing this bug to document the improvement needed, and then changing the tests to test the current state of the world)
How is the LB preserved? indicates it is NOT preserved, making this higher prio.
We do have an e2e test for this, but perhaps it isn't testing what I think it is. highlights that we definitely don't preserve it on AWS, but the test should be checking that it is preserved on GCE.