jiebi/CodeConvo huggingface dataset:
Change:
return rs.Address.Equal(other.Address) && rs.Port == other.Port } <ins> // GetKernelVersionAndIPVSMods returns the linux kernel version and the required ipvs modules func GetKernelVersionAndIPVSMods(Executor exec.Interface) (kernelVersion string, ipvsModules []string, err error) { kernelVersionFile := "/proc/sys/kernel/osrelease" out, err := Executor.Command("cut", "-f1", "-d", " ", kernelVersionFile).CombinedOutput() if err != nil { return "", nil, fmt.Errorf("error getting os release kernel version: %v(%s)", err, out) } kernelVersion = strings.TrimSpace(string(out)) // parse kernel version ver1, err := version.ParseGeneric(kernelVersion) if err != nil { return kernelVersion, nil, fmt.Errorf("error parsing kernel version: %v(%s)", err, kernelVersion) } // "nf_conntrack_ipv4" has been removed since v4.19 // see https://github.com/torvalds/linux/commit/a0ae2562c6c4b2721d9fddba63b7286c13517d9f ver2, _ := version.ParseGeneric("4.19") // get required ipvs modules if ver1.LessThan(ver2) { ipvsModules = append(ipvsModules, ModIPVS, ModIPVSRR, ModIPVSWRR, ModIPVSSH, ModNfConntrackIPV4) } else { ipvsModules = append(ipvsModules, ModIPVS, ModIPVSRR, ModIPVSWRR, ModIPVSSH, ModNfConntrack) } return kernelVersion, ipvsModules, nil } </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!--kube-proxy cannot use ipvs mode on Linux 4.19 due to a check for the module, which was changed to (). uses to check for : It should instead accept on Linux 4.19 or above. What happened: kube-proxy fell back from ipvs mode to iptables mode. What you expected to happen: kube-proxy using ipvs. How to reproduce it (as minimally and precisely as possible): Launch a cluster on an image using Linux 4.19 or above with kube-proxy using ipvs mode (see ). Environment: Kubernetes version (use ): All Kernel (e.g. ): 4.19 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig network
/area ipvs /assign /cc
Okay, so should check {nfconntrackipv4 | nf_conntrack} and expect load at least one module?
I think so
Please just go ahead :)
Change:
} } <ins> // Set the expire_nodest_conn sysctl we need for if val, _ := sysctl.GetSysctl(sysctlExpireNoDestConn); val != 1 { if err := sysctl.SetSysctl(sysctlExpireNoDestConn, 1); err != nil { return nil, fmt.Errorf("can't set sysctl %s: %v", sysctlExpireNoDestConn, err) } } // Set the expire_quiescent_template sysctl we need for if val, _ := sysctl.GetSysctl(sysctlExpireQuiescentTemplate); val != 1 { if err := sysctl.SetSysctl(sysctlExpireQuiescentTemplate, 1); err != nil { return nil, fmt.Errorf("can't set sysctl %s: %v", sysctlExpireQuiescentTemplate, err) } } </ins> // Set the ip_forward sysctl we need for if val, _ := sysctl.GetSysctl(sysctlForward); val != 1 { if err := sysctl.SetSysctl(sysctlForward, 1); err != nil {

Discussion:
What happened: After updating the pods backing a service with sessionAffinity set, all communications to the service stopped working. What you expected to happen: Communications should continue to work How to reproduce it (as minimally and precisely as possible): 1- Create a service with backed by a deployment of a single pod 2- Connect to the service from a pod 3- Delete the pod and wait for it to recreate When trying to reconnect to the service all packets will be lost until the real server is removed because the persistency remains regardless of . In addition, if the client keeps retrying, the number of connections to the real server will never reach 0 and it will not be deleted (until the persistency timeout expires, which by default takes 3h) Anything else we need to know?: I did some testing and setting fixes the issue. I'll create a PR tomorrow (including some changes discussed in which are related) Environment: Kubernetes version (use ): kube-proxy OS (e.g. from /etc/os-release): Kernel (e.g. ): /area ipvs /sig network /kind bug /assign
Change:
# Configure kube-proxy to run as a windows service. flags+=" --windows-service=true" <del> # TODO(mtaufen): Configure logging for kube-proxy running as a service. # I haven't been able to figure out how to direct stdout/stderr into log # files when configuring it to run via sc.exe, so we just manually # override logging config here. flags+=" --log-file=${WINDOWS_LOGS_DIR}kube-proxy.log" # klog sets this to true internally, so need to override to false # so we actually log to the file flags+=" --logtostderr=false" </del> # Enabling Windows DSR mode unlocks newer network features and reduces # port usage for services. # https://techcommunity.microsoft.com/t5/networking-blog/direct-server-return-dsr-in-a-nutshell/ba-p/693710

Discussion:
/kind feature Hey, in K8s 1.23 we are planning to deprecate multiple klog flags. Deprecated flags: , , , , , , , , , , , One of the alpha milestones is requires us to remove usage of deprecated flags within K8s repo. Examples found for windows [ ] [ ] /sig windows /wg structured-logging
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign I've started looking into this. Part of the problem is that go-runner is not part of kubernetes-node-windows- I suspect that is where the scripts get and kube- from.
Change:
if es.cgroupsPerQOS { cmdArgs = append(cmdArgs, "--cgroups-per-qos", "true", <del> "--cgroup-root", "/", </del> ) } if !*disableKubenet {

Discussion:
In node-e2e-test on Containervm image, the containers of the pods created by Kubernetes are subcontainers of docker-daemon/docker/. It means that the runtime resource usage (docker-daemon) is not correct, because all pods are included. This problem maybe due to container misconfiguration in node-e2e-test.
The kubelet on debian-based containervm image is misconfigured. Will fix it shortly.
Change:
message Mount { // Path of the mount within the container. string container_path = 1; <del> // Path of the mount on the host. </del> <ins> // Path of the mount on the host. If the hostPath doesn't exist, then runtimes // should report error. If the hostpath is a symbolic link, runtimes should // follow the symlink and mount the real destination to container. </ins> string host_path = 2; // If set, the mount is read-only. bool readonly = 3;

Discussion:
Currently, Docker create the host directory if the host path does not exist. For host path, Kubelet doesn't check the host directory existence, and pass the mount to docker directly. Given so, we should: 1) Either clearly define the expectation in CRI; 2) Or create the host directory ourselves when it doesn't exist. /cc
I think hostPath is expected to be already exist and kubelet should create the host directory if it is not exist.
Hmm, another problem is how to known whether hostPath is (expected) file or directory? Since it doesn't exist, we can only assume it is a directory?
There is a new field in the hostpath spec, that may help:
Another thing we may want to clearly define is: If when the host path is a symlink, what is the expected behavior. I think we assume container runtime should follow the symlink and mount the real content, but it's not clearly defined anywhere.
can you clarify, when you say "host path", are you referring specifically to hostPath volumes, or to any volume plugin's host-side path that gets passed into CRI?
I believe it's .
/cc
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. Prevent issues from auto-closing with an comment. 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:
ginkgo.BeforeEach(func() { c = f.ClientSet ns = f.Namespace.Name <ins> dc = f.DynamicClient </ins> }) ginkgo.It("deployment reaping should cascade to its replica sets and pods", func() {

Discussion:
[x] Original approval issue: [x] Test pr: [x] Two weeks soak end date: 19 November 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still some remaining Deployment endpoints which are untested. a Deployment with a static label the Deployment with a new Label and updated data the Deployment to ensure it's patched all Deployments in all Namespaces find the Deployment(1) ensure that the Deployment is found and is patched Namespaced Deployment(1) via a Collection with a LabelSelector Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 5 points* This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
BobyMcbobs commented in original Issue: Unsure if the endpoint replaceAppsV1NamespacedDeploymentStatus is able to be hit. When this endpoint is attempted to be updated the data after retrieving the update resource doesn't reflect the values in the update
/assign
When using the appv1.Deployment structure instead of maps of interfaces to build the structure in a patch of the Deployment, this error comes up. Still in progress yment-static":"true"}: does not match template , spec.selector: Invalid value: "null": field is immutable]
replaceAppsV1NamespacedDeploymentStatus to test. Increase cover by 1 Endpoint
/reopen PR reverted by due to flaky test
Reopened this issue. <detailsIn response to : /reopen PR reverted by due to flaky test 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
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
/reopen Soaking, ready for promotion 19 November 2020
Reopened this issue. <detailsIn response to : /reopen Soaking, ready for promotion 19 November 2020 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
/remove-lifecycle stale
/triage accepted
/merged
Change:
"strings" "testing" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" api "k8s.io/kubernetes/pkg/apis/core" )

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: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:
Change:
} } <del> s.Broadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: s.EventClient.Events("")}) </del> <ins> if s.Broadcaster != nil && s.EventClient != nil { s.Broadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: s.EventClient.Events("")}) } </ins> // Start up a healthz server if requested if s.HealthzServer != nil {

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?: bug What happened: Got panic after running: Panic: What you expected to happen: No panic and exit successfully. How to reproduce it (as minimally and precisely as possible): Run the following command on both CoreOS v1298.7.0(bare metal) and Ubuntu 16.04.2 LTS(OpenStack) Happened with the following versions: v1.7.0-alpha.3 v1.7.0-alpha.4 v1.7.0-beta.0 v1.7.0-beta.1 v1.7.0-beta.2 v1.7.0-rc.1 v1.8.0-alpha.0 v1.8.0-alpha.1 Anything else we need to know?: I guess it caused by . Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Both CoreOS v1298.7.0(bare metal) and Ubuntu 16.04.2 LTS(OpenStack) Kernel (e.g. ): CoreOS v1298.7.0: Linux node- 4.9.16-coreos-r1 SMP Tue Apr 4 19:09:38 UTC 2017 x8664 Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz GenuineIntel GNU/Linux Ubuntu 16.04.2 LTS: Linux ubuntu- 4.4.0-62-generic -Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig network /area kube-proxy
/cc
cc/ Looks like there is a new regression in v1.7. Please triage this to decide if it is a release blocker. If not, please provide the workaround for the users. Thanks!

cc/
Digging into the code, will send a PR.
PR sent. Folks review it please.
Added the release-blocker label. We got a PR for it very fast so it won't delay the release anyway, thanks
Change:
testCases := map[string]struct { clientConfig *testClientConfig icc          *testICC <ins> overrides    *ConfigOverrides </ins> checkedICC bool result     string <del> ok         bool </del> <ins> overridden bool </ins> err        error }{ "in-cluster checked on empty error": {

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!--What happened: In-cluster namespace isn't overridden by kubeconfig if the context is specified via kubectl flag. When using , the override works as expected. What you expected to happen: If I specify for a context in kubeconfig, then I expect to use as the default namespace, regardless of whatever's in . How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: supposedly fixed this issue, but not for the case where the context is specified via a command line flag (). This is because this line checks for . Environment: Kubernetes version (use ): v1.10.5 (details above) Cloud provider or hardware configuration: - OS (e.g. from /etc/os-release): - Kernel (e.g. ): - Install tools: - Others: - <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
fixed in
Change:
# A set of helpers for starting/running etcd for tests <del> ETCD_VERSION=${ETCD_VERSION:-3.5.3} </del> <ins> ETCD_VERSION=${ETCD_VERSION:-3.5.4} </ins> ETCD_HOST=${ETCD_HOST:-127.0.0.1} ETCD_PORT=${ETCD_PORT:-2379} # This is intentionally not called ETCD_LOG_LEVEL:

Discussion:
Please publish 3.5.4-0 image and update to to benefit from fix for , while still keeping v3.5.3 critical correctness fixes (, ). For recent PRs for update to etcd v3.5.3 see and
/sig release /sig api-machinery /kind bug
/cc /triage accepted
Hey, Can I work on this ? I'm a beginner, but all the good first issues are mostly assigned. Can you guide me on doing this ?
I am working on this. /assign
Hi I would like to work on Make sense to backport in v1.22, v1.23 & v1.24? Thanks!!
hi, it makes sense to me, but requires approval from dependency maintainers. i can only approve the kubeadm changes.
was this backported ?
Change:
func (e *exists) Admit(a admission.Attributes) (err error) { defaultVersion, kind, err := api.RESTMapper.VersionAndKindForResource(a.GetResource()) if err != nil { <del> return admission.NewForbidden(a, err) </del> <ins> return errors.NewInternalError(err) </ins> } mapping, err := api.RESTMapper.RESTMapping(kind, defaultVersion) if err != nil { <del> return admission.NewForbidden(a, err) </del> <ins> return errors.NewInternalError(err) </ins> } if mapping.Scope.Name() != meta.RESTScopeNameNamespace { return nil

Discussion:
Currently the admission controller returns a forbidden (403) error if the namespace doesn't exist. We should return a 404 error instead.
Change:
configFile = "config/performance-config.yaml" ) <ins> var ( defaultMetrics = []string{ "scheduler_scheduling_algorithm_predicate_evaluation_seconds", "scheduler_scheduling_algorithm_priority_evaluation_seconds", "scheduler_binding_duration_seconds", "scheduler_e2e_scheduling_duration_seconds", } ) </ins> // testCase configures a test case to run the scheduler performance test. Users should be able to // provide this via a YAML file. //

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should allow collecting both default scheduler metrics (Prometheus) and custom metrics easily. At a high level, these collectors should produce a json formatted result which will then be consumed by perf-dash to present in the dashboard. Prometheus metrics We should provide a metrics collector that collects and summarizes default scheduler metrics defined in . To begin with, we can manually pick a list of interesting metrics. Longer term, we could allow configuring the metric list in test definition. already had a PoC . As a reference, is how clusterloader collects scheduler latency metrics. Custom metrics The most important metric is scheduling throughput. is how clusterloader calculates the throughput. We can start with just calculating the average throughput without the percentiles. We may want other custom metrics that are either common to all tests or specific to certain tests. We should allow these custom collectors to be easily and ideally configurable. Why is this needed: Give more insights into scheduler performance. Part of /sig scheduling /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
Change:
// can't delete a target pool that's currently in use by a forwarding rule. // Thus, we have to tear down the forwarding rule if either it or the target // pool needs to be updated. <del> if fwdRuleExists && (fwdRuleNeedsUpdate || tpNeedsUpdate) { </del> <ins> if fwdRuleExists && (fwdRuleNeedsUpdate || tpNeedsRecreation) { </ins> // Begin critical section. If we have to delete the forwarding rule, // and something should fail before we recreate it, don't release the // IP.  That way we can come back to it later.

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 /sig network /area cloudprovider What happened: The cloud provider interface that should . The GCE provider does this for but not for . Every other in-tree provider implements by fully updating the load balancer including updated backend nodes: , , , And the following out-of-tree providers do as well and Oracle (not oss yet). What you expected to happen: I expect that all cloud providers implement by creating or fully updating the load balancer if it already exists. Related discussion: /cc
/assign Make sense to make implementation in GCE consistent with others for the ease of up-coming service controller enhancement. This sounds like a 1.10 task.
is this task blocking you on another attempt at refactoring the service controller sync logic?
yup
Change:
t.Error(err) } } <ins> // Expecting Exists func to throw error if VM deleted _, err = vm.Exists(ctx) if err == nil { t.Error("expected error") } </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 --What happened: We have k8s cluster with version . And I noticed that if I deleted worker node VM from IAAS, then node stuck in state, I created statefulset before and the pod scheduled on that node was stuck in state, and no new pod was created to replace that. Node should be deleted if no instance is found Related log When I check the log of I could see following log keeps popping up. Looks like node_controller noticed that the VM is gone but it doesn't delete the node. Related code here will return if no instance is found. But it should check if it's VM is deleted not shutdown, then return And it should cherry pick this fix avoiding deleting shutdown node What you expected to happen: After VM is deleted, the node should be deleted, pods assigned to the node should be rescheduled to other available nodes How to reproduce it (as minimally and precisely as possible): k8s cluster. In our case we use PKS. workloads on node worker node VM from IAAS Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vSphere Cloud Provider
/sig cloud-provider /sig vmware
Same issue as this one The issue and is cluster API repo. We should fix it inside node_controller in k/k
Hi this issue was found when testing windows cluster deployed using PKS. We do have a workaround by manually deleting node using kubectl. Still we wish the fix could go in ASAP. Could you ask someone from upstream to to review the PR that fix this issue? Thank you
, we will try to push this through for v1.20. 1.19 is approaching code thaw, so we can't push this through
Thanks Michael. I'll let my team know.
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