jiebi/CodeConvo huggingface dataset:
Code change:
} info := infos[0] mapping := info.ResourceMapping() <del> printer, err := f.PrinterForMapping(cmd, false, nil, mapping, allNamespaces) </del> <ins> // no need to print namespace for root-scoped resources printWithNamespace := allNamespaces if mapping != nil && mapping.Scope.Name() == meta.RESTScopeNameRoot { printWithNamespace = false } printer, err := f.PrinterForMapping(cmd, false, nil, mapping, printWithNamespace) </ins> if err != nil { return err }

Related discussion:
text: This is wrong, cluster scoped resources should never have a NAMESPACE column. We need to fix and add a test to ensure this doesn't regress.
The presence of the flag is what triggers this.
I would help fix it.
I mean to add a test after modification, but found that current test framework could not support the case: To cover the scene, we need a real NewHumanReadablePrinter in test case, to ensure the output format, and modify the related funcs in FakeFactory to support pass in param withNamespace. I feel this not like behavior of unit test to some extent. The loss may outweighs the gain to have such a big impact on the whole. What's your opinion
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing the label for more than 7 days. <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Code change:
} } <del> err := utilfeature.DefaultFeatureGate.SetFromMap(o.config.FeatureGates) if err != nil { </del> <ins> if err := o.processHostnameOverrideFlag(); err != nil { return err } if err := utilfeature.DefaultFeatureGate.SetFromMap(o.config.FeatureGates); err != nil { </ins> return err } return nil } <ins> // processHostnameOverrideFlag processes hostname-override flag func (o *Options) processHostnameOverrideFlag() error { // Check if hostname-override flag is set and use value since configFile always overrides if len(o.hostnameOverride) > 0 { hostName := strings.TrimSpace(o.hostnameOverride) if len(hostName) == 0 { return fmt.Errorf("empty hostname-override is invalid") } o.config.HostnameOverride = strings.ToLower(hostName) } return nil } </ins> // Validate validates all the required options. func (o *Options) Validate(args []string) error { if len(args) != 0 {

Related discussion:
text: <!-- 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?: What happened: kube-proxy came up cleanly but mis-configured iptable rules due to a mis-match in the hostname and node name within the cluster triggering a default behavior. In this case the hostname returned the fqdn of the host and the cluster only had the hostname. This resulted in the following warning messages when kube-proxy started. Which then presents itself as pods not being able to access clusterip ip addresses with no route errors. What you expected to happen: Would it be better to fail to in this scenario rather than try to fall back to some default? I spent a good amount of time trying to track down the Error messages that were a result of this before finally working back to taking a closer at the Warning message. How to reproduce it (as minimally and precisely as possible): Start the kube-proxy with set to an invalid hostname should recreate this issue. Anything else we need to know?: While I think we can chalk up this issue to mis-configuration the purpose of opening this issue is really to have a conversation about the default behavior. I've seen several other issues filed that appear to be related to this behavior: , , . Would throwing an error and exiting non-zero be a better default action when the nodeIP is nil? What use case(s) does a default of support? If there must be a default behavior here maybe the IP address on the interface associated with the default gateway is a better default than ? Maybe the issue isn't in the proxier code but the kube-proxy itself should error when it fails to get node info rather than a warning? Environment: I'm not sure how much of this is important to this but here's what my environment was when I ran into this. Kubernetes version: 1.8.5 Cloud provider or hardware configuration: Bare metal OS (e.g. from /etc/os-release): Centos 7 and Ubuntu 16.04
This is similar (though not the same symptom) to for which was supposed to fix it but was closed. One of the objections was up til now, kube-proxy has had no requirement that the hostname = nodename or even that the hostname be defined.
Code change:
} } <del> err := utilfeature.DefaultFeatureGate.SetFromMap(o.config.FeatureGates) if err != nil { </del> <ins> if err := o.processHostnameOverrideFlag(); err != nil { return err } if err := utilfeature.DefaultFeatureGate.SetFromMap(o.config.FeatureGates); err != nil { </ins> return err } return nil } <ins> // processHostnameOverrideFlag processes hostname-override flag func (o *Options) processHostnameOverrideFlag() error { // Check if hostname-override flag is set and use value since configFile always overrides if len(o.hostnameOverride) > 0 { hostName := strings.TrimSpace(o.hostnameOverride) if len(hostName) == 0 { return fmt.Errorf("empty hostname-override is invalid") } o.config.HostnameOverride = strings.ToLower(hostName) } return nil } </ins> // Validate validates all the required options. func (o *Options) Validate(args []string) error { if len(args) != 0 {

Related discussion:
text: Making kube-proxy exit on failure to retrieve the node object might cause regressions in some legitimate use-cases. But I have no idea what those are. ?
I have a hard time imagining what the legit cases might be. I am confused, though - I only see this field being used in one very specific place, that would not have the effect you are claiming.
I can't see the error message from log? If kube-proxy failed to create kube-ipvs0 dummy interface, it will log something like "Failed to create dummy interface: kube-ipvs0, error:...".
This breaks Services of type and with . This is problematic for AWS environments where the kubelet is configured to override the hostname (AWS instances default to the short name and for the cloud provider integrations to work this needs to be overridden to the private fqdn of the host).
Any chance we could get this prioritized as a bug fix for v1.11?
cc
After putting a bit more thought into this, would it be possible to standardize on an environment variable that could be set through the downward api to override the default behavior of treating the hostname as the node name in the proxy? That would simplify the configuration on the kubeadm side (no need to override the command with the downward api, only setting the appropriate env variable), and would also provide a more accurate way to retrieve the actual node name for kube-proxy when deployed as a daemonset without the need to interact with the kubelet directly. I would suggest that we could use for this purpose. I'd also be happy to take a stab at implementing the changes needed for the v1.12 cycle.
Code change:
} } <del> err := utilfeature.DefaultFeatureGate.SetFromMap(o.config.FeatureGates) if err != nil { </del> <ins> if err := o.processHostnameOverrideFlag(); err != nil { return err } if err := utilfeature.DefaultFeatureGate.SetFromMap(o.config.FeatureGates); err != nil { </ins> return err } return nil } <ins> // processHostnameOverrideFlag processes hostname-override flag func (o *Options) processHostnameOverrideFlag() error { // Check if hostname-override flag is set and use value since configFile always overrides if len(o.hostnameOverride) > 0 { hostName := strings.TrimSpace(o.hostnameOverride) if len(hostName) == 0 { return fmt.Errorf("empty hostname-override is invalid") } o.config.HostnameOverride = strings.ToLower(hostName) } return nil } </ins> // Validate validates all the required options. func (o *Options) Validate(args []string) error { if len(args) != 0 {

Related discussion:
text: Pods not getting scheduled on the new node joined to the cluster using kubespray The node joined to the cluster but new pods schedueld on the nodes are failing with error "get https://10.233.0.1 : dial tcp 10.233.0.1: 443 connection refused" Network plugin - calico kube-proxy running in ipvs mode new worker node, can connect to master server ip address over 6443 new worker node, cannot access cluster ip 10.233.0.1 over port 443 , nodelocaldns and kube-proxy pods are in running state on new node -proxy logs show error "invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP" Unable to write event: 'Post https://127.0.0.1:6443/api/v1/namespaces/default/events dial tcp 127.0.0.1:6443 connection refused" -ln output do not show any services addr show output do not show kube-ipvs0 and calico interfaces Can someone please help. Thanks
Code change:
} // Even if PodCIDR is assigned, but NetworkUnavailable condition is // set to true, we need to process the node to set the condition. <ins> networkUnavailableTaint := &v1.Taint{Key: algorithm.TaintNodeNetworkUnavailable, Effect: v1.TaintEffectNoSchedule} </ins> _, cond := v1node.GetNodeCondition(&newNode.Status, v1.NodeNetworkUnavailable) <del> if cond == nil || cond.Status != v1.ConditionFalse { </del> <ins> if cond == nil || cond.Status != v1.ConditionFalse || !utiltaints.TaintExists(newNode.Spec.Taints, networkUnavailableTaint) { </ins> return ca.AllocateOrOccupyCIDR(newNode) } return nil

Related discussion:
text: forked from As from the discussion with and we have to start checking taints wherever we check for node.Spec.Unschedulable. Also overlaps on some parts with /sig node /assign
cc
No sure the discussion history :); personally, prefer to deprecate and replace it with taint.
- same here, the goal would be to deprecate its usage, start checking taints everywhere unschedulable is used. Also, as long as we as we have v1, we might have to keep checking for both.
great, there's same subtask in my mind: deprecated description to the taint for command with taint others ??
- yup, but for 4 it is more something like check taints wherever we checn for unschedulable, since we cannot just replace until v1 is gone.
, my major point is to handle it task by task to make sure we did not miss anything :).
yes we definitely should
- should we define a specific taint for unschedulable (key and effect) ? (i.e what happens when a user uses cordon/uncordon)
I'm not sure about having specific Taint for Unschedulable is a good idea. Pretty much any Taint with NoSchedule effect will do (and this is what we should be checking).
- I agree, but in case of we can add a taint with key or something like that with a effect. This might help us especially if the node has no taints.
, not sure whether we should handle specially; AFAIK, set this flag for node maintenance, this taint should not be tolerated.
The whole point of moving from to Taints is to make things more configurable. as they're decision makers here.
If we are discussing about deprecate/re-implement by Unschedulable taint, +1 as it make sense. Current cordon is causing confusion in community since you can always taint it instead, and tainting is what most Kubernetes setup tool is doing today.
I agree with that we should use NoSchedule taint. I also agree that generally no pod should tolerate NoSchedule taints, but they may want to do so if the desire, knowing that anything could happen to the node they are scheduled on. For example, today DS pods tolerate "Unschedulable" bit.
Code change:
} // Even if PodCIDR is assigned, but NetworkUnavailable condition is // set to true, we need to process the node to set the condition. <ins> networkUnavailableTaint := &v1.Taint{Key: algorithm.TaintNodeNetworkUnavailable, Effect: v1.TaintEffectNoSchedule} </ins> _, cond := v1node.GetNodeCondition(&newNode.Status, v1.NodeNetworkUnavailable) <del> if cond == nil || cond.Status != v1.ConditionFalse { </del> <ins> if cond == nil || cond.Status != v1.ConditionFalse || !utiltaints.TaintExists(newNode.Spec.Taints, networkUnavailableTaint) { </ins> return ca.AllocateOrOccupyCIDR(newNode) } return nil

Related discussion:
text: They may as well want to tolerate "NoSchedule" taints.
/sig scheduling
Agree; it's up to 'user' to decide whether tolerates the taint, we just need to taint it and doc what's happened in node for taints :)
We should have a mechanism that allows a cluster admin to limit types of tolerations that users can set. This is needed to prevent abuse in multi-tenant clusters. For example, cluster admin may want to taint nodes with rare resources to prevent pods from certain group of users to land on them. Users shouldn't be able to tolerate such taints. That said, this is a separate topic of its own which is related to policy and should be discussed separately.
- we’re already facing this in production for our spare nodes. I’ll bring this up in our next sig-meeting, I’ll also file an issue for this
Code change:
}, &api.Namespace{}, store, <del> 0, </del> <ins> 5*time.Minute, </ins> ) reflector.Run() return &lifecycle{ <del> Handler:            admission.NewHandler(admission.Create, admission.Delete), </del> <ins> Handler:            admission.NewHandler(admission.Create, admission.Update, admission.Delete), </ins> client:             c, store:              store, immortalNamespaces: util.NewStringSet(api.NamespaceDefault),

Related discussion:
text: We should have a single NamespaceLifecycle plugin that enforces the Namespace rules now that all providers are off NamespaceAutoProvision. We may also want to make this no longer a user choice to configure and hard-wire the server to always run this check first to simplify configuration errors. For an example
Code change:
subnet: netip.MustParsePrefix("fd00:1:2:3::/64"), want:   netip.MustParseAddr("fd00:1:2:3:FFFF:FFFF:FFFF:FFFF"), }, <ins> { name:   "ipv6 00fc::/112", subnet: netip.MustParsePrefix("00fc::/112"), want:   netip.MustParseAddr("fc::ffff"), }, { name:   "ipv6 fc00::/112", subnet: netip.MustParsePrefix("fc00::/112"), want:   netip.MustParseAddr("fc00::ffff"), }, </ins> } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) {

Related discussion:
text: We ran into an issue with an old version of k8s 1.18 that we were running where subnet for cluster IP is given as . The control plane comes up just fine but then when you try to create a k8s service, it fails due to a broken behavior with the IP Allocator Since this is not really a supported version of the k8s, I went around digging up a bit more to see what is the regular behavior and found this to be very inconsistent across a few release branches. bash go test -timeout 30m -run ^TestAllocateNextFC$ -v === RUN TestAllocateNextFC ? --- PASS: TestAllocateNextFC (0.00s) PASS ok 0.566s go func TestAllocateNextFC(t *testing.T) { , cidr, err := netutils.ParseCIDRSloppy("fc::/112") if err != nil { t.Fatal(err) } // Need to be replaced with the suitable handler for that version of the branch r, err := newTestAllocator(cidr) if err != nil { t.Fatal(err) } defer r.Destroy() ip, err := r.AllocateNext() if err != nil { t.Fatalf("%s", err.Error()) } fmt.Println(ip.String()) } Add the above Test case under the IP allocator test case No response_ <detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details<detailsNA </details
/sig network /assign /kind bug
Thanks for helping me with this issue.
/triage accepted /assign
Code change:
// 1.  spec.containers[*].image // 2.  spec.initContainers[*].image // 3.  spec.activeDeadlineSeconds <ins> // 4.  spec.terminationGracePeriodSeconds </ins> containerErrs, stop := ValidateContainerUpdates(newPod.Spec.Containers, oldPod.Spec.Containers, specPath.Child("containers")) allErrs = append(allErrs, containerErrs...)

Related discussion:
text: <!-- 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: Some k8s client tried to evict a pod by setting negative value for deletionGracePeriodSeconds. But all eventual delete calls (and force-delete calls) made by kubelet, pod-garbage-collector, etc were not able to delete that pod, because apiserver doesnt allow deletionGracePeriodSeconds to be increased once it is set. So force-delete (which set it to 0) doesn't take effect when it's already negative. Not even kubectl is able to call delete with negative grace-period. But curl with an even more negative grace-period value worked. What you expected to happen: force-delete works. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I think the issue is in the code below As the comment suggest, in phase 1, the was set to a negative value (meaning was in the past), and in phase 2, has to be set even lower, otherwise, it will be considered as pending graceful deletion and not performing the immediate delete. I think there're two possible fixes. not allowing setting in the past ( should be non-negative). In that case, we could convert to 0 if negative. that could be set in the past. In that case, in phase 2, we treat negative value of the same as 0, and allow immediate delete. Thoughts? 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
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig api-machinery 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
/cc /triage accepted
No component in the system should ever treat the timestamp of DeletionTimestamp as authoritative.
Code change:
// 1.  spec.containers[*].image // 2.  spec.initContainers[*].image // 3.  spec.activeDeadlineSeconds <ins> // 4.  spec.terminationGracePeriodSeconds </ins> containerErrs, stop := ValidateContainerUpdates(newPod.Spec.Containers, oldPod.Spec.Containers, specPath.Child("containers")) allErrs = append(allErrs, containerErrs...)

Related discussion:
text: In Kube, components are required to calculate the time period from when they observe the event in their local clock (i.e. 30s from now), not use the deletion timestamp. A negative value of deletion grace period should be rejected by the apiserver as an invalid value (bad request / invalid field).
attempts to take a missing or positive deletion grace period negative should be rejected, I agree. if a negative value is already persisted, I'd be inclined to allow a negative value in an update and clip to 0
As I mentioned in the PR, eviction is passing negatives through to the store: In kubectl, we specify the default value for GracePeriod is -1. In the case of delete, we simply don't set the value in the deleteOptions we send to the API. In the case of eviction, we send the -1 value, and that gets passed along to the store.
I don't see the -1 getting sent to the eviction API. It looks like values < 0 result in a nil value being sent to the API: I would not expect the API to accept a negative value as-is.
Looks like you are correct. Do the deletionOptions go through their own validation or through some kind of validation for the evict API? The original bug report mentions 'evict' though it's not clear if the eviction API was used or not.
ValidateDeleteOptions is called inside pod deletion, but did not check that the field was non-negative. I don't see any eviction-specific validation.
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
/lifecycle rotten
Im investigating the and . Surprisingly see you here...
Code change:
} } <del> // LocalEndpoint returns the full path to a windows named pipe func LocalEndpoint(path, file string) string { u := url.URL{ Scheme: npipeProtocol, Path:   path, } return u.String() + "//./pipe/" + file </del> <ins> // LocalEndpoint empty implementation func LocalEndpoint(path, file string) (string, error) { return "", fmt.Errorf("LocalEndpoints are unsupported in this build") </ins> } var tickCount = syscall.NewLazyDLL("kernel32.dll").NewProc("GetTickCount64")

Related discussion:
text: What happened: I replaced the kubelet on one of my 1.14 nodes with a build from master, and now I'm getting this error starting up. Test passes since 5/31/2019 commit have been failing on testgrid. If you look at the logs, the Windows nodes are not coming up. What you expected to happen: No errors starting up kubelet How to reproduce it (as minimally and precisely as possible): Build master, then try to run the kubelet on Windows Anything else we need to know?: /sig windows Environment: Kubernetes version (use ): Cloud provider or hardware configuration: Azure OS (e.g: ): Windows Server 2019 Kernel (e.g. ): 10.0..529 Install tools: aks-engine
cc /priority critical-urgent
/milestone v1.15 Release team - it looks like a recent PR broke windows nodes. We will need a fix here for 1.15
Ok, so the problem here is a little more complicated and we're actually seeing a bug that is actually in the code for quite some time, just that we never used that particular code path. But first: TL;DR: Quick fix is to start the kubelet on Windows with: --feature-gates="KubeletPodResources=false" Now, as to why this is happening: PR [1] was merged 3 days ago and it graduates KubeletPodResources feature as Beta. That means kubelet will enable it by default.With the introduction of the above feature, this branch of code is entered when starting kubelet [2]. We can see a call to the function: defined here [3].While innocent enough, gets the necessary npipe by calling: . is defined here [4] for Windows . The problem is actually that url.URL can't handle Windows style paths [5] and will replace "" with "%5C" as it's to be expected. The paths are transformed along the way from the default "/var/lib/kubelet" to "varlibkubelet" by defined here [6]. More specifically in the use of to create a path. It's inputs are unix style but returns the path Windows style as it's to be expected.The solution is to replace the usage of url.URL in with some alternative package or just implement it.
Code change:
} } <del> // LocalEndpoint returns the full path to a windows named pipe func LocalEndpoint(path, file string) string { u := url.URL{ Scheme: npipeProtocol, Path:   path, } return u.String() + "//./pipe/" + file </del> <ins> // LocalEndpoint empty implementation func LocalEndpoint(path, file string) (string, error) { return "", fmt.Errorf("LocalEndpoints are unsupported in this build") </ins> } var tickCount = syscall.NewLazyDLL("kernel32.dll").NewProc("GetTickCount64")

Related discussion:
text: [1] [2] [3] [4] [5] [6]
Thanks for the analysis! I was a bit concerned around the fact that this started showing up around my commit: but the root cause here is indeed, as you said, the graduation of feature to Beta and the way the invalid escape sequences are being introduced.
GCE tests failing too /cc
I'm trying a quick to see if anything else is broken. There are other functions in that same file doing that substitution already so it may make sense to use that as a workaround until a better solution is available.
Still working on it - looks like the path to create the directories is also busted. With still getting