jiebi/CodeConvo huggingface dataset:
Change:
// AUTO-GENERATED FUNCTIONS START HERE. DO NOT EDIT. var map_IPBlock = map[string]string{ <del> "":       "IPBlock describes a particular CIDR (Ex. "192.168.1.1/24") that is allowed to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should not be included within this rule.", "cidr":   "CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24"", "except": "Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" Except values will be rejected if they are outside the CIDR range", </del> <ins> "":       "IPBlock describes a particular CIDR (Ex. "192.168.1.1/24","2001:db9::/64") that is allowed to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should not be included within this rule.", "cidr":   "CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64"", "except": "Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" Except values will be rejected if they are outside the CIDR range", </ins> } func (IPBlock) SwaggerDoc() map[string]string {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : mentions an IPBlock with only IPv4 examples. Add a comment or example to clarify that IPv6 network blocks are (or possibly aren't) valid here. Why is this needed: Cluster operators who use IPv6 networking want to understand how to isolate different workloads inside their cluster network (and without reading source code). Logged against kubernetes/kubernetes rather than the website repo because this is generated documentation. Kubernetes already has single-stack support for IPv6 clusters KEP for dual-stack support is /sig docs /sig network /priority backlog
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign /remove-triage unresolved can you guide me on what steps are needed to publish the examples?
I via the pull request. (Although I want these examples , it's not a task I'm familiar with).
Change:
} ` <ins> func Test4xxStatusCodeInvalidPatch(t *testing.T) { _, client, closeFn := setup(t) defer closeFn() obj := []byte(`{ "apiVersion": "apps/v1", "kind": "Deployment", "metadata": { "name": "deployment", "labels": {"app": "nginx"} }, "spec": { "selector": { "matchLabels": { "app": "nginx" } }, "template": { "metadata": { "labels": { "app": "nginx" } }, "spec": { "containers": [{ "name":  "nginx", "image": "nginx:latest" }] } } } }`) resp, err := client.CoreV1().RESTClient().Post(). AbsPath("/apis/apps/v1"). Namespace("default"). Resource("deployments"). Body(obj).Do().Get() if err != nil { t.Fatalf("Failed to create object: %v: %v", err, resp) } result := client.CoreV1().RESTClient().Patch(types.MergePatchType). AbsPath("/apis/apps/v1"). Namespace("default"). Resource("deployments"). Name("deployment"). Body([]byte(`{"metadata":{"annotations":{"foo":["bar"]}}}`)).Do() var statusCode int result.StatusCode(&statusCode) if statusCode != 422 { t.Fatalf("Expected status code to be 422, got %v (%#v)", statusCode, result) } result = client.CoreV1().RESTClient().Patch(types.StrategicMergePatchType). AbsPath("/apis/apps/v1"). Namespace("default"). Resource("deployments"). Name("deployment"). Body([]byte(`{"metadata":{"annotations":{"foo":["bar"]}}}`)).Do() result.StatusCode(&statusCode) if statusCode != 422 { t.Fatalf("Expected status code to be 422, got %v (%#v)", statusCode, result) } } </ins> // Tests that the apiserver returns 202 status code as expected. func Test202StatusCode(t *testing.T) { s, clientSet, closeFn := setup(t)

Discussion:
/kind bug /sig api-machinery /cc What happened: patching (SMP) any object's annotation using invalid patch content will result in an (500) internal-server error. expecting a (400) bad-request error in this case. patch body: received error: the error is thrown from converter instead of the patcher, so it seems that patcher considers the body as valid then the converter complained. Anything else we need to know?: when my grandpa was 65 years old he started running one mile a day to keep fit. he's 70 now and we have no idea where he is.
I just tried the same patch with "MergePatchType", and it also fails with 500.
I can't make it fail with JSONPatchType, I get a 422
I suspect the error should read "the server rejected your request due to an error in our request"
Change:
"k8s.io/klog" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/types" utilversion "k8s.io/apimachinery/pkg/util/version" "k8s.io/apimachinery/pkg/util/wait"

Discussion:
What happened: Network services with heavy load will cause "connection reset" from time to time. Especially those with big payloads. When packets with sequence number out-of-window arrived k8s node, conntrack marked them as INVALID. kube-proxy will ignore them, without rewriting DNAT. The packet goes back the the original pod, who doesn't recognize the packet because of the wrong source ip, end up RSTing the connection. What you expected to happen: connection not reset How to reproduce it (as minimally and precisely as possible): wrote this just to reproduce the issue: Basically run it in a cluster, and after a while you will be able to see "Connection reset by peer" on both server and client pods. Anything else we need to know?: Related issue: Environment: Kubernetes version (use ): 1.11.7 Cloud provider or hardware configuration: gke (should be general to all provider) OS (e.g: ): PRETTYNAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSIONID="9" VERSION="9 (stretch)" ID=debian HOMEURL="" SUPPORTURL="" BUGREPORTURL="" Kernel (e.g. ): Linux gke-cluster-1-11-default-pool--6nzv 4.14.89+ SMP Wed Jan 9 13:35:00 PST 2019 x86_64 GNU/Linux
/sig network
I created a small app to reproduce this issue:
I've been hitting this exact problem for packets between a Pod and the outside world. So the DROP rule has to go into the INPUT chain. Would that be a job for a CNI driver or the kube-proxy?
was put to iptables mode but not to , right? Isn't ipvs mode affected by this issue, too?
Can anyone point me out how netfilter ignore this STATE invalid packet? I checked the code in netfilter for function iptablenatdo_chain, but didn't find the code that handles the STATE=invalid packet. Thanks for help.
Invalid is connection tracking state. My understanding is: If for some reason conntrack doesn't think it's the packet is "tracked" it could be grouped into "invalid" state. The problem is once it happens, .
ipvs should be fine. do you see similar issue in ipvs?
I also encountered this problem.

Have you solved it
is this a similar issue for ipvs?
The error is a very general networking issue, which could be caused by many different reasons. This specific cause can be reproduced by the It looks like you got an answer already there :)
Change:
ResourceVersion string `json:"resourceVersion,omitempty"` // Optional. If referring to a piece of an object instead of an entire object, this string <del> // should contain a valid field access statement. For example, // if the object reference is to a container within a pod, this would take on a value like: // "desiredState.manifest.containers[2]". Such statements are valid language constructs in // both go and JavaScript. This is syntax is chosen only to have some well-defined way of </del> <ins> // should contain information to identify the sub-object. For example, if the object // reference is to a container within a pod, this would take on a value like: // "spec.containers{name}" (where "name" refers to the name of the container that triggered // the event) or if no container name is specified "spec.containers[2]" (container with // index 2 in this pod). This syntax is chosen only to have some well-defined way of </ins> // referencing a part of an object. // TODO: this design is not final and this field is subject to change in the future. FieldPath string `json:"fieldPath,omitempty"`

Discussion:
Forked from ... The event generated from kubelet for BoundPod and displayed by kubectl should have Container(s) column ; otherwise, the user might think the entire pod is at the running state, but actually only one or some containers are running. When there are missing event(s) for failed containers, the thing gets worse. For example, in case, only net container is running. $ get events | grep testpd Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get events Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting created Created with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004 Mon, 29 Dec 2014 20:58:38 +0000 testpd Pod Pending scheduled Successfully assigned testpd to kubernetes-minion- Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting pulled Successfully pulled image kubernetes/pause:latest Mon, 29 Dec 2014 20:58:39 +0000 testpd BoundPod running started Started with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004
Change:
} func TestValidateCustomResourceDefinitionValidationRuleCompatibility(t *testing.T) { <del> allValidationsErrors := []validationMatch{ </del> <ins> allRuleValidationsErrors := []validationMatch{ </ins> invalid("spec", "validation", "openAPIV3Schema", "properties[x]", "x-kubernetes-validations[0]", "rule"), invalid("spec", "validation", "openAPIV3Schema", "properties[obj]", "x-kubernetes-validations[0]", "rule"), invalid("spec", "validation", "openAPIV3Schema", "properties[obj]", "properties[a]", "x-kubernetes-validations[0]", "rule"),

Discussion:
Noticed a copy & paste issue when reading through the CEL code. Basically here: This should be instead of: The impact of this issue should be that messageExpressions are always evaluated with the CEL environment of the compatibility version. But stored (i.e. pre-existing) messageExpressions should be evaluated with a CEL environment with the "max" version instead. For users of Kubernetes this means that messageExpressions deployed with one minor version of Kubernetes might not work anymore if they rollback e.g. by one minor version. messageExpressions should be treated the same way as rules in that regard. Deploy Kubernetes 1.30 Deploy CRD that uses messageExpression that is using Sets (which became available with Kubernetes 1.30 that is using compatibilty version 1.29) Rollback to Kubernetes 1.29 Update something in the CRD =CRD update will fail because messageExpression is evaluated with the wrong CEL environment (it should still work) No response <detailsAt least on Kubernetes main, but I would assume this isuse is there since CEL was implemented </details<details</details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This 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
cc Will open a PR in a bit
Change:
}} } <del> func podAddressChanged(oldPod, newPod *v1.Pod) bool { </del> <ins> func podChanged(oldPod, newPod *v1.Pod) bool { // If the pod's readiness has changed, the associated endpoint address // will move from the unready endpoints set to the ready endpoints. // So for the purposes of an endpoint, a readiness change on a pod // means we have a changed pod. if podutil.IsPodReady(oldPod) != podutil.IsPodReady(newPod) { return true } </ins> // Convert the pod to an EndpointAddress, clear inert fields, // and see if they are the same. newEndpointAddress := podToEndpointAddress(newPod)

Discussion:
This test has started failing on our e2e test suite, erroring out with "Failed to get endpoints..." https://k8s- https://k8s- Example failures https://k8s- https://k8s- cc cc
This may be related to our recently-merged endpoints change in . I'll look into it.
I verified that the flakiness introduced was a result of . A fix in should be merging soon. /assign
GitHub didn't allow me to assign the following users: joelsmith. Note that only can be assigned. <detailsIn response to : I verified that the flakiness introduced was a result of . A fix in should be merging soon. /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
Change:
func gvkP(g, v, k string) *schema.GroupVersionKind { return &schema.GroupVersionKind{Group: g, Version: v, Kind: k} } <ins> func gvk(g, v, k string) schema.GroupVersionKind { return schema.GroupVersionKind{Group: g, Version: v, Kind: k} } </ins>

Discussion:
Improve the to ensure that the expected storage version for a resource is one understood by previous releases. We have API testdata from prior versions available in When checking each group/version/kind in the test: accumulate all the versions of the group/kind available in previous (non-HEAD) releases if there is a beta or stable version of the group/kind available in previous releases, then the storage version must be in the set of previously available versions It is too easy to accidentally change the storage version prematurely and edit the test/integration/etcd test to match the bug cc
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This 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
Change:
func (w ConditionalWait) IsConditionMet(info *resource.Info, o *WaitOptions) (runtime.Object, bool, error) { endTime := time.Now().Add(o.Timeout) for { <ins> if len(info.Name) == 0 { return info.Object, false, fmt.Errorf("resource name must be provided") } </ins> resourceVersion := "" gottenObj, err := o.DynamicClient.Resource(info.Mapping.Resource).Namespace(info.Namespace).Get(info.Name, metav1.GetOptions{}) switch {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: I created a job with metadata.generateName twice and waited for completion, but got: panic: interface conversion: runtime.Object is unstructured.UnstructuredList, not unstructured.Unstructured What you expected to happen: kubectl to wait for the last job to complete. How to reproduce it (as minimally and precisely as possible): kubectl create -f kubectl create -f kubectl wait --for=condition=complete -f (shortened): apiVersion: batch/v1 kind: Job metadata: generateName: my-job- Anything else we need to know?: Environment: Kubernetes version (use ): 1.11.3 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I have to choose a sig, but I am not sure which one is right...
Reiterating the mentions to trigger a notification: <detailsIn response to : I have to choose a sig, but I am not sure which one is right... 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
/sig cli /sig apps
/assign
kubectl get -f also doesn't work as expected.
/remove-sig apps
Change:
// awsRegions is a set of recognized regions var awsRegions sets.String <del> // RecognizeRegion is called for each AWS region we know about. </del> <ins> // recognizeRegion is called for each AWS region we know about. </ins> // It currently registers a credential provider for that region. // There are two paths to discovering a region: //  * we hard-code some well-known regions //  * if a region is discovered from instance metadata, we add that <del> func RecognizeRegion(region string) { </del> <ins> func recognizeRegion(region string) { </ins> awsRegionsMutex.Lock() defer awsRegionsMutex.Unlock()

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: From /kind cleanup What happened: What you expected to happen: 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:
/sig cloud-provider /assign
Change:
func (d *dummyStorage) Count(_ string) (int64, error) { return 0, fmt.Errorf("unimplemented") } <ins> func (d *dummyStorage) injectError(err error) { d.Lock() defer d.Unlock() d.err = err } </ins> func TestGetListCacheBypass(t *testing.T) { backingStorage := &dummyStorage{}

Discussion:
As Jordan pointed out in: watchcache treats RV=0 and RV="" the same way, even though it's not what we document: This should be fixed. /kind bug /sig api-machinery /priority important-soon
/assign
/triage accepted
Change:
err := p.Start() require.NoError(t, err) <del> e, err := newEndpointImpl(socket, "mock", make(map[string]pluginapi.Device), func(n string, a, u, r []pluginapi.Device) {}) </del> <ins> e, err := newEndpointImpl(socket, resourceName, make(map[string]pluginapi.Device), callback) </ins> require.NoError(t, err) return p, e

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:
func (pc *metricsCollector) collect() []DataItem { var dataItems []DataItem for _, metric := range pc.Metrics { <del> dataItem := collectHistogram(metric, pc.labels) </del> <ins> dataItem := collectHistogramVec(metric, pc.labels) </ins> if dataItem != nil { dataItems = append(dataItems, *dataItem) }

Discussion:
The new scheduler performance test was introduced back in 1.18, back then, the metric it supported are all . However, along with , some metrics are updated to be , and hence it's no longer appropriate to return the first Histogram: However, it's very common (for instance Preemption) that the metrics may hold multiple histograms: Additionally, metrics and have been removed, we should update them to : /sig scheduling
/triage accepted /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
Change:
"//pkg/api/validation:go_default_library", "//pkg/apis/policy:go_default_library", "//pkg/client/clientset_generated/internalclientset/typed/policy/internalversion:go_default_library", <ins> "//pkg/client/retry:go_default_library", </ins> "//pkg/kubelet/client:go_default_library", "//pkg/labels:go_default_library", "//pkg/registry/cachesize:go_default_library",

Discussion:
What happened: When I try to test after implementing the 1st approach according to , I found pod disruption budgets cannot handle concurrent requests. The error message is: It is an Optimistic Lock error message. It means PDB can't handle concurrent requests. How to reproduce it (as minimally and precisely as possible): 1) Create a deployment with 6 replicas and schedule them to the same node, say node A. You can leave only one node scheduling enabled, and then create the deployment. 2) Create the PDB that match the deployment's label 3) Uncordon another node, say node B 4) Drain node A using concurrent POST eviction requests. Ref: I'm not sure if this behavior is OK for PDB. I think I can make work by waiting for a while if current pod label(s) match previous pod label(s).
Oh, that's interesting. I think the problem is that this function doesn't retry if UpdateStatus() fails due to version conflict. I think the solution is to modify the caller, i.e. this function so that instead of just it instead does something like This will loop re-doing checkAndDecrement() and getPodDisruptionBudgets() until checkAndDecrement() succeeds, or fails with a non-conflict error. Does that make sense? cc/ for sanity check
Or use PATCH?
Yes, PATCH should work also. I haven't written code that uses PATCH, so I can't advise exactly the code to write here (there are examples by grepping for patch, but I'm not sure exactly what is the right way to do it from inside of API server code, which is where we are here). can you do a PR to implement this, either using the approach I described above or using PATCH? I think this is important to get into 1.5.
I think PATCH may NOT be safe here. For example: 1) current pdb 2) creating eviction A: get 3) creating eviction B: get 4) creating eviction A: PATCH pdb 5) creating eviction B: PATCH pdb 6) pdb's . It's wrong. Retry loop make more sense to me.
Good point! You're right. Retry loop should be OK.
I can help to create a PR using retry loop.

Could you please triage this for 1.5 and apply blocker or non-blocker labels as appropriate along with priority.
Done.
who is actually working on this issue? Could one of you set yourselves as an assignee for this issue? Thanks! cc:
retry logic with PR needs reviews/lgtm