jiebi/CodeConvo huggingface dataset:
Change:
ret['details'] = {} # This module function is strange and returns True if the rule exists. # If not, it returns a string with the error from the call to iptables. <del> ret['iptables_rule_exists'] =  __salt__['iptables.check'](**iptables_rule) == True </del> <ins> ret['iptables_rule_1_exists'] =  __salt__['iptables.check'](**iptables_rule_1) == True ret['iptables_rule_2_exists'] =  __salt__['iptables.check'](**iptables_rule_2) == True </ins> return ret # This is a little hacky.  I should probably import a real library for this

Discussion:
Spin up a cluster. Create a container on each of two machines. Try to ping each other's IPs. No love. It seems we need an extra iptables rule. For example, for a minion with the 10.244.2.0/24 subnet assigned, we need: iptables -t nat -A POSTROUTING -s 10.244.2.0/24 ! -d 10.244.2.0/24 -j MASQUERADE
Hrm, I can't repro this. I tried: ping 10.244.2.1 from a different kubernetes VM and it worked. (or do you mean from inside a container?)
From within a container to another container
repro'ed it for me, too.
Is this just ping? Or is this any network traffic? , Tim Hockin wrote:
Any traffic - the kernel is not masquerading it because our iptables magic doesn't match packets coming from inside a container on a veth. I saw this while trying to do another round of perf tests.
Change:
} else { helper := resource.NewHelper(o.restClient, o.nodeInfo.Mapping) unsched.SetBool(desired) <del> _, err := helper.Replace(cmdNamespace, o.nodeInfo.Name, true, o.nodeInfo.Object) </del> <ins> var err error for i := 0; i < kMaxNodeUpdateRetry; i++ { // We don't care about what previous versions may exist, we always want // to overwrite, and Replace always sets current ResourceVersion if version is "". helper.Versioner.SetResourceVersion(o.nodeInfo.Object, "") _, err = helper.Replace(cmdNamespace, o.nodeInfo.Name, true, o.nodeInfo.Object) if err != nil { if !apierrors.IsConflict(err) { return err } } else { break } // It's a race, no need to sleep } </ins> if err != nil { return err }

Discussion:
Even on a cluster of size 3, I regularly see concurrent modification problems with kubectl: NODES= for node in node; done for node in node; done Doing that a few times and you are likely to see something like: I suspect that 1) kubectl cordon / uncordon should retry (or use a PATCH method)? 2) something - maybe the heartbeat? is causing concurrent modifications to the cluster. (if we have trouble reproducing I can try to narrow this down - I'm going to test with an empty cluster later; right now it is a cluster with lots of PetSets & volumes)
I'd bet that this is caused by node status updates. And I'd agree that cordon should probably retry.
Change:
--accept-hosts="^localhost$,^127.0.0.1$,^[::1]$": Regular expression for hosts that the proxy should accept. --accept-paths="^/.*": Regular expression for paths that the proxy should accept. --address="127.0.0.1": The IP address on which to serve on. <del> --api-prefix="/api/": Prefix to serve the proxied API under. </del> <ins> --api-prefix="/": Prefix to serve the proxied API under. </ins> --disable-filter[=false]: If true, disable request filtering in the proxy. This is dangerous, and can leave you vulnerable to XSRF attacks, when used with an accessible port. -p, --port=8001: The port on which to run the proxy. Set to 0 to pick a random port. --reject-methods="POST,PUT,PATCH": Regular expression for HTTP methods that the proxy should reject.

Discussion:
Now that we've moved the experimental api to /apis/experimental... it's inaccessible from by default. We should fix that. who stepped on this earlier
security questions for you: this prefix was apparently in response to a security review quite some time ago. I don't understand how this adds much security. Can we just remove it? If not, is it acceptable to change the default from "/api/" to "/api", which would match both api locations? Otherwise we'll have to take a comma-separated list or something...
Ref
Oh, so this is not related to the security requests! And the original use case was just to re-root the URL path so it didn't interfere with static content. Sorry, I got confused because the last time I monkeyed with that, it was in conjunction with the allow/deny list that actually was the security request. In that case, let's see if we can change the default to "/", if that will break anything.
That change got introduced as part of to protect against XSRF in kubectl proxy. But I think the more important part of that change was that it disallows POST/PUT/PATCH by default. So as long as there is no state changing action outside of /api/ that can be triggered with a GET it should be safe to remove.
Change:
return fmt.Errorf("%v", strings.Join(errMsg, "; ")) } <del> // NodeRunningOutdatedKubelet returns true if the kubeletVersion reported // in the nodeInfo of the given node is "outdated", meaning < 1.2.0. // Older versions were inflexible and modifying pod.Status directly through // the apiserver would result in unexpected outcomes. func NodeRunningOutdatedKubelet(node *v1.Node) bool { v, err := utilversion.ParseSemantic(node.Status.NodeInfo.KubeletVersion) if err != nil { glog.Errorf("couldn't parse version %q of node %v", node.Status.NodeInfo.KubeletVersion, err) return true } if v.LessThan(podStatusReconciliationVersion) { glog.Infof("Node %v running kubelet at (%v) which is less than the minimum version that allows nodecontroller to mark pods NotReady (%v).", node.Name, v, podStatusReconciliationVersion) return true } return false } </del> // NodeExistsInCloudProvider returns true if the node exists in the // cloud provider. func NodeExistsInCloudProvider(cloud cloudprovider.Interface, nodeName types.NodeName) (bool, error) {

Discussion:
As discussed on slack with we might want to clean the node controller from code that ensures backward compatibility for version 1.4 and earlier ones. /sig node
/assign
- how do we plan to devide this one ? The following order for merge should be fine I think: the tests (we can split also test case deletion if it's too long to review): logic itself + kubeletVersion on the according tests: change how we create nodecontroller: clean consts and BUILD:
Yeah, sounds good.
I'll create the PRs accordingly and assign them to you
Change:
return err } opts.Config = config <del> opts.AttachFunc = attach.DefaultAttachFunc </del> <ins> opts.AttachFunc = attachFunc </ins> <del> clientset, err := kubernetes.NewForConfig(config) </del> <ins> clientset, err := f.KubernetesClientSet() </ins> if err != nil { return err }

Discussion:
The command provides a flag but this doesn't do anything. most likely the flag shouldn't exist. I have no idea how kustomize could be useful here to start a single pod. This creates a pod, and shows that is ignored: No response <details</details<detailsAzure, K3OS</details<detailsOSX 11.6.1 (Big Sur) </detailsNo response No response No response
/sig cli
This comes from the inclusion of DeleteFlags: brings in FilenameFlags: has Kustomize, resulting in the flag: I suspect there are many flags from DeleteFlags that don't really apply to . : Not sure what this would do : seems to be ignored and : doesn't seem to be used : doesn't seem to be used : also probably doesn't apply There might be others as well...
It seems to delete object which created by command.
I agree, As far as I can see, , and have this deleteFlags exposure.
/assign
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
/triage accepted
Change:
} func (r *SimpleProxyReactor) Handles(action Action) bool { <del> resourceCovers := r.Resource == "*" || r.Resource == action.GetResource().Resource if !resourceCovers { return false } return true </del> <ins> return resourceCovers(r.Resource, action) </ins> } func (r *SimpleProxyReactor) React(action Action) (bool, restclient.ResponseWrapper, error) { return r.Reaction(action) } <ins> func resourceCovers(resource string, action Action) bool { if resource == "*" { return true } if resource == action.GetResource().Resource { return true } if index := strings.Index(resource, "/"); index != -1 && resource[:index] == action.GetResource().Resource && resource[index+1:] == action.GetSubresource() { return true } return false } </ins>

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 -- Can't match "serviceaccounts/token", can only match "serviceaccounts" Can match "serviceaccounts/token"
/kind feature
/sig testing
/assign
/triage accepted
Change:
kc.ClusterDomain, net.IP(kc.ClusterDNS)) <ins> if err != nil { return nil, err } </ins> k.BirthCry() go k.GarbageCollectLoop() go kubelet.MonitorCAdvisor(k, kc.CAdvisorPort) kubelet.InitHealthChecking(k) <del> return k </del> <ins> return k, nil </ins> }

Discussion:
Things like SyncFrequency should have a lower-bound of acceptable, and that really should be 0ns.
The main point of this is now fixed, though we could be better about input checking all over
Change:
REGISTRY ?= gcr.io/kubernetes-e2e-test-images GOARM=7 QEMUVERSION=v2.9.1 <del> GOLANG_VERSION=1.11.2 </del> <ins> GOLANG_VERSION=1.11.3 </ins> export ifndef WHAT

Discussion:
The go team has released 1.11.3 with three security fixes. From their e-mail announcement: We should kick off upgrades of both the kubernetes build system, and our CI, as soon as possible. Do you have an ETA for the rules_go bump that will contain 1.11.3 toolchain support? cc:
I'm preparing releases that use Go 1.11.3 by default. Those will be on the rules_go 0.14, 0.15, and 0.16 branches. I expect to tag them tonight as soon as they get through CI.
Fantastic! Thank you
rules_go 0.14.7, 0.15.9, and 0.16.4 are now tagged and ready to go.
related commits and issue:
Reopening to track other branches, as well as the CI bump
go1.11.3 and go1.10.6 introduced a regression, and so go1.11.4 and go1.10.7 were released Friday afternoon with a fix. We'll need to bump everything again on master, and should hold off on cherry-picks for now.
This looks fixed by Is there anything else that needs to be done as well?
Still need to merge for k8s 1.13.
Closing as all branches are now up to date.
Change:
} } <ins> func TestIsValidGroupId(t *testing.T) { goodValues := []int64{0, 1, 1000, 65535, 2147483647} for _, val := range goodValues { if !IsValidGroupId(val) { t.Errorf("expected true for '%d'", val) } } badValues := []int64{-1, -1003, 2147483648, 4147483647} for _, val := range badValues { if IsValidGroupId(val) { t.Errorf("expected false for '%d'", val) } } } func TestIsValidUserId(t *testing.T) { goodValues := []int64{0, 1, 1000, 65535, 2147483647} for _, val := range goodValues { if !IsValidUserId(val) { t.Errorf("expected true for '%d'", val) } } badValues := []int64{-1, -1003, 2147483648, 4147483647} for _, val := range badValues { if IsValidUserId(val) { t.Errorf("expected false for '%d'", val) } } } </ins> func TestIsValidPortName(t *testing.T) { goodValues := []string{"telnet", "re-mail-ck", "pop3", "a", "a-1", "1-a", "a-1-b-2-c", "1-a-2-b-3"} for _, val := range goodValues {

Discussion:
Help review this, thanks.
Are you asking for better validation on pod creation? I'm not really sure what you mean when you say "tip".
Yes, I mean it's better validate the pod when create. The tip mean the validation info response from server and show by client.
Change:
<ins> # Maintainers Eric Paris <eparis@redhat.com> </ins>

Discussion:
This issue is a bucket placeholder for collaborating on the "Known Issues" additions for the 1.22 Release Notes(). If you know of issues or API changes that are going out in 1.22, please comment here so that we can coordinate incorporating information about these changes in the Release Notes. /assign /sig release /milestone v1.22
GitHub didn't allow me to assign the following users: simcard0000. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : This issue is a bucket placeholder for collaborating on the "Known Issues" additions for the 1.22 Release Notes(). If you know of issues or API changes that are going out in 1.19, please comment here so that we can coordinate incorporating information about these changes in the Release Notes. /sig release /milestone v1.22 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
/triage accepted
1.19 or 1.22 ?
/assign
For the 1.21 example in , should be changed to
Please add the following to the Known Issues section of the 1.22 Release Notes: CC
Can you also mention the CSIMigrationVSphere feature gate in the note as well?
what should I mention about the CSIMigrationVSphere feature gate? If someone uses vSphere CSI Driver, he/she should not upgrade to v1.22 whether CSIMigrationVSphere is on or off. If someone does not use vSphere CSI Driver, then we also don't need to worry about this feature gate.
If the feature gate is enabled, they should also hold off on upgrading to 1.22
The main concern as far as k8s release is - it is intree to CSI migration of vSphere volumes that is broken in 1.22. So I think our release note should say something like:
Change:
return fmt.Errorf("deployment %q failed to create new replica set", deploymentName) } if err != nil { <del> return fmt.Errorf("error waiting for deployment %q (got %s / %s) and new replica set %q (got %s / %s) revision and image to match expectation (expected %s / %s): %v", deploymentName, deployment.Annotations[deploymentutil.RevisionAnnotation], deployment.Spec.Template.Spec.Containers[0].Image, newRS.Name, newRS.Annotations[deploymentutil.RevisionAnnotation], newRS.Spec.Template.Spec.Containers[0].Image, revision, image, err) </del> <ins> if deployment == nil { return errors.Wrapf(err, "error creating new replica set for deployment %q ", deploymentName) } deploymentImage := "" if len(deployment.Spec.Template.Spec.Containers) > 0 { deploymentImage = deployment.Spec.Template.Spec.Containers[0].Image } newRSImage := "" if len(newRS.Spec.Template.Spec.Containers) > 0 { newRSImage = newRS.Spec.Template.Spec.Containers[0].Image } return fmt.Errorf("error waiting for deployment %q (got %s / %s) and new replica set %q (got %s / %s) revision and image to match expectation (expected %s / %s): %v", deploymentName, deployment.Annotations[deploymentutil.RevisionAnnotation], deploymentImage, newRS.Name, newRS.Annotations[deploymentutil.RevisionAnnotation], newRSImage, revision, image, err) </ins> } return nil }

Discussion:
Found in local testing. Looks like it's coming from:
/area conformance
/sig testing
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(`rootfs_linux.*kubernetes.io~secret.*no such file or directory`) </del> <ins> var reBug88766 = regexp.MustCompile(`rootfs_linux.*kubernetes.io~(secret|projected).*no such file or directory`) </ins> var ( lock sync.Mutex

Discussion:
ci-kubernetes-e2e-gce-scale-correctness [sig-node] Pods Extended Pod Container Status should never report success for a pending container 2021-02-19 https://k8s- ! Feb 19 12:22:34.933: 1 errors: pod pod-submit-status-0-11 on node gce-scale-cluster-minion-group-2-cczj container unexpected exit code 128: start=1970-01-01 00:00:00 +0000 UTC end=2021-02-19 12:21:43 +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/-96dc-4682-af6a-" to rootfs "" at "" caused "stat /var/lib/kubelet/pods/-96dc-4682-af6a- no such file or directory""": unknown /sig scalability /sig node It failed 6/10 times in recent runs /priority critical-urgent /cc /cc
/triage accepted /cc
I do not see any recent changes in test setup, apart from test renames.
Test is already ignoring: Looks very similar, so probably regex should be extended. Original issues and PRs: /assign
could you triage?
We meet tomorrow, I'll make sure this is on our board/agenda.
Injected service account tokens changed from secret-based to projected-token based by default in , which merged 2/18 That coincides with this flake starting: as points out, the test already tolerated secret volume setup errors, I guess because those error messages are expected to occur spuriously in rapidly restarting containers? If it was acceptable for secret volume errors to be encountered in this test before, I agree the regex should be expanded to accomodate projected volume tokens. opened to do this. Separately, is sig storage or sig node looking at
Change:
nodeName := types.NodeName("instance") readOnly := false spec := createVolSpec(diskName, readOnly) <del> attachError := errors.New("Fake attach error") </del> detachError := errors.New("Fake detach error") diskCheckError := errors.New("Fake DiskIsAttached error") tests := []testcase{ // Successful Attach call { <del> name:   "Attach_Positive", attach: attachCall{diskName, nodeName, nil}, </del> <ins> name:           "Attach_Positive", diskIsAttached: diskIsAttachedCall{diskName, nodeName, false, diskCheckError}, attach:         attachCall{diskName, nodeName, nil}, </ins> test: func(testcase *testcase) (string, error) { attacher := newAttacher(testcase) return attacher.Attach(spec, nodeName)

Discussion:
Currently we don't check if disk is already attached : from what i remember it can cause some problems, but not sure, sorry for the mass tag
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 storage /assign
Change:
import ( "path" "testing" <del> "time" </del> "github.com/stretchr/testify/require"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: For now, UT in doesn't work because callback function will never be called, is rewritten in this function : Another thing, i'm wondering why we rewrite device health in function which in this file: What you expected to happen: UT assertion should be executed. How to reproduce it (as minimally and precisely as possible): Add some logs in callback function of , it will show nothing. Anything else we need to know?: I will send a PR to fix this. /cc WDYT? /sig node
/assign
GitHub didn't allow me to assign the following users: RenaudWasTaken. Note that only can be assigned. <detailsIn response to : /assign 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
Good catch
Change:
APIVersion: "v1", FieldPath:  "spec.containers[3]", }, <del> Reason:  "Started", Message: "some verbose message: 1", Source:  v1.EventSource{Component: "eventTest"}, Count:   1, Type:    v1.EventTypeNormal, </del> <ins> Reason:              "Started", Message:             "some verbose message: 1", Source:              v1.EventSource{Component: "eventTest"}, ReportingController: "eventTest", Count:               1, Type:                v1.EventTypeNormal, </ins> }, expectLog:    `Event(v1.ObjectReference{Kind:"Pod", Namespace:"baz", Name:"foo", UID:"differentUid", APIVersion:"v1", ResourceVersion:"", FieldPath:"spec.containers[3]"}): type: 'Normal' reason: 'Started' some verbose message: 1`, expectUpdate: false,

Discussion:
From the Deprecated API Migration Guide: , since v1.19, the has been using the new reportingController and reportingInstance to replace the decrecated source.component and But when I checked the Kube events in a cluster with version 1.26.0, those new fields are empty and the supposed to be deprecated fields have not been renamed. Seeing the values in the new fields like reportingController and reportingInstance an Kubernetes cluster with version 1.26.0 some Kube events the Kube events details for the field of reportingController, reportingInstance, source.component, No response <detailsServer Version: version.Info{Major:"1", Minor:"26", GitVersion:"v1.26.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2022-12-11T00:15:47Z", GoVersion:"go1.19.4", Compiler:"gc", Platform:"linux/amd64"} </details<detailsAzure </details<details</details<details</details<details</details<details</details
/sig instrumentation
I have also encountered this issue in my local 1.26.0 Kubernetes cluster, which does not align with the deprecation guide described in I believe I can investigate this further
/assign
Thank you for making the PR to fix this! Also a comment in the PR for the doc update.
/triage accepted
Change:
DNS configuration MUST be configured in the Pod. release: v1.17 file: test/e2e/network/dns.go <ins> - testname: Scheduling, HostPort matching and HostIP and Protocol not-matching codename: '[sig-network] HostPort validates that there is no conflict between pods with same hostPort but different hostIP and protocol [LinuxOnly] [Conformance]' description: Pods with the same HostPort value MUST be able to be scheduled to the same node if the HostIP or Protocol is different. This test is marked LinuxOnly since hostNetwork is not supported on Windows. release: v1.16, v1.20 file: test/e2e/network/hostport.go </ins> - testname: Ingress API codename: '[sig-network] Ingress API should support creating Ingress API operations [Conformance]'

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: We want to change ownership of a test from scheduler to network Which test(s) are failing: [sig-scheduling] SchedulerPredicates [Serial] validates that there is no conflict between pods with same hostPort but different hostIP and protocol [Conformance] Since when has it been failing: Testgrid link: https://k8s- Reason for failure: Once merges, we will exclude hostPort test on Windows. This is because of how the hostPort test is structured where we are relying on hostNetwork pod to test the communication between hostPort pods. This will not work on Windows as hostNetwork is not supported. I think it is better to have this test in sig-network and test the communication as scheduler should be responsible only for assigning a pod to node. This also ensures that hostPort on Windows is exercised properly. Anything else we need to know: More context
/sig scheduling /sig network cc
/area conformance /area test /sig windows since windows
/triage accepted