jiebi/CodeConvo huggingface dataset:
Change:
What happened: I created a service where the was the same as the , and having done so, then the was not accessible externally on the Windows node where the pod was running (it was, however, accessible on the Linux master). When I changed either the or the so that they were different then the service was accessible on the Windows node. What you expected to happen: I expect services to work when the and the are the same value. How to reproduce it (as minimally and precisely as possible): Here's the file that I used: Then, in a web browser on my desktop machine, I visited the on both the Linux master's IP address, and then in a different tab, using the again, the IP address of the Windows worker node where that pod was scheduled. It only worked using the IP address of the Linux master. The tab using the Windows worker node's IP address did not load. Then, I changed either the or the so that they were different values, and when they were different, it worked using the of both the Linux master's IP address and the IP address of the Windows worker node where that pod was scheduled. Anything else we need to know?: On-premise install of k8s The Windows nodes all have the following feature gates enabled: WinOverlay WindowsGMSA Linux master: OS (e.g. ): Windows worker: If you need any more information then please let me know.
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
Can you take a look?

Discussion:
if len(elbPolicy.VIPs) == 0 || elbPolicy.VIPs[0] != vip { continue } <ins> } else if len(elbPolicy.VIPs) != 0 { continue </ins> } LogJson(plist, "Found existing Hns loadbalancer policy resource", 1) return &loadBalancerInfo{

if len(plist.FrontendVIPs) == 0 || plist.FrontendVIPs[0] != vip { continue } <ins> } else if len(plist.FrontendVIPs) != 0 { continue </ins> } LogJson(plist, "Found existing Hns loadbalancer policy resource", 1) return &loadBalancerInfo{
Change:
What happened: We will now always delete the pods from unschedulable queue no matter the Add operations succeed or not in function. What you expected to happen: Delete pods from unschedulable queue only when add operations succeeds
/sig scheduling
/assign
Will the pods be to the queues again somewhere if we delete them by mistake here ? It seems that can not make sure to add them again.
I am not sure if we will add them back again somewhere. If not, not only but also need to be updated. I have already send a PR here:

Discussion:
func (p *PriorityQueue) MoveAllToActiveQueue() { p.lock.Lock() defer p.lock.Unlock() <ins> // There is a chance of errors when adding pods to other queues, // we make a temporary slice to store the pods, // since the probability is low, we set its len to 0 addErrorPods := make([]*framework.PodInfo, 0) </ins> for _, pInfo := range p.unschedulableQ.podInfoMap { pod := pInfo.Pod if p.isPodBackingOff(pod) { if err := p.podBackoffQ.Add(pInfo); err != nil { klog.Errorf("Error adding pod %v to the backoff queue: %v", pod.Name, err) <ins> addErrorPods = append(addErrorPods, pInfo) </ins> } } else { if err := p.activeQ.Add(pInfo); err != nil { klog.Errorf("Error adding pod %v to the scheduling queue: %v", pod.Name, err) <ins> addErrorPods = append(addErrorPods, pInfo) </ins> } } } p.unschedulableQ.clear() <ins> // Adding pods that we could not move to Active queue or Backoff queue back to the Unschedulable queue for _, podInfo := range addErrorPods { p.unschedulableQ.addOrUpdate(podInfo) } </ins> p.moveRequestCycle = p.schedulingCycle p.cond.Broadcast() }

if p.isPodBackingOff(pod) { if err := p.podBackoffQ.Add(pInfo); err != nil { klog.Errorf("Error adding pod %v to the backoff queue: %v", pod.Name, err) <ins> } else { p.unschedulableQ.delete(pod) </ins> } } else { if err := p.activeQ.Add(pInfo); err != nil { klog.Errorf("Error adding pod %v to the scheduling queue: %v", pod.Name, err) <ins> } else { p.unschedulableQ.delete(pod) </ins> } } <del> p.unschedulableQ.delete(pod) </del> } p.moveRequestCycle = p.schedulingCycle p.cond.Broadcast()
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-storage] [Serial] Volume metrics should create metrics for total time taken in volume operations in P/V Controller Since when has it been failing: 6/1 Testgrid link: https://k8s- Reason for failure: Probably caused by Anything else we need to know:
cc
cc
this is possibly caused by renaming one label of the metric from "pluginname" to "volumeplugin". Having a fix under testing now
/assign
GitHub didn't allow me to assign the following users: yuxiangqian. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <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
Thanks for opening this let us know if we can help! /priority important-soon /milestone v1.15 /cc
is working on a fix
apologies for the late reply. fix PR is in for review

Discussion:
Help:    "Storage operation end to end duration in seconds", Buckets: []float64{.1, .25, .5, 1, 2.5, 5, 10, 15, 25, 50, 120, 300, 600}, }, <del> []string{"volume_plugin", "operation_name"}, </del> <ins> []string{"plugin_name", "operation_name"}, </ins> ) func init() {
Change:
What happened: made sure that API calls to Azure that return a HTTP code 200 with an embedded error are retried. Nevertheless, we observe a series of errors during the Azure Disk detach backoff while calling , and the detach operation is immediately cancelled. Happy scenario: the disk is to be re-attached to the same VM. The reconciler's will update the VMSS instance and the previous detach error will be masked. It takes 15 min for the detach call to timeout but the disk will eventually get re-attached after several VMSS updates (). Not-so-happy scenario: the disk is to be re-attached to another VM. The same errors as in will be thrown indefinitely. controller-manager's logs: What you expected to happen: The backoff succeeds and the failed detach operation gets retried. How to reproduce it: A single Pod with a single Azure Disk. This seems quite hard to reproduce, but it is happening consistently in one of our customer's resource group (eastus). Anything else we need to know?: Environment: Kubernetes version: branch (kubernetes/kubernetes Cloud provider: Azure (via AKS-Engine) OS: Ubuntu 16.04.6 LTS Kernel: 4.15.0-1042-azure Install tools: Network plugin and version: Others: /sig azure paging
/assign

Discussion:
} if !bFoundDisk { <del> return nil, fmt.Errorf("detach azure disk failure, disk %s not found, diskURI: %s", diskName, diskURI) </del> <ins> // only log here, next action is to update VM status with original meta data klog.Errorf("detach azure disk: disk %s not found, diskURI: %s", diskName, diskURI) </ins> } newVM := compute.VirtualMachine{

package azure import ( <del> "fmt" </del> "net/http" "strings"

} if !bFoundDisk { <del> return nil, fmt.Errorf("detach azure disk failure, disk %s not found, diskURI: %s", diskName, diskURI) </del> <ins> // only log here, next action is to update VM status with original meta data klog.Errorf("detach azure disk: disk %s not found, diskURI: %s", diskName, diskURI) </ins> } newVM := compute.VirtualMachineScaleSetVM{
Change:
--cleanup-ipvs is a default-true flag. If set to false, will skip flushing IPVS rules. It has no impact to normal operation. "Partial cleanup" feels like a footgun, and I can't find a compelling reason why a user would want to run cleanup, but skip IPVS. I suspect this is a holdover from when autocleanup ran on-boot, before . To do this ticket: Deprecate the existing flag. You will find examples of deprecated flags in the 1.15 branch and behind.
asked to do this, assuming this is something we're actually okay to deprecate. /sig network /kind cleanup /priority backlog
CC would appretiate a sanity check on the admin implications. :)
I will take this. Correct me if I am wrong, we deprecate the flag but the IPVS flushing will happen by default in the background whenever the user runs the ?
the issue has already been "claimed", pending a sanity check. Deprecating the flag would entail always flushing IPVS on .
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/good-first-issue
/assign is it ok to be deprecated now?
Um.. I have done it and just ask for a confirm to deprecate it. By the way, you shouldn't only delete the flag.
Great! No problems I'll follow this issue and check your Pull Request to learn more about this desprecation scenario :+1:
could you please rename the issue as

Discussion:
fs.BoolVar(&o.CleanupAndExit, "cleanup", o.CleanupAndExit, "If true cleanup iptables and ipvs rules and exit.") fs.BoolVar(&o.CleanupIPVS, "cleanup-ipvs", o.CleanupIPVS, "If true and --cleanup is specified, kube-proxy will also flush IPVS rules, in addition to normal cleanup.") <ins> fs.MarkDeprecated("cleanup-ipvs", "In a future release, running --cleanup will always flush IPVS rules") </ins> fs.Var(utilflag.IPVar{Val: &o.config.BindAddress}, "bind-address", "The IP address for the proxy server to serve on (set to `0.0.0.0` for all IPv4 interfaces and `::` for all IPv6 interfaces)") fs.Var(utilflag.IPVar{Val: &o.config.HealthzBindAddress}, "healthz-bind-address", "The IP address for the health check server to serve on (set to `0.0.0.0` for all IPv4 interfaces and `::` for all IPv6 interfaces)")
Change:
Using the list of tested stable endpoints referenced in , we can pick out the endpoints which are part of the ConfigMap kind: This is a stable core endpoint which has existing testing, potentially making for low-hanging fruit to upgrade to Conformance. /area test /area conformance /sig testing
/assign
Promoting will increase Conformance Coverage by 1 endpoint.
PR was closed because AdmissionWebHook is not yet GA. /close
You can't close an active issue/PR unless you authored it or you are a collaborator. <detailsIn response to : PR was closed because AdmissionWebHook is not yet GA. 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
This test uses a beta version of the API. According to the , this is prohibited. The URL of the API which is test is hitting is .
/unassign The original PR was superseded by 's

Discussion:
import ( "fmt" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework"

configMap, err := newConfigMapWithEmptyKey(f) framework.ExpectError(err, "created configMap %q with empty key in namespace %q", configMap.Name, f.Namespace.Name) }) <ins> ginkgo.It("should patch ConfigMap successfully", func() { name := "configmap-test-" + string(uuid.NewUUID()) configMap := newConfigMap(f, name) ginkgo.By(fmt.Sprintf("Creating configMap %v/%v", f.Namespace.Name, configMap.Name)) _, err := f.ClientSet.CoreV1().ConfigMaps(f.Namespace.Name).Create(configMap) framework.ExpectNoError(err) configMap.Data = map[string]string{ "data": "value", } ginkgo.By(fmt.Sprintf("Updating configMap %v/%v", f.Namespace.Name, configMap.Name)) _, err = f.ClientSet.CoreV1().ConfigMaps(f.Namespace.Name).Update(configMap) framework.ExpectNoError(err) configMapFromUpdate, err := f.ClientSet.CoreV1().ConfigMaps(f.Namespace.Name).Get(name, metav1.GetOptions{}) framework.ExpectNoError(err) ginkgo.By(fmt.Sprintf("Verifying update of configMap %v/%v", f.Namespace.Name, configMap.Name)) framework.ExpectEqual(configMapFromUpdate.Data, configMap.Data) }) </ins> }) func newEnvFromConfigMap(f *framework.Framework, name string) *v1.ConfigMap {
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: N/A Which test(s) are failing: [sig-auth] [Feature:NodeAuthorizer] A node shouldn't be able to create another node Since when has it been failing: N/A Testgrid link: N/A Reason for failure: The test creates a new ` node, but it does not delete it after the test ends: kubectl get nodes NAME STATUS ROLES AGE VERSION 1954k8s000 Ready agent 24d v1.14.1 1954k8s001 Ready agent 24d v1.14.1 foo NotReady <none4m3s k8s-master--0 Ready master 24d v1.14.1 Anything else we need to know: /sig testing
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
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
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-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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

Discussion:
} ginkgo.By(fmt.Sprintf("Create node foo by user: %v", asUser)) _, err := c.CoreV1().Nodes().Create(context.TODO(), node, metav1.CreateOptions{}) <ins> // NOTE: If the test fails and a new node IS created, we need to delete it. If we don't, we'd have // a zombie node in a NotReady state which will delay further tests since we're waiting for all // tests to be in the Ready state. defer func() { f.ClientSet.CoreV1().Nodes().Delete(context.TODO(), node.Name, metav1.DeleteOptions{}) }() </ins> framework.ExpectEqual(apierrors.IsForbidden(err), true) })
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : If I have a that has a resource and I describe the namespace, I see that CPU and Memory limits/requests are present for the namespace, but a confusing "No resource limits." message is present at the bottom. Ex. I would like to see this "No resource limits." message replaced with something that makes it more clear to the user what is missing or not in use (since it's not apparently cpu or memory limits). From poking around the source code, the message stems from and seems to be intended to describe whether a resource is present or not. But from how it reads, it seems to be very vague and a user could easily assume that it refers to cpu and memory for the namespace instead. Why is this needed: Users using kubectl to inspect their namespace can be easily confused and either think that their namespace is missing a ResourceQuota or that conflicting information about CPU and memory resource limits for the namespace is being presented.
/sig cli
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
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-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten

Discussion:
// DescribeLimitRanges merges a set of limit range items into a single tabular description func DescribeLimitRanges(limitRanges *corev1.LimitRangeList, w PrefixWriter) { if len(limitRanges.Items) == 0 { <del> w.Write(LEVEL_0, "No resource limits.n") </del> <ins> w.Write(LEVEL_0, "No LimitRange resource.n") </ins> return } w.Write(LEVEL_0, "Resource Limitsn TypetResourcetMintMaxtDefault RequesttDefault LimittMax Limit/Request Ration")
Change:
What happened: that uses Ubuntu image fails during Kubernetes installation: Full log: Indeed, is not present on nodes. Only and subdirectories are present in . I don't know what code removed (or did not package) and symlinks, but they should be there. What you expected to happen: Kubernetes is installed correctly and e2e tests start. How to reproduce it (as minimally and precisely as possible): Run in a PR. Anything else we need to know?: Prow job: It seems to be the only one that uses Ubuntu image. This command works and installs Kubernetes correctly: is present there. Dunno what the prow job does differently.
/sig testing
the nodes receive files staged via the release scripts and downloaded by the cluster/ scripts, I don't think sig testing will be the right group to fix this. SIG node has some owners related to the various images that might have some idea how this is setup
/sig release this is probably an issue in the release scripts
cc:
PTAL, it looks like a stupid bug somewhere.
Q: Did this ever run successfully?
Most probably not, I haven't found a working e2e tests on Ubuntu. Still, works well, there must be something slightly different in test setup scripts.
ping again? Short recap: This works: is there. ( is symlink to ) This does not work: Fails with: does not exist. The prow job must do something slightly different than kube-
The serial job is using GCI (COS): Is the non-serial job working? It uses ubuntu: If not, my guess from the last time I remember looking was checking the release bundle and ensuring it includes the ubuntu dir
No, same error. created by contains , released bundles (e.g. ) contains it too. Otherwise would not work with an Ubuntu image. So what does the prow job differently? Does something there prune the scripts? is just a symlink to , does it make a difference?
Found it, creates without any symlinks. It looks like bazel limitation. I filled to explicitly create the symlinks when tarball is created. BTW, if and use different way to produce tarballs, who / when tests the ones created by ?
Most of CI is using make release or equivalent. Presumbit uses bazel. Jan Šafránek <:
/area release-eng /milestone v1.16 /priority important
/priority important-soon

Discussion:
extension = "tar.gz", package_dir = "kubernetes", strip_prefix = "//", <ins> symlinks = { "kubernetes/cluster/gce/cos/": "gci", "kubernetes/cluster/gce/custom/": "gci", "kubernetes/cluster/gce/ubuntu/": "gci", }, </ins> tags = ["no-cache"], deps = [ ":_full_server",

http_archive( name = "io_k8s_repo_infra", <del> sha256 = "462dcc769f29e9eee16499edb818e2fc2ffc24efea28300d53bbc098d27d322c", strip_prefix = "repo-infra-f85734f673056977d8ba04b0386394b684ca2acb", urls = mirror("https://github.com/kubernetes/repo-infra/archive/f85734f673056977d8ba04b0386394b684ca2acb.tar.gz"), </del> <ins> sha256 = "f6d65480241ec0fd7a0d01f432938b97d7395aeb8eefbe859bb877c9b4eafa56", strip_prefix = "repo-infra-9f4571ad7242bf3ec4b47365062498c2528f9a5f", urls = mirror("https://github.com/kubernetes/repo-infra/archive/9f4571ad7242bf3ec4b47365062498c2528f9a5f.tar.gz"), </ins> ) http_archive(
Change:
<!-- 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: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment:
/sig apps
/assign
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
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-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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

Discussion:
case !shouldContinueRunning && exists: // If daemon pod isn't supposed to run on node, but it is, delete all daemon pods on node. for _, pod := range daemonPods { <ins> if pod.DeletionTimestamp != nil { continue } </ins> podsToDelete = append(podsToDelete, pod.Name) } }