jiebi/CodeConvo huggingface dataset:
Code change:
ginkgo.BeforeEach(func() { c = f.ClientSet ns = f.Namespace.Name <ins> dc = f.DynamicClient </ins> }) ginkgo.It("deployment reaping should cascade to its replica sets and pods", func() {

Related discussion:
text: [x] Original approval issue: [x] Test pr: [x] Two weeks soak end date: 19 November 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still some remaining Deployment endpoints which are untested. a Deployment with a static label the Deployment with a new Label and updated data the Deployment to ensure it's patched all Deployments in all Namespaces find the Deployment(1) ensure that the Deployment is found and is patched Namespaced Deployment(1) via a Collection with a LabelSelector Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 5 points* This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
BobyMcbobs commented in original Issue: Unsure if the endpoint replaceAppsV1NamespacedDeploymentStatus is able to be hit. When this endpoint is attempted to be updated the data after retrieving the update resource doesn't reflect the values in the update
/assign
When using the appv1.Deployment structure instead of maps of interfaces to build the structure in a patch of the Deployment, this error comes up. Still in progress yment-static":"true"}: does not match template , spec.selector: Invalid value: "null": field is immutable]
replaceAppsV1NamespacedDeploymentStatus to test. Increase cover by 1 Endpoint
/reopen PR reverted by due to flaky test
Reopened this issue. <detailsIn response to : /reopen PR reverted by due to flaky test Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/reopen Soaking, ready for promotion 19 November 2020
Reopened this issue. <detailsIn response to : /reopen Soaking, ready for promotion 19 November 2020 Instructions for interacting with me using PR comments are available .
Code change:
ginkgo.BeforeEach(func() { c = f.ClientSet ns = f.Namespace.Name <ins> dc = f.DynamicClient </ins> }) ginkgo.It("deployment reaping should cascade to its replica sets and pods", func() {

Related discussion:
text: If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-lifecycle stale
/triage accepted
/merged
Code change:
func (i *Instances) NodeAddresses(name string) ([]api.NodeAddress, error) { glog.V(4).Infof("NodeAddresses(%v) called", name) <del> srv, err := getServerByName(i.compute, name) </del> <ins> addrs, err := getAddressesByName(i.compute, name) </ins> if err != nil { return nil, err } <del> addrs := []api.NodeAddress{} for _, addr := range findAddrs(srv.Addresses["private"]) { addrs = append(addrs, api.NodeAddress{ Type:    api.NodeInternalIP, Address: addr, }) } for _, addr := range findAddrs(srv.Addresses["public"]) { addrs = append(addrs, api.NodeAddress{ Type:    api.NodeExternalIP, Address: addr, }) } // AccessIPs are usually duplicates of "public" addresses. api.AddToNodeAddresses(&addrs, api.NodeAddress{ Type:    api.NodeExternalIP, Address: srv.AccessIPv6, }, api.NodeAddress{ Type:    api.NodeExternalIP, Address: srv.AccessIPv4, }, ) </del> glog.V(4).Infof("NodeAddresses(%v) => %v", name, addrs) return addrs, nil }

Related discussion:
text: From we can find that, hardcode "private" and "public", seems only support that network with such name. , it fetch the first ip. usually, it can include both v6 and v4 ip. what's the meaning to just fetch the first one ? is it v4 or v6 ?
ping and
Yes. Zoom out a level or two in the code, and you'll see we're trying to either a) setup an openstack loadbalancer to point to the minion node (a single address) using , or b) report to kubernetes all the addresses we know about the node and whether they are "internal" or "external" in . All we have at the starting point is the server name (from kubernetes), and we need to make up the rest of this information somehow. (I agree (a) should reuse the NodeAddresses() function from (b), but the latter is a newer function and the code hasn't yet been refactored in that way. This doesn't really change the substance of this discussion.) Re (1): The logic as currently implemented is: Assume any network named "private" is "internal" Assume any network named "public" is "external" Assume the AccessIPs (IPv4 and IPv6) are "external" Any other network addresses are ignored. I implemented the first two ("private" and "public") following the Rackspace public cloud precedent, and on the basis that users in other OpenStack clouds can use these names if they want to encourage an address other than the Access addresses. For the (a) use case, we just take the first address we find in order of the above; for (b) we report that full list. I preferred "private" to "public" since (again, at least on Rackspace public cloud), the traffic on "private" network is sometimes cheaper/free. I agree this isn't great, and please suggest something better if you have a use case in mind. Perhaps we should pull a list of network names that should be considered "internal" and "external" from the provider config? Perhaps I could assume that provider networks are public and non-provider networks are internal? I don't want to add too much configuration here if there's a good algorithm that will Just Work.
Code change:
func (i *Instances) NodeAddresses(name string) ([]api.NodeAddress, error) { glog.V(4).Infof("NodeAddresses(%v) called", name) <del> srv, err := getServerByName(i.compute, name) </del> <ins> addrs, err := getAddressesByName(i.compute, name) </ins> if err != nil { return nil, err } <del> addrs := []api.NodeAddress{} for _, addr := range findAddrs(srv.Addresses["private"]) { addrs = append(addrs, api.NodeAddress{ Type:    api.NodeInternalIP, Address: addr, }) } for _, addr := range findAddrs(srv.Addresses["public"]) { addrs = append(addrs, api.NodeAddress{ Type:    api.NodeExternalIP, Address: addr, }) } // AccessIPs are usually duplicates of "public" addresses. api.AddToNodeAddresses(&addrs, api.NodeAddress{ Type:    api.NodeExternalIP, Address: srv.AccessIPv6, }, api.NodeAddress{ Type:    api.NodeExternalIP, Address: srv.AccessIPv4, }, ) </del> glog.V(4).Infof("NodeAddresses(%v) => %v", name, addrs) return addrs, nil }

Related discussion:
text: I think in practice it's probably ok to continue to prefer "internal" to "external" for loadbalancer setup, but I can contrive hypothetical cases that need more flexibility here too. Again, if you have a concrete need for such a thing, please file a bug so we have some idea of the flexibility required. Complicating all this is that Kubernetes never actually defined what an "internal" address was. just says "Generally the IP address of the node that is routable only within the cluster" which isn't a sufficiently strict definition. Looking at where Kubernetes actually uses it: just uses the first address reported (preferring InternalIPs to ExternalIPs) and the Kubernetes master configures an "SSH Tunnel Check" which just uses the first ExternalIP ... which kind of makes it pointless to ever even bother reporting anything beyond the first address. In both cases, it's assumed that this address is reachable by the Kubernetes master nodes, which makes the Internal vs External distinction a bit pointless. Re (2): is meant to return more than one IP, and the loadbalancer setup can only use a single IP for each node (or would unnecessarily track/healthceck multiple paths to the same backend for multiple addresses). If you're seeing single addresses returned by then you should file a bug. All the above treats IPv4 and IPv6 as equally important, if the OpenStack cloud has both, and the "first" address used for the loadbalancer will be an arbitrary choice between the two protocols (not quite true: will use AccessIPv4 before AccessIPv6). I think that's how it should be (the rest of the code should be protocol agnostic), but I wouldn't be surprised if there's some part of Kubernetes that doesn't support IPv6 properly. There certainly used to be lots of places that assumed IPv4 in Kubernetes, and GCE doesn't support IPv6 iirc so it gets less testing - if you've found something that breaks with IPv6, please file bugs. Now this bug: what would you like done here? Would you like the current situation to be documented further? Is the "private"/"public" naming thing too restrictive for your usecase? Something else?
Code change:
func (i *Instances) NodeAddresses(name string) ([]api.NodeAddress, error) { glog.V(4).Infof("NodeAddresses(%v) called", name) <del> srv, err := getServerByName(i.compute, name) </del> <ins> addrs, err := getAddressesByName(i.compute, name) </ins> if err != nil { return nil, err } <del> addrs := []api.NodeAddress{} for _, addr := range findAddrs(srv.Addresses["private"]) { addrs = append(addrs, api.NodeAddress{ Type:    api.NodeInternalIP, Address: addr, }) } for _, addr := range findAddrs(srv.Addresses["public"]) { addrs = append(addrs, api.NodeAddress{ Type:    api.NodeExternalIP, Address: addr, }) } // AccessIPs are usually duplicates of "public" addresses. api.AddToNodeAddresses(&addrs, api.NodeAddress{ Type:    api.NodeExternalIP, Address: srv.AccessIPv6, }, api.NodeAddress{ Type:    api.NodeExternalIP, Address: srv.AccessIPv4, }, ) </del> glog.V(4).Infof("NodeAddresses(%v) => %v", name, addrs) return addrs, nil }

Related discussion:
text: Hi, if we talked about openstack, I expect it not bind to rackspace, although, the kubernetes called RK SDK, But from my understanding, seems RK itself SDK not bind network to "private" and "pubic". User can define public network with their names, like site-network, for example. or "testnet", And for private, it should be seem. For nova list, the addresses, it can have "OS-EXT-IPS:type":"fixed" or "OS-EXT-IPS:type":"floating" for floating, I think what you means "Public", for fixed, I think its what you means "Private". In other words, we'd better to find related information from other fields in nova or neutron infromation. Instead of bind to "private" and "public" name.
I this issue and wrote a patch that implements what suggests. I will send a PR soon
Glad to see some improvements here. And wish to use it if implemented
Code change:
"fmt" "net/http" "net/http/httptest" <ins> "net/url" </ins> "reflect" "testing" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> ) func TestInstallHandler(t *testing.T) {

Related discussion:
text: What would you like to be : Add support to the kube-apiserver so that we can disable health-checks via query params. Why is this needed: Currently, the healthz endpoint is inflexible in that any and all health checks are currently executed when the endpoint is hit. Since the kube-apiserver only currently supports a liveness check, this means all persistent health check failures will eventually result in a kubelet driven restart. However, this may not be desirable behavior if you have additional monitoring services layered on top of your control plane. For instance, take the etcd failure from the perspective of the kube-apiserver. Currently, persistent failures during the etcd health check from the api-server healthz endpoint will cause the kube-apiserver to be restarted. This sometimes helps (in the case of a faulty etcd-client connection) but also can be detrimental (the kube-apiserver restarts until the etcd cluster is functioning, then the kube-apiserver bombards the etcd cluster with requests to update local caches, saturating the etcd cluster with requests, causing it to timeout on its own liveness probes and trigger a kubelet-driven restart). Let's say that we could now disable etcd from our liveness health check. Then if we had an external monitoring service, we could ask independently ask etcd if it was healthy and we could also ask the kube-apiserver if it thought etcd was unhealthy. Based on the combination of those answers, we could enable more intelligent responses to certain situation, like restarting the kube-apiserver when it thought etcd was unhealthy but etcd was actually reporting as healthy but not doing so when etcd was actually unhealthy. This feature is backwards-compatible and opt-in. There would be no impact to existing behavior unless these query params are actually used. /sig api-machinery /kind feature
/cc
SGTM
/assign
Code change:
# Get the compute zone zone=${ZONE:-"$(gcloud info --format='value(config.properties.compute.zone.value)')"} <ins> zone=${zone// /} </ins> if [[ ${zone} == "" ]]; then echo "Could not find gcloud compute/zone when running: `gcloud info --format='value(config.properties.compute.zone.value)'`" exit 1

Related discussion:
text: The compute project and zone in the prerequisites check are incorrectly calculated: !!! Error in hack/make-rules/test-e2e- Error in hack/make-rules/test-e2e- 'tee -i "${artifacts}/build-"' exited with status 1 0 Call stack: 1: hack/make-rules/test-e2e- main(...) Exiting with status 1 blocked by the following errors in each case: 1- Could not find gcloud compute/zone when running: .... 2- Could not find gcloud project when running: ..... 1- gcloud config unset compute/zone 2- gcloud config unset project 3- make test-e2e-node REMOTE=true LIST_IMAGES=true gcloud --version Google Cloud SDK 453.0.0 alpha 2023.10.27 beta 2023.10.27 bq 2.0.98 core 2023.10.27 gcloud-crc32c 1.0.0 <details</details<details</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 node /assign
Code change:
Searches: []string{testHostDomain}, }, nil } <del> // getResolvConf returns the hostResolvConf string, which will be used to get the Host's DNS configuration. func getResolvConf(t *testing.T) (string, func()) { return hostResolvConf, func() {} } </del>

Related discussion:
text: When a --resolv-conf (DNS resolver config) is passed to kubelet on a Windows node, the config content is used as part of sandbox initialization (through getHostDNSConfig()). Now with the recent changes (), it seems now to fail with an error like: E0315 10:22:16. 4764 ] "Error syncing pod, skipping" err="failed to "CreatePodSandbox" for "img-pull-(-b40a-459d-9033-)" with CreatePodSandboxError: "Failed to generate sandbox config for pod "img-pull-(-b40a-459d-9033-)": Unexpected resolver config value: "C:etckubernetescni". Expected "" or "Host"."" pod="img-puller-3842/img-pull-" podUID=-b40a-459d-9033- This is showing on all the runs of GCE testgrid (latest): Reading/using the passed resolv config on Windows Run a Windows pool with DNS resolv config being set as part of kubelet params. No response_ 27 alpha.3 1.27 beta.0 master <detailsGCE </details<details</details<details</details<details</details<details</details
/triage accepted /milestone v1.27 /sig node /sig network
/sig windows /cc
/priority criticial-urgent as this is likely a release blocking
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority criticial-urgent 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
/priority critical-urgent
Hmm, so you're setting the [1]. This PR introduced the capability to read the DNS config options from the Windows host registries while removing the capability to read from a file, introducing a regression. I've sent a PR addressing this issue: [1]
Is the file you are pointing to a UNIX-style or something else?
Was the file changing the behavior of the node?
Code change:
Searches: []string{testHostDomain}, }, nil } <del> // getResolvConf returns the hostResolvConf string, which will be used to get the Host's DNS configuration. func getResolvConf(t *testing.T) (string, func()) { return hostResolvConf, func() {} } </del>

Related discussion:
text: Yeah, what used on GCE/GKE, seems to be a Linux-like conf, eg: nameserver 10.128.0.1 search c.<project_name.internal google.internal ` We haven't tried to remove from kubelet to see the behavior.
This Issue/PR has been marked as release blocker. Please have the fix merged by eod today otherwise the feature has to be reverted. For the Issue/PR owner: please have a revert/feature disable PR open today in case the fix failed to get in. Thank you! See the -- Kubernetes 1.27 release manager
I opened up a revert PR in case this PR does not merge by code freeze.
Thanks for the resolution! both 2019 and 2022 grids seems to be back to green now!
Thanks for confirming! I opened to ensure gets updated too
Code change:
} if h.nodeCacheCapable && result.NodeNames != nil { <del> nodeResult = make([]*v1.Node, 0, len(*result.NodeNames)) for i := range *result.NodeNames { nodeResult = append(nodeResult, nodeNameToInfo[(*result.NodeNames)[i]].Node()) </del> <ins> nodeResult = make([]*v1.Node, len(*result.NodeNames)) for i, nodeName := range *result.NodeNames { if node, ok := nodeNameToInfo[nodeName]; ok { nodeResult[i] = node.Node() } else { return nil, nil, fmt.Errorf( "extender %q claims a filtered node %q which is not found in nodeNameToInfo map", h.extenderURL, nodeName) } </ins> } } else if result.Nodes != nil { <del> nodeResult = make([]*v1.Node, 0, len(result.Nodes.Items)) </del> <ins> nodeResult = make([]*v1.Node, len(result.Nodes.Items)) </ins> for i := range result.Nodes.Items { <del> nodeResult = append(nodeResult, &result.Nodes.Items[i]) </del> <ins> nodeResult[i] = &result.Nodes.Items[i] </ins> } }

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: Default scheduler crash if scheduler extender filter returns a not found node What you expected to happen: Default scheduler just should consider the not found node as not an candidate, instead of crash itself (panic). How to reproduce it (as minimally and precisely as possible): cluster only have 1 node: 0.0.0.1 scheduler extender (with nodeCacheCapable enabled) filter accidentally returns a candidate node: 0.0.0.2 scheduler recieved the candidate nodes: 0.0.0.2 from scheduler extender, but got below error: The is SuggestedHost: filteredNodes[0].Name: 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 scheduling
Code change:
return nil } <del> policyGroupVersion, err := CheckEvictionSupport(d.Client) if err != nil { return err } </del> // TODO(justinsb): unnecessary? getPodFn := func(namespace, name string) (*corev1.Pod, error) { return d.Client.CoreV1().Pods(namespace).Get(name, metav1.GetOptions{}) } <del> if len(policyGroupVersion) > 0 { return d.evictPods(pods, policyGroupVersion, getPodFn) </del> <ins> if !d.DisableEviction { policyGroupVersion, err := CheckEvictionSupport(d.Client) if err != nil { return err } if len(policyGroupVersion) > 0 { return d.evictPods(pods, policyGroupVersion, getPodFn) } </ins> } return d.deletePods(pods, getPodFn)

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Allow to have an additional flag (e.g. or ) to allow a to drain pods off a node, even if they violate PodDisruptionBudgets Why is this needed: There are times where you want to drain pods off a node even if violating a PDB. For example, if you are running a one-worker node kubernetes cluster (not minikube), and you want to upgrade it. Or, like me, you are running a test cluster and want to scale down to zero nodes when you're not going to be using the cluster for a while in order to save costs. If that worker node has a deployment with a PDB, then will get stuck as it cannot get rid of the pod while respecting the PDB, which is expected; but in this case, it is a hindrance. Adding the switch will allow users to explicitly acknowledge that they want to ignore the PDBs (and accept the corresponding downtime for an application/service)
/sig node
+1
+1 Our company offers Kubernetes as PaaS. We manage Kubernetes, including IaaS OS updates and if a customer does not specify the PDB correctly, we are not able to drain the node for the OS updates. A flag would be werry helpfull for our use case.
+1
/active
I have created to address this. This is a pretty simple implementation, but I think it achieves the desired results. A suitable workflow would be: 1) Configure you component to use drain as normal 2) After some timeout, run drain with --disable-eviction option.
I'll wait until the PR is merged and released before testing, but if I understand right, it would require me do this, right? If so, I think it would be better if we did it a different way and have one call, something like this: Where implies that if the drain is still running after this time, switch to the mode without having to call kubectl again
I think that would require a sizeable refactor or add a great deal of complexity to the code, the same could be achieved with In practical terms, I'm focused on automatic node remediation via destroying the node and getting a new one. The timeout would be very large, the drain library is blocking, so I want it to fail quickly and requeue.
Code change:
return nil } <del> policyGroupVersion, err := CheckEvictionSupport(d.Client) if err != nil { return err } </del> // TODO(justinsb): unnecessary? getPodFn := func(namespace, name string) (*corev1.Pod, error) { return d.Client.CoreV1().Pods(namespace).Get(name, metav1.GetOptions{}) } <del> if len(policyGroupVersion) > 0 { return d.evictPods(pods, policyGroupVersion, getPodFn) </del> <ins> if !d.DisableEviction { policyGroupVersion, err := CheckEvictionSupport(d.Client) if err != nil { return err } if len(policyGroupVersion) > 0 { return d.evictPods(pods, policyGroupVersion, getPodFn) } </ins> } return d.deletePods(pods, getPodFn)

Related discussion:
text: I'm going to be performing the calculation of when it's appropriate to evict/delete outside of the drain library, and I suspect most will be as well, so there's not really a great incentive to do it in the drain library itself IMO.
That's all good, I have no issue using the flag as long as does error out and return a non-zero code as expected (there's been a few times where it seems to error out, but still return 0)