jiebi/CodeConvo huggingface dataset:
Change:
// // Enable resource limits priority function ResourceLimitsPriorityFunction utilfeature.Feature = "ResourceLimitsPriorityFunction" <ins> // owner: @m1093782566 // beta: v1.9 // // Implement IPVS-based in-cluster service load balancing SupportIPVSProxyMode utilfeature.Feature = "SupportIPVSProxyMode" </ins> ) func init() {

Discussion:
There are some work to be done in the follow-up of , that is, help IPVS existing alpha. [x] GCE CI failures()[x] cross-node visit NodePort ()[x] hairpin issue ()[x] Using ipset doing snat and packet filtering and reduce iptables call().[x] automatically load kernel modules. (, )[x] creating e2e test suite for IPVS in upstream CI ().[x] ip cmd -netlink bind/unbind IP address to/from dummy device()[x] rsync to HEAD of iptables(, )[x] enable flush batch API()[x] Fix TODOs in codes ()[x] Bug report (, )[x] Default sync period()[x] IPV6 support(, and more...) /cc
/cc
ref ! It will generate annoy error info If unbind multi-ports on one service .
You're right. I think it's a nice finding. Can you fire a PR to fix it?
Sure, I'll make it soon.
I found it is treated as already bound if returned 2 in , but ref to the and of ip , it just means an error was reported by the kernel, such as "Operation not permitted". I prefer to use instead of command to manage ip address.
Actually, I have considered to use netlink before. I think what you said make sense, but can we discuss it in other thread? I mean, create a new issue and link it here? Thanks!
I opened a issue
on the subject :)
OOPS... I will fix that typo. Thanks
Wish to use ipset to replace KUBE-MARK-MASQ chain.
I find it's a reasonable suggestion and am trying to make it workable...
There are to ways to add IPVS CI job: , but doesn't support any kube-proxy config right now, so I had this pr , and also, need support it too, see this pr: kubernetes/kubernetes-anywhere build cluster. See this pr: kubernetes/test-infra The second way is much easier and faster, but I was told they gonna deprecated the , so in the long term, we still need and 's support. If anybody have better way or have some suggestion about this, please let me know, I'll be really appreciate, Thanks.
This one is done as both PRs are merged:
ACK!

/area ipvs
We are almost reaching the beta, except GCE CI failures, see The failure is the case that, visiting Cluster IP from Pod A, and the backend Pod B is in the same host with the Pod A. Pod A failed to get response from Pod B until timeout. I can reproduce the failures in my GCE cluster with kubent as network plugin, but it works fine in my local-up cluster and people has never reported the issue yet. and I are digging...
IPVS CI is green now.
Change:
"reflect" "strings" "testing" <ins> "time" </ins> utilexec "k8s.io/utils/exec" testexec "k8s.io/utils/exec/testing"

Discussion:
A status of Pod mounted NFS PV remain as terminating when a node shutdown and restart. A Pod is completely terminated. Deploy a Pod mounted NFS PV Shutdown the node where the Pod is running Wait for 5 min and the Pod status become Restart the node The Pod status is still and the Pod is never terminated completely <detailsPrepare a NFS Server.(I used ) Deploy a Pod mounted NFS PV like this. Shutdown the node where the Pod is running.(In this case ) And the status of node02 becomes . After 5 min later(by default), the Pod status becomes . (The time a Pod becomes status depends on .) Then, restart the node and the status of node02 becomes . But the Pod status is still and the Pod is never terminated completely. It seems that a faild to delete Pod because of trying to unmount a not mounted directory. Force delete Pod. Delete Pod's directory on the node. </detailsNo response <details</details<detailsnone(on premise) </details<details</details<details</details<details</details<details</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
/sig storage
/sig node
It dose not happen using , so it seems to depend on NFS volume plugin.
/assign
I try to build and run kubelet with comment out this logic. Then it seems to get well. related: This change checks the result of instead of the mount point check. However, check logic is not implemented in and (these functions are used in NFS volume plugin), despite it is done in .
/remove-sig node /sig storage
Reopening, fix had to be reverted due to unit tests requiring root permissions ()
I am terribly sorry... Please wait a moment. I'll try to fix it.
no worries, just get to review the rework, making sure the units tests don't require root permissions
Thank you! Fixed in .
Are there any plans to backport this to older Kubernetes versions? This seems like a critical fix.
Change:
// is a mountpoint. // It should return ErrNotExist when the directory does not exist. // IsLikelyNotMountPoint does NOT properly detect all mountpoint types <del> // most notably linux bind mounts. </del> <ins> // most notably linux bind mounts and symbolic link. </ins> IsLikelyNotMountPoint(file string) (bool, error) // DeviceOpened determines if the device is in use elsewhere // on the system, i.e. still mounted.

Discussion:
What happened: I realized csi local driver with the function of IsLikelyNotMountPoint in kubernetes pkg/util/mount library. The function as follows: We notice that If i use the symbolic link filepath, it will return false which cause the error to umount after this function. What you expected to happen: return true How to reproduce it (as minimally and precisely as possible): A directory link A to someone device the function with symbolic link Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 OS (e.g: ): centos Kernel (e.g. ): Linux 3.10.0-862.3.2.el7.x8664 SMP Mon May 21 23:36:36 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: yum
/sig storage
Change:
Err           error Calls         []string IP            net.IP <del> ExtID         string </del> <ins> ExtID         map[string]string </ins> Machines      []string NodeResources *api.NodeResources ClusterList   []string

Discussion:
I see the following in the kube-controller-manager log: - This is happening to me on HEAD and is the reason why pod status is always showing unknown even when they are scheduled and running.
This is with the vagrant cloud provider. It looks like the delta between the new and old minion is the Node.Spec.ExternalID is being set on the incoming minion but is not set in the originally created minion.
I am not sure how this is not affecting other cloud providers. It looks to me that NodeController populated the node ExternalID here: It looks like the Kubelet provided value is missing the ExternalID
Actually, I am now confused on what the NodeController may or may not be doing here that is causing the status to not get updated.
It looks like the client is passing an ExternalID on the incoming request, but the original value that is in etcd does not have an ExternalID set. Not sure what changed that would have caused this issue to appear.
I think this causes problems: The memory is re-used in a for-loop by Go so referring to a pointer value in a map here will cause problems I think.
Ok, the referenced line is the problem. Sending a PR.
Well, I go back on that now. A simple way to reproduce this is to delete all the minions in your cluster, and verify the node controller is able to add them back. For me, this is causing the node controller to add them back in an unknown status, and then all updates to the node fail. The update fails because the node controller is not setting an ExternalID on the original object.
I am looking into this now. cc/ too
Related issue opened while debugging this:
Debugged through here: I can via manual fmt see that the object has an ExternalID set prior to the call Create. When I look at etcd, I end up with this persisted: Note: it is missing an ExternalID somehow ;-)
Ok, I think I see the issue Nodes returned from here: Do not have an ExternalID Which can make Nodes created from here: End up without an External ID. Having two different nodeClient.Create() paths in this code is confusing. Also we are doing bad things in maps holding pointers to memory allocated in for-loop. We need to fix that ;-)
Yeah, this is bug we should fix. Thanks for looking into this.

If you already have a potential fix, please feel free to grab the issue from me.
I think I have a PR that should fix. Testing that now. Will cc you on the PR.
Thanks for fixing - it did end up affecting AWS as well (AWS isn't in a fully working state just yet, particularly with node discovery).
Change:
"//staging/src/k8s.io/api/policy/v1beta1:go_default_library", "//staging/src/k8s.io/api/rbac/v1:go_default_library", "//staging/src/k8s.io/api/rbac/v1beta1:go_default_library", <del> "//staging/src/k8s.io/api/scheduling/v1alpha1:go_default_library", </del> <ins> "//staging/src/k8s.io/api/scheduling/v1beta1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/api/equality:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/api/meta:go_default_library",

Discussion:
/kind bug What happened: When I try to create a priorityclass object like: It fails with And when I try create it with yaml file like: It works. What you expected to happen: Create a priorityclass object with kubectl.
/sig cli
Do you have --runtime- set in kube-apiserver?
No, if set this, it works.
Agree this is a bug. v1beta1 should be preferred.
/sig scheduling
Change:
} } <ins> // EmbeddableTypeMeta passes GetObjectKind to the type which embeds it. type EmbeddableTypeMeta runtime.TypeMeta func (tm *EmbeddableTypeMeta) GetObjectKind() schema.ObjectKind { return (*runtime.TypeMeta)(tm) } </ins> func TestConflictingAddKnownTypes(t *testing.T) { s := runtime.NewScheme() gv := schema.GroupVersion{Group: "foo", Version: "v1"}

Discussion:
We have moved to non-global schema in a number of places in 1.6 and 1.7. It is easy to forget registering the unversioned types like , leading to encoding errors in error cases. The registration of the unversioned types should be automatic as for the types, i.e. in .
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
do we need to close out this issue? (since referenced PR has merged)
Fixed by
Change:
string(api.ResourcePersistentVolumeClaims), string(api.ResourceStorage), string(api.ResourceRequestsStorage), <ins> string(api.ResourceServicesNodePorts), string(api.ResourceServicesLoadBalancers), </ins> ) // IsStandardResourceName returns true if the resource is known to the system

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In some validation functions, such as , , value returned may be wrong. When return some errors and , we may just return , that is not expected What you expected to happen: return correctly
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 api-machinery
/assign
Can you clarify "wrong"?
For example in will add and to field of ResourceQuotaSpec. Before , these two resources are not to standard resource sets, will return error since they are not fully-qualified neither. But will not return any error since the two resources are to standard quota resource name sets. The result above is not expected . Error happened in , we need to return it instead of returning when we ran
Change:
} return cloudprovider.Zone{ <del> FailureDomain: zone, Region:        location, </del> <ins> FailureDomain: strings.ToLower(zone), Region:        strings.ToLower(location), </ins> }, nil } // if UseInstanceMetadata is false, get Zone name by calling ARM

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: Azure cloud provider gets the availability zone from IMDS directly and the zone is usually in lower cases in most regions. But there're chances this is not true in some regions, hence customer's workloads depend on availability zone may not work. What you expected to happen: The availability zone is always in lower cases. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig cloud-provider /area provider/azure
/assign
Fixed by .
Change:
t.Errorf("expected to evaluate %v, got %v", tc.expectEvaluate, evaluator.lv) } if !reflect.DeepEqual(result.Warnings, tc.expectWarnings) { <del> t.Errorf("expected warnings:n%vngotn%v", tc.expectWarnings, result.Warnings) </del> <ins> t.Errorf("expected warnings:n%vngotn%v", strings.Join(tc.expectWarnings, "n"), strings.Join(result.Warnings, "n")) </ins> } }) }

Discussion:
When updating policy labels on a namespace, existing pods are evaluated to see if they are compatible with the new policy. If there are too many pods, or if evaluation takes too long, we short circuit and warn that not all pods were checked. For that reason, we want to prioritize checking a variety of pods before checking essentially identical pods, so that unique warnings can be surfaced before reaching the pod count cutoff or evaluation timeout. Pods created by the same controller are most likely to be identical (e.g. replicas from a replicaset or job, copies of pods from a statefulset or daemonset, etc) cc
This is an interesting fix I'd like to take this up Can I take this up? I am fairly new to Kubernetes source code so might need some help
I am guessing this is where the logic you mentioned should be implemented right?
thanks for the interest; this is targeted at the beta version... right now, effort is going toward the alpha-blocking work for 1.22
Should I wait for the code freeze before working on this? Sorry for lame questions
If you want to start looking at it, that's fine, but it's possible the code in the ValidateNamespace function will change before we're ready to start merging 1.23 work, and there isn't really reviewer bandwidth to take a look at work-in-progress stuff for next release yet.
Sure, I'll just for code freeze before I start with implementation By the time I'll just assign this to myself /assign
Does it make sense to take it up now? I think we already have a couple of RC builds after the code freeze
sure, it's fine to start work in a branch in your fork and have a WIP PR open, even before master reopens for 1.23 work
Awesome, I'll start working on it Thank you
Hello! Are you still working on this? If you don't have time, I can take this issue. If not, maybe I can give some help
Since this was not an urgent issue I was working on some other issues last week I have started on this, Will be raising a PR maybe today or tomorrow I Will ask you if I get stuck Thank you
Change:
fi } <ins> # kube::util::read-array # Reads in stdin and adds it line by line to the array provided. This can be # used instead of "mapfile -t", and is bash 3 compatible. # # Assumed vars: #   $1 (name of array to create/modify) # # Example usage: # kube::util::read-array files < <(ls -1) # function kube::util::read-array { local i=0 unset -v "$1" while IFS= read -r "$1[i++]"; do :; done eval "[[ ${$1[--i]} ]]" || unset "$1[i]" # ensures last element isn't empty } </ins> # Some useful colors. if [[ -z "${color_start-}" ]]; then declare -r color_start="033["

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 --This issue was moved from What happened: building kubernetes with make fails on mac after What you expected to happen: building should not fail How to reproduce it (as minimally and precisely as possible): build from a mac Anything else we need to know?: mapfile is not available on macOS bash. we should have a version check at minimum if we're going to use unsupported features (some of the code already does this) cc
/sig release
Ugh. Does the containerized build at least still work on Mac? Ideally we'd stick to that as the recommended approach, since we can at least guarantee a correct environment. I guess this is really Apple's fault, for refusing to upgrade the bash version on Macs (so they can avoid GPL) - the default on most Macs is 3.2.57, which dates to 2007 according to this blog post: I don't personally think we should support something that old. None of our CI uses a bash that old. It's ripe for breakage. You can install a newer version of bash via homebrew.
the containerized build does not because this code runs on the host. we should put a version check then, so we get a more understandable error.
Up until this point we have supported it by using instead, macOS's old system bash is annoying, but errors from deep within our bash waste more time supporting confused developers
IIRC even in CI you ran into a bash version problem in fact just yesterday (?) we could add a snippet like this to the main build if we don't want to switch to :
I worry about requiring brew and can imagine some folks systems might be managed in a way that disallow this. Still it's reaaaaally painful having to debug and trying to keep things running with the crufty OSX dev userspace. Given there are multiple snippets of brew install suggestions, it would be better imho to put them in one common top level place (ie: )
fair, On systems with restricted at least should work, if that doesn't work i'd expect the setup is just too restrictive to build at all (?)

The check doesn't have to require homebrew per se either, even just "Sorry building on macOS is unsupported" is more helpful than:
Fix inbound:
/assign
Change:
} return obj.(*autoscalingv1.Scale), err } <ins> // CreateScale takes the representation of a scale and creates it.  Returns the server's representation of the scale, and an error, if there is any. func (c *FakeClusterTestTypes) CreateScale(ctx context.Context, clusterTestTypeName string, scale *autoscalingv1.Scale, opts v1.CreateOptions) (result *autoscalingv1.Scale, err error) { obj, err := c.Fake. Invokes(testing.NewRootCreateSubresourceAction(clustertesttypesResource, clusterTestTypeName, "scale", scale), &autoscalingv1.Scale{}) if obj == nil { return nil, err } return obj.(*autoscalingv1.Scale), err } </ins>

Discussion:
What happened: Test create method for non-namespaced subresources generate invalid code. I have the following code generation annotations: which generated test method with generated fake client: What you expected to happen: It should be: How to reproduce it (as minimally and precisely as possible): Generate clients for non-namespaced resources with subresources (like scale) like this: /sig api-machinery /area code-generator /assign
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : What happened: What you expected to happen: It should be: How to reproduce it (as minimally and precisely as possible): Generate clients for non-namespaced resources with subresources (like scale) like this: /sig api-machinery /area code-generator /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
/assign
/triage accepted
Change:
preFilterWithExtensionsPluginName = "prefilter-with-extensions-plugin" duplicatePluginName               = "duplicate-plugin" testPlugin                        = "test-plugin" <ins> permitPlugin                      = "permit-plugin" </ins> ) // TestScoreWithNormalizePlugin implements ScoreWithNormalizePlugin interface.

Discussion:
What would you like to be : When the pod is scheduled to the phase and I delete the pod, the pod still remains in the until the plugin allow/reject/timeout(Especially when waiting for a long time). Why is this needed: We need to take the initiative to delete the data in the and terminate the process in waiting state of plugin to ensure data accuracy, if the pod has been deleted /cc /priority important-soon /assign /sig scheduling
I think we can update the event handler for deleting pods to reject the pod. Can you send a PR for that?
OKI will send a pr for it.
Change:
close(timeoutCh) select { case <-done: <del> if !watcher.IsStopped() { </del> <ins> eventCh := watcher.ResultChan() select { case _, opened := <-eventCh: if opened { t.Errorf("Watcher received unexpected event") } if !watcher.IsStopped() { t.Errorf("Watcher is not stopped") } case <-time.After(wait.ForeverTestTimeout): </ins> t.Errorf("Leaked watch on timeout") } case <-time.After(wait.ForeverTestTimeout):

Discussion:
Which test(s) are flaking: TestWatchHTTPTimeout Reason for failure: This test is flaking, but not enough to fail our presubmit CI (which currently retries up to 3 times and passes on a single green run). Observed in when trying to disable this flake toleration. Reproducer steps: test binary: with : This is reproducible on release-1.18 as well, though is happening an order of magnitude more frequently on master: /sig api-machinery
/assign I would like to give it a shot.
thanks for looking