jiebi/CodeConvo huggingface dataset:
Change:
if volumeQty.Cmp(requestedQty) < 0 { continue } <ins> // If PV node affinity is invalid, return no match. // This means the prebound PV (and therefore PVC) // is not suitable for this node. if !nodeAffinityValid { return nil, nil } </ins> return volume, 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?: /assign What happened: Volume got bound to PV on node "kubernetes-minion-group-82c8" When the pod went back through scheduling, the predicate returned success for other nodes even though we should have updated the PV cache to point to the PVC: I think in , instead of continuing if the node affinity doesn't match, it should fail if the PV is prebound.
This causes two issues: On the second pass, the scheduler may choose a different node. Then in Assume/Bind volumes, we'll also prebind a second set of PVs. If the scheduler chose a different node on the second pass, and the PVCs became fully bound in between the predicates and assume volumes, then assume volumes will return success and the pod will get scheduled to the wrong node.
Change:
f, tf, codec, _ := NewAPIFactory() ns := dynamic.ContentConfig().NegotiatedSerializer tf.Printer = &testPrinter{} <ins> deleted := false </ins> tf.Client = &fake.RESTClient{ NegotiatedSerializer: ns, Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { switch p, m := req.URL.Path, req.Method; { <del> case p == "/namespaces/test/replicationcontrollers/redis-master" && (m == http.MethodGet || m == http.MethodPut || m == http.MethodDelete): </del> <ins> case p == "/namespaces/test/replicationcontrollers/redis-master" && m == http.MethodDelete: deleted = true fallthrough case p == "/namespaces/test/replicationcontrollers/redis-master" && m == http.MethodPut: </ins> return &http.Response{StatusCode: http.StatusOK, Header: defaultHeader(), Body: objBody(codec, &rc.Items[0])}, nil <ins> case p == "/namespaces/test/replicationcontrollers/redis-master" && m == http.MethodGet: statusCode := http.StatusOK if deleted { statusCode = http.StatusNotFound } return &http.Response{StatusCode: statusCode, Header: defaultHeader(), Body: objBody(codec, &rc.Items[0])}, nil </ins> case p == "/namespaces/test/replicationcontrollers" && m == http.MethodPost: return &http.Response{StatusCode: http.StatusCreated, Header: defaultHeader(), Body: objBody(codec, &rc.Items[0])}, nil default:

Discussion:
When replacing an existing pod, the command fails as it tries to create a pod with a name that is still used by terminating pod. How does the option works? deletes a pod (e.g. mypod) creates a new pod with the same name (mypod) What happens? As the command tries to recreate the pod, it fails as the is in state. Thus it can not be created. The problem is the does not wait for a pod to be deleted. Reproducer: run mypod --image=yapei/hello-openshift --generator=run-pod/v1 get pod mypod -o yaml replace -f --force The last command ends with:
option introduce by
With set to positive value, what should be the default behaviour of the command? When set to , should the command hang for and then create the pod? Or is there a way to create a callback (inside a scheduler?) that creates the pod once the current one is deleted?
You could watch for the resource to be deleted and create after you see the deletion happen
have you ever tried to set , I think this will do a non graceful deletion. should make sure the old resource is deleted before it creates a new resource, if not, that's a bug.
Though the help says the is to be used only with , it returns the error above.
Then I think there are two issues we need to track: 1. option should be ignored or just returns error if users are not using option. 2. should always make sure the old resource has been deleted before create the new resource.
Change:
"kernelcheck_unsupported.go", ], importpath = "k8s.io/kubernetes/pkg/util/ipvs", <del> deps = select({ "@io_bazel_rules_go//go/platform:android": [ "//vendor/k8s.io/utils/exec:go_default_library", ], "@io_bazel_rules_go//go/platform:darwin": [ "//vendor/k8s.io/utils/exec:go_default_library", ], "@io_bazel_rules_go//go/platform:dragonfly": [ "//vendor/k8s.io/utils/exec:go_default_library", ], "@io_bazel_rules_go//go/platform:freebsd": [ "//vendor/k8s.io/utils/exec:go_default_library", ], </del> <ins> deps = [ "//staging/src/k8s.io/apimachinery/pkg/util/version:go_default_library", "//vendor/k8s.io/utils/exec:go_default_library", ] + select({ </ins> "@io_bazel_rules_go//go/platform:linux": [ "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//vendor/github.com/docker/libnetwork/ipvs:go_default_library", "//vendor/github.com/golang/glog:go_default_library", <del> "//vendor/k8s.io/utils/exec:go_default_library", ], "@io_bazel_rules_go//go/platform:nacl": [ "//vendor/k8s.io/utils/exec:go_default_library", ], "@io_bazel_rules_go//go/platform:netbsd": [ "//vendor/k8s.io/utils/exec:go_default_library", ], "@io_bazel_rules_go//go/platform:openbsd": [ "//vendor/k8s.io/utils/exec:go_default_library", ], "@io_bazel_rules_go//go/platform:plan9": [ "//vendor/k8s.io/utils/exec:go_default_library", ], "@io_bazel_rules_go//go/platform:solaris": [ "//vendor/k8s.io/utils/exec:go_default_library", ], "@io_bazel_rules_go//go/platform:windows": [ "//vendor/k8s.io/utils/exec:go_default_library", </del> ], "//conditions:default": [], }),

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:
return nil, err } <ins> subnetCidrs, err := c.getSubnetCidrs(subnetIDs) if err != nil { klog.Errorf("Error getting subnet cidrs: %q", err) return nil, err } </ins> sourceRangeCidrs := []string{} for cidr := range sourceRanges { sourceRangeCidrs = append(sourceRangeCidrs, cidr)

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: For each NLB created, K8s creates an ingress rule on the node group's security group for each port exposed for each CIDR attached to the VPC to allow health checks to succeed. AWS limits the number of rules per security group to 60 by default. This quota is adjustable but multiplied by the quota for security groups per network interface cannot exceed 1000. I have a VPC with 16 CIDR blocks attached to it and a quota for rules per security group set to 80. Each NLB created adds 18 new rules (16 for Health Check, 1 for Client, and 1 for MTU) to the node group's security groups. This high number of unnecessary rules created makes it impossible to create more than 4 NLBs per node group (if each one has a single port exposed). What you expected to happen: For the health check to succeed, the NLB must be able to ping the node port for the service on the cluster's node group. So the node group's security group just needs an inbound rule for each ENI of the NLB, making the number of rules necessary on the cluster's node group directly proportional to the number of AZs the NLB is configured. How to reproduce it (as minimally and precisely as possible): Create a VPC on AWS with 8 CIDRs attached to it; Create a K8s Cluster; Create a Network Load Balancer with 6 ports exposed; If the default quota of rules per security group has not been changed, the NLB creation will fail with RulesPerSecurityGroupLimitExceeded. Anything else we need to know?: 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:
/sig cloud-provider
/area provider/aws
Change:
return "", err } <del> // Clear any existing mount reference from the API.  These may be leftover // from previous mounts where the unmount operation couldn't get access to // the API credentials. if vol.Mounted { opts := storageostypes.VolumeUnmountOptions{ Name:      vol.Name, Namespace: vol.Namespace, } if err := u.api.VolumeUnmount(opts); err != nil { klog.Warningf("Couldn't clear existing StorageOS mount reference: %v", err) } } </del> srcPath := filepath.Join(b.deviceDir, vol.ID) dt, err := pathDeviceType(srcPath) if err != nil {

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: When a PVC is created and the PV mounted into a Pod using the StorageOS in-tree volume driver, the StorageOS CLI & UI do not report that the volume is mounted. The PV is created and mounted into the Pod successfully, and all k8s functionality works as expected. However, since the correct mount status is not visible to administrators using the StorageOS UI or CLI, they may make changes to or delete a mounted volume without realising, and the safeguards (must use to delete a mounted volume) do not trigger. This is a regression caused by , released in 1.14.0. What you expected to happen: The StorageOS CLI should report volume mount information (node name, mount timestamp). How to reproduce it (as minimally and precisely as possible): StorageOS node containers with CSI disabled: application Pod with a PVC using the StorageOS StorageClass: StorageOS to list volumes: Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.0 and later Cloud provider or hardware configuration: any OS (e.g: ): any linux (incl. Ubuntu 18.04) Kernel (e.g. ): any linux (incl. 4.15.0-33-generic) Install tools: any (incl. minikube) Network plugin and version (if this is a network-related bug): N/A Others: Requires StorageOS deployment /sig storage /assign
Change:
options.Limit = p.PageSize } requestedResourceVersion := options.ResourceVersion <ins> requestedResourceVersionMatch := options.ResourceVersionMatch </ins> var list *metainternalversion.List paginatedResult := false

Discussion:
We recently started using the list pager from client-go as part of Calico, and have seen reports of the following error showing up: No error, just beautiful paged list calls. Create 1,000 resources of a particular type, such as a NetworkPolicy. (Need 500 to trigger paging) Do a of all those resources with set. Originally filed here (but maybe that repo is not monitored): Reference issue in Calico: projectcalico/calico (comment) Reference Calico list pager code: We think this is the required fix: <detailsclient-go version (but bug seems to be in master too). </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/triage accepted
Change:
legacyregistry.MustRegister(metric) } volumeschedulingmetrics.RegisterVolumeSchedulingMetrics() <ins> PodScheduleSuccesses = scheduleAttempts.With(metrics.Labels{"result": "scheduled"}) PodScheduleFailures = scheduleAttempts.With(metrics.Labels{"result": "unschedulable"}) PodScheduleErrors = scheduleAttempts.With(metrics.Labels{"result": "error"}) </ins> }) }

Discussion:
What happened: two scheduler metrics, and , was not recorded in . scheduler has some code for this already. It seems to be a bug. What you expected to happen: and was recorded How to reproduce it (as minimally and precisely as possible): /king bug /sig scheduling
/assign
What do you expect for ? And I think pending pods are available in metrics, but not from scheduler. You can get it from pods info metrics.
actually, scheduler has some code already for recording these metrics. But I found a bug in these code. I will post my PR to fix this issue soon. // I updated the issue description for clarifying.
Change:
and best practices, and to refresh command syntax, output, changed prerequisites, as needed. <del> Name | Description | Notable Features Used | Complexity Level ------------- | ------------- | ------------ | ------------ | ------------ [Guestbook](guestbook/) | PHP app with Redis | Replication Controller, Service | Beginner [WordPress](mysql-wordpress-pd/) | WordPress with MySQL | Deployment, Persistent Volume with Claim | Beginner [Cassandra](storage/cassandra/) | Cloud Native Cassandra | Daemon Set | Intermediate </del> <ins> |Name | Description | Notable Features Used | Complexity Level| ------------- | ------------- | ------------ | ------------ | |[Guestbook](guestbook/) | PHP app with Redis | Replication Controller, Service | Beginner | |[WordPress](mysql-wordpress-pd/) | WordPress with MySQL | Deployment, Persistent Volume with Claim | Beginner| |[Cassandra](storage/cassandra/) | Cloud Native Cassandra | Daemon Set | Intermediate </ins> <del> Note: Please add examples to the list above that are maintained. </del> <ins> * Note: Please add examples to the list above that are maintained. </ins> See [Example Guidelines](guidelines.md) for a description of what goes in this directory, and what examples should contain.

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): If this is a BUG REPORT, please: The table in the readme for /examples is broken. What happened: The table in the readme for /examples is broken. How to reproduce it (as minimally and precisely as possible): can be updated
Closing this issue as has merged.
Change:
} if zones, ok := cnc.cloud.Zones(); ok { <del> zone, err := getZoneByProviderIDOrName(ctx, zones, node) </del> <ins> zone, err := getZoneByProviderIDOrName(ctx, zones, providerID, node.Name) </ins> if err != nil { return nil, fmt.Errorf("failed to get zone from cloud provider: %v", err) }

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: introduces a regression that func is invoked on a Node obj without , hence it can fail fetching the node addresses when the is not set. What you expected to happen: I would expect cloud-controller-manager to be able to initialize new Node. How to reproduce it (as minimally and precisely as possible): the gcp legacy-cloud-controller v1.18.1 () that the node-controller cannot initialize a new Node. Logs of the cloud-controller-manager repeated multiple times: Ensure that the Node is with the taint. Ensure that the of the Node is not set. The cloud-controller-manager is not running on the host machine and that's why it cannot call the gce matadata. But it was never a hard requirement for cloud-controller-manager to run on the host machine. Anything else we need to know?: The legacy cloud-controller-manager v1.17.x is working perfectly fine. Environment: Kubernetes version (use ):v1.18.1 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:
/sig cloud-provider /kind regression
/cc
can we open a new issue re:
Change:
handler = genericapifilters.WithAuditAnnotations(handler, c.AuditBackend, c.AuditPolicyChecker) handler = genericapifilters.WithWarningRecorder(handler) handler = genericapifilters.WithCacheControl(handler) <ins> handler = genericfilters.WithHSTS(handler, c.HSTSDirectives) </ins> handler = genericapifilters.WithRequestReceivedTimestamp(handler) handler = genericfilters.WithPanicRecovery(handler, c.RequestInfoResolver) return handler

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add the "Strict-Transport-Security" header to the API server responses. Why is this needed: Nessus scanner treats this as a Medium Risk in kubernetes 1.18.10.
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 api-machinery
/remove-sig api-machinery /sig auth
Change:
// whether or not a container name was given via --container ContainerNameSpecified bool <del> Interactive            bool </del> Selector               string Object           runtime.Object

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: says: What you expected to happen: Don't suggest that -- as it doesn't actually do that when used. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: (This was reported in but that issue was closed) Environment: Kubernetes version (use ): (This is indeed head from today) Cloud provider or hardware configuration: macOS OS (e.g. from /etc/os-release): Kernel (e.g. ):Install tools:Others:
/sig cli
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:
kube::log::status "Updating " "${OPENAPI_ROOT_DIR}" <del> curl -w "n" -kfs --oauth2-bearer dummy_token "https://${API_HOST}:${API_PORT}/openapi/v2" | jq -S '.info.version="unversioned"' > "${OPENAPI_ROOT_DIR}/swagger.json" </del> <ins> curl -w "n" -kfsS -H 'Authorization: Bearer dummy_token' "https://${API_HOST}:${API_PORT}/openapi/v2" | jq -S '.info.version="unversioned"' > "${OPENAPI_ROOT_DIR}/swagger.json" </ins> kube::log::status "SUCCESS"

Discussion:
What happened: After running ./hack/update-openapi- with the latest code, api/openapi- file became empty even when no changes were made in the code. What you expected to happen: After running ./hack/update-openapi- with the latest code, api/openapi- file should not be changed when no changes were made in the code. When I tried the same thing a few week back, I didn't encounter this problem. How to reproduce it (as minimally and precisely as possible): Download the latest kubernetes/kubernetes code and run the following script to update openapi spec. api/openapi- became empty after this. Anything else we need to know?: There's a line in update-openapi- that runs a curl command . This line was changed a few days ago by this commit: PR: I checked out the commit before and ran /update-openapi- It works. is not empty any more. Is there any new setting required before running ./hack/update-openapi- now? 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:
/sig api-machinery
cc
Hi, thanks for the report, but it is a bit weird that I could not reproduce locally: and besides, completes successfully on my machine. Could you reproduce?
Someone else also ran into this same problem and asked a question on sig-api-machinery slack yesterday. So I'm not the only one who ran into this.
could you change the args passed to curl in to and rerun the script to see if there is any error?
since it is already late here(UTC+8), I would check this issue again tomorrow
I was the "someone else" who ran into this problem :) I changed the script to use The result: Actually, it was 403 without the "S", too, but that is visible only if curl is executed in verbose mode.
Hi, thanks for your information. Given that the apiserver returned 403, I suspect the flag passed to curl has no effect in your environment, would you mind posting the output of ? I am using curl 7.64.1: In addition, I think you could try changing the curl command in to the following: and see if the problem is solved.

I tried the following and it worked for me. is no longer empty. curl version:
Thanks for your confirmation, and I have filed to address this issue.
I can confirm, it works with the changed curl command.
/triage accepted
Change:
imageutils "k8s.io/kubernetes/test/utils/image" ) <ins> // secondNodePortSvcName is the name of the secondary node port service const secondNodePortSvcName = "second-node-port-service" </ins> var ( // agnHostImage is the image URI of AgnHost agnHostImage = imageutils.GetE2EImage(imageutils.Agnhost)

Discussion:
What happened: indicates that we're missing an e2e test for. This specific issue is just a tracker to create a new E2E test that demonstrated .
/sig network
/assign
btw, should this be a part of conformance?
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
I can start working on this.
Sure/ are you working full time on it ? If so I'll drop the issue from my work ... Otherwise we can collaborate as I already have some code for this. Let me know. Was hoping to have this done in the next week or so.
I would love to collaborate, especially if you already have some code. But if you want to drop this from your work, I don't mind taking it on full time either. I can pick up from where ever you left off.
ok, if youve got full bandwidth go for it. if make progress on it this wk ill just drop it . I actually dont know where my old branch is for this :), so i guess youll have to start from scratch. One thing to note ~ Might be seeing if any tests can be reused for this or extended in a simple way by just adding a secondary service, rather then writing a full blown test from scratch. Let me know how it goes thanks !
I will let you know how it progresses. Thanks !
thanks for getting this taken care of :) looks like the PR is LGTM.
Thanks for letting me take a stab at it!