jiebi/CodeConvo huggingface dataset:
Change:
//   - If a file is found, then retreives volumePluginDependentPath from globalMapPathUUID. //   - Once volumePluginDependentPath is obtained, store volume information to VolumeSource // examples: <del> //   mapPath: pods/{podUid}}/{DefaultKubeletVolumeDevicesDirName}/{escapeQualifiedPluginName}/{volumeName} </del> <ins> //   mapPath: pods/{podUid}/{DefaultKubeletVolumeDevicesDirName}/{escapeQualifiedPluginName}/{volumeName} </ins> //   globalMapPathUUID : plugins/kubernetes.io/{PluginName}/{DefaultKubeletVolumeDevicesDirName}/{volumePluginDependentPath}/{pod uuid} func (plugin *fcPlugin) ConstructBlockVolumeSpec(podUID types.UID, volumeName, mapPath string) (*volume.Spec, error) { pluginDir := plugin.host.GetVolumeDevicePluginDir(fcPluginName)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Currently, FC plugin returns volume name and empty FCVolumeSource during ConstrutVolumeSpec during . However, in order to recreate newMounter from volumeSpec, volume information are lacking. As a result, filesystem volume's reconstruction always fails. What you expected to happen: Filesystem volume's reconstruction works properly, then a volume is unmounted and detached from kubelet node. How to reproduce it (as minimally and precisely as possible): (1) Create filesystem volume using FC plugin (2) Restart kubelet service which a pod with FC volume is running Anything else we need to know?: cc Environment: Kubernetes version (use ):Install tools: local-cluster-
/assign
/sig storage
Change:
// newExecPodSpec returns the pod spec of exec pod func newExecPodSpec(ns, generateName string) *v1.Pod { <del> pod := NewAgnhostPod(ns, "agnhost-pod", nil, nil, nil) </del> <ins> // GenerateName is an optional prefix, used by the server, // to generate a unique name ONLY IF the Name field has not been provided pod := NewAgnhostPod(ns, "", nil, nil, nil) </ins> pod.ObjectMeta.GenerateName = generateName return pod }

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: ci-kubernetes-e2e-gce-scale-correctness Which test(s) are failing: [sig-network] Services should only allow access from service loadbalancer source ranges [Slow] Since when has it been failing: Constant failure from 2020-09-23 Testgrid link: Reason for failure: From Similar logs found in previous runs Anything else we need to know: There is open bug () for flakes, however this is not a flake, but a constant failure. /sig networking
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Which jobs are failing: ci-kubernetes-e2e-gce-scale-correctness [sig-network] Services should only allow access from service loadbalancer source ranges [Slow] Constant failure from 2020-09-23 From Similar logs found in previous runs There is open bug () for flakes, however this is not a flake, but a constant failure. 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 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 network
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/priority critical
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /priority critical 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
ok, I think I got it,
so, it seems the 500 error is generated because it is using GenerateName, but ti has the pod.Name hardcoded
So do we know if this is related to any single proxy mode or applies for all?

Trying to figure out how it relates to & since those were only pertaining to IPVS.
This is a new problem that affected the same test in all modes, it was not a network problem at the end The ipvs one was flaky before this, I'll reopen it
Change:
t.Errorf("error while waiting for pods in namespace %v: %v", ns, err) } } <ins> func waitForSchedulerCacheCleanup(sched *scheduler.Scheduler, t *testing.T) { schedulerCacheIsEmpty := func() (bool, error) { snapshot := sched.Cache().Snapshot() return len(snapshot.Nodes) == 0 && len(snapshot.AssumedPods) == 0, nil } if err := wait.Poll(time.Second, wait.ForeverTestTimeout, schedulerCacheIsEmpty); err != nil { t.Errorf("Failed to wait for scheduler cache cleanup: %v", err) } } </ins>

Discussion:
While lookint into , I spent few minutes looking into this test: And there is a problem that is relatively easy to reproduce. The problem is that we are running its test cases one by one. But nothing in the meantime is ensuring that the current state that the test assumes is reflected in scheduler. In particular the problem that I observed couple time is that: we finished one test case we call cleanupNodes [but we don't ensure that scheduler actually cleaned up this node] we start the next test case we try to schedule a pod that has some toleration (but shouldn't fit on our node) by accident the toleration make it fit on to the previous node so scheduler schedules it on the node from previous test case
/assign
Change:
nodeIPValidator: validateNodeIP, clock:           clock.RealClock{}, enableControllerAttachDetach:            kubeCfg.EnableControllerAttachDetach, <del> iptClient:                               utilipt.New(utilexec.New(), utildbus.New(), utilipt.ProtocolIpv4), </del> <ins> iptClient:                               utilipt.New(utilexec.New(), utildbus.New(), protocol), </ins> makeIPTablesUtilChains:                  kubeCfg.MakeIPTablesUtilChains, iptablesMasqueradeBit:                   int(kubeCfg.IPTablesMasqueradeBit), iptablesDropBit:                         int(kubeCfg.IPTablesDropBit),

Discussion:
/kind bug What happened: Kubelet uses "iptables" instead of "ip6tables" in an ipv6-only cluster. This causes failed traffic for services (and probably a lot of other problems). For instance the chain is created in but is missing in ; When a is assigned the fails; What you expected to happen: All components should use in a ipv6-only cluster. should work in an ipv6-only cluster. How to reproduce it (as minimally and precisely as possible): Start a ipv6-only cluster Check iptables Optional; try a service type: LoadBalancer Anything else we need to know?: is hard-coded in finc in "" Environment: Kubernetes version (use ):Cloud provider or hardware configuration: kvm VMs on Ubuntu 16.04 OS (e.g. from /etc/os-release): Own BusyBox system Kernel (e.g. ):Install tools: None Others:
/sig network
/area ipv6
Thanks for reporting this problem. I'll take a look.
is a link to the code with the hard-coded ipv4 protocol.
Thanks, I will send a pr to fix this issue.
/assign
I see this issue too. Also there is some related discussion with issue .
I just pulled the latest from master, and gave a try with IPv6 cluster, but I still see the error, when using kube-proxy + IPVS: E0829 16:51:56. 1 ] Failed to execute iptables-restore: exit status 2 (ip6tables-restore v1.4.21: The protocol family of set KUBE-LOOP-BACK is IPv4, which is not applicable. Were you able to try this with kube-proxy+IPVS?
Sorry, I didn't try ipv6 cluster with ipvs proxier. Those two issue are related, but not exactly the same issue. Seems we already have conclusion in , nobody working on that?
Change:
pod := toBeAttachedPod(f) _, err := client.CoreV1().Pods(f.Namespace.Name).Create(pod) Expect(err).To(BeNil()) <ins> err = framework.WaitForPodNameRunningInNamespace(client, pod.Name, f.Namespace.Name) Expect(err).NotTo(HaveOccurred()) </ins> By("'kubectl attach' the pod, should be denied by the webhook") <del> _, err = framework.NewKubectlCommand("attach", fmt.Sprintf("--namespace=%v", f.Namespace.Name), pod.Name, "-i", "-c=container1").Exec() </del> <ins> timer := time.NewTimer(30 * time.Second) defer timer.Stop() _, err = framework.NewKubectlCommand("attach", fmt.Sprintf("--namespace=%v", f.Namespace.Name), pod.Name, "-i", "-c=container1").WithTimeout(timer.C).Exec() </ins> Expect(err).NotTo(BeNil()) if e, a := "attaching to pod 'to-be-attached-pod' is not allowed", err.Error(); !strings.Contains(a, e) { framework.Failf("unexpected 'kubectl attach' error message. expected to contain %q, got %q", e, a)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig testing What happened: The test . This can happen more frequently when it has to pull the necessary image. Additionally, spawning and starting pods takes a bit longer on Windows nodes. â¢ Failure [88.631 seconds] [sig-api-machinery] AdmissionWebhook Should be able to deny attaching pod [It] Oct 8 16:36:05.987: unexpected 'kubectl attach' error message. expected to contain "attaching to pod 'to-be-attached-pod' is not allowed", got "error running &amp;{/usr/local/bin/kubectl [kubectl --server=https://k8s-cbelu- --kubeconfig=/home/ubuntu/kube/config6 attach --namespace=e2e-tests-webhook-d8clc to-be-attached-pod -i -c=container1] [] &lt;nilIf you don't see a command prompt, try pressing enter.nerror: unable to upgrade connection: container container1 not found in pod to-be-attached-pode2e-tests-webhook-d8clcn [] &lt;nil0xc0018941b0 exit status 1 &lt;nil&lt;niltrue [0xc0002d1808 0xc0002d1838 0xc0002d1860] [0xc0002d1808 0xc0002d1838 0xc0002d1860] [0xc0002d1820 0xc0002d1850] [0x92bfb0 0x92bfb0] 0xc00074dd40 &lt;nil}:nCommand stdout:nnstderr:nIf you don't see a command prompt, try pressing enter.nerror: unable to upgrade connection: container container1 not found in pod to-be-attached-pod_e2e-tests-webhook-d8clcnnerror:nexit status 1n" Additionally, the command could hang (if it actually managed to attach), causing the test to never end. The command should be executed with a timeout.

What you expected to happen: The test should wait for the pod to enter a state before trying to attach to it, so it won't randomly fail. The test should have a timeout when trying to attach to the pod. How to reproduce it (as minimally and precisely as possible): Run the test using Windows nodes and / or delete webhook image from the Compute Node's image cache. Anything else we need to know?: Environment: Kubernetes version (use ): v1.12.0-rc.2 Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): Windows Server 1803 compute nodes Kernel (e.g. ): N/A Install tools: N/A Others:
Change:
--quiet  --delete-disks all  --zone "${ZONE}"  <del> "${MASTER_NAME}" || true </del> <ins> "${MASTER_NAME}" </ins> # Delete the master pd (possibly leaked by kube-up if master create failed) gcloud compute disks delete  --project "${PROJECT}"  --quiet  --zone "${ZONE}"  <del> "${MASTER_NAME}"-pd || true </del> <ins> "${MASTER_NAME}"-pd </ins> # Find out what minions are running. local -a minions

Discussion:
'kubernetes-soak-weekly-deploy' sometimes fails to deploy because the clean-up cluster step fails to delete the template: Then the subsequent cluster step fails to create the template, because it already exists: It keeps retrying and failing, because the template already exists, until it times out and the deployment fails. Suggested fixes: Cluster down should try harder to delete the template (maybe wait/retry). Cluster up should recognize that the template exists, and try to delete/recreate, or just re-use the existing.
Looks like ran in to this on Monday, May 11, 2015 around 1:00 PM PST. I'll assign this to my self and take a crack at fixing it.
This is causing most of our e2e tests to fail in continuous integration as well as users private e2e test clusters. Bumping to priority/p0 and v1.0 milestone. Saad thinks he's figured it out, and is working on a fix as we speak.
In essence... Saad: "I think what's happening is the previous clean up step to delete the managed instance group happens asynchronously, therefore there is a race condition to delete the template. Working on a fix".
Change:
github.com/golang/mock v1.6.0 github.com/golangci/golangci-lint v1.51.2 github.com/google/go-flow-levee v0.1.5 <ins> go.uber.org/automaxprocs v1.5.2 </ins> gotest.tools/gotestsum v1.6.4 honnef.co/go/tools v0.4.2 sigs.k8s.io/logtools v0.4.1

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : should detect the appropriate GOMAXPROCS based off of the cpu limit supplied to the pod. Why is this needed: If not, test failures can occur (e.g. ) where GOMAXPROCS defaults to the number of cpus on the machine, while the cpu limit is actually far less. Too many compile/test processes launch, and any timing tests can become flaky. The end result is that running the test jobs on a node with more CPUs can make it flaky when running the test on a node with fewer CPUs cleanly passes. It's possible to set GOMAXPROCS=cpu limits in test jobs to avoid this, but it would be nicer if would autodiscover and set GOMAXPROCS appropriately.
/sig testing /sig k8s-infra
/transfer kubernetes
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
/assign dims
xref:
This is already done, which is great, but for some more info I did some benchmarking of setting GOMAXPROCs vs not: Pretty substantially better in some cases
Change:
// addTokenSecretReference adds a reference to the ServiceAccountToken that will be created func addTokenSecretReference(refs []v1.ObjectReference) []v1.ObjectReference { <del> return addNamedTokenSecretReference(refs, "default-token-p7w9c") </del> <ins> return addNamedTokenSecretReference(refs, "default-token-stdpg") </ins> } // addNamedTokenSecretReference adds a reference to the named ServiceAccountToken

Discussion:
/kind feature What happened: In playing with the nginx ingress controller deployment, I noticed the following pod name: nginx-ingress-controller--c0ck5 I figure we should possibly put something in place to prevent accidental l33t profanity ;-). What you expected to happen: The following pod name: nginx-ingress-controller--r0ck5
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
My first github (k8s) issue. I've no idea which SIG would cover this topic. /sig product-management
/sig api-machinery
Previously we removed vowels in . We can 3xt3nd the idea with 0, 1 (can stand for ) and 3. would you like to send a PR? If not, I can work on this.
/assign jamesawebb1
Reassign to me if you do not want to contribute a PR.
Change:
--port="$KUBELET_PORT"  --healthz_port="${KUBELET_HEALTHZ_PORT}" 1>&2 & KUBELET_PID=$! <del> kube::util::wait_for_url "http://127.0.0.1:${KUBELET_HEALTHZ_PORT}/healthz" "kubelet: " 0.2 25 </del> <ins> kube::util::wait_for_url "http://127.0.0.1:${KUBELET_HEALTHZ_PORT}/healthz" "kubelet(masterless)" </ins> kill ${KUBELET_PID} 1>&2 2>/dev/null kube::log::status "Starting kubelet in masterful mode"

Discussion:
Example:
Is kubelet healthz coupled with the docker daemon being accessible? ?
That particular error is coming from cAdvisor and should not be causing the test to block. The Kubelet does wait up to 5min for Docker to come up though. Do we use a real Docker in these tests?
Shippable is running on different os dist? ContainerOsVersion:Ubuntu precise?
Yes today kubelet healthz coupled with docker daemon. We even periodically healthcheck docker and kubelet, and restart them even there are issues.
Another example:
bumping priority because we have to get these flaky tests fixed.
This has been marked P0 for 2 months but hasn't had any updates. Is this still happening on Shippable? If so, can we just increase a timeout in the test?
This is ridiculous, I'll fix it myself.
Change:
return result } <del> func (t *timeBudget) periodicallyRefresh(stopCh <-chan struct{}) { </del> <ins> func (t *timeBudgetImpl) periodicallyRefresh(stopCh <-chan struct{}) { </ins> ticker := time.NewTicker(time.Second) defer ticker.Stop() for {

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: bazel-test-master (periodic-kubernetes-bazel-test-master ) Which test(s) are flaking: gotest: Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --cc
/sig api-machinery
This is continuing to be flaky with more recent failure:
/assign Would you mind taking a look here? thanks! /triage accepted
- can we somehow uncover when this started happening? This test is very old and it seems it started happening very recently, so it would be helpful to see when this started happening...
Triage shows flakes starting ~Sept 30: Before Sept 30 it seems the job was flaking much less frequently.
Might be related to I will take a look.
It seems it's not related to that PR (neither to the previous: ) As there were already failures like that on Sep 24th (before this one was merged). I will take a deeper look.
OK - it's not related to any changes mentioned before. I can reproduce this particular failure by simply adding somewhere in this block: So it's probably connected to cpu-starvation at the test level and the solution is to switch to less aggressive timeouts. Will send out a PR.
Actually - it appeared to be slightly more subtle then that. But I already fully understand the problem. It's purely test issue, but require a bit more changes (and I won't get to it today/tomorrow). I will send a fix for that early next week.
- if that changes anything from your tracking perspective ^^
No board changes yet - the next stage is "Observing" once this issue gets closed :) If you have time - I'd love to pick your brain/understand the error more thoroughly though! Hoping you drop a good explanation in your PR next week
Thanks for sharing those insights, on your discovery of the solution to this bug.
It seems the PR didn't address that fully. Looking.
out for review
Change:
LivenessProbe  *Probe               `json:"livenessProbe,omitempty"` ReadinessProbe *Probe               `json:"readinessProbe,omitempty"` Lifecycle      *Lifecycle           `json:"lifecycle,omitempty"` <del> // Optional: Defaults to /dev/termination-log </del> <ins> // Required. </ins> TerminationMessagePath string `json:"terminationMessagePath,omitempty"` // Optional: Default to false. Privileged bool `json:"privileged,omitempty"` <del> // Optional: Policy for pulling images for this container </del> <ins> // Required: Policy for pulling images for this container </ins> ImagePullPolicy PullPolicy `json:"imagePullPolicy"` // Optional: Capabilities for container. Capabilities Capabilities `json:"capabilities,omitempty"`

Discussion:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc
Change:
return waitForNodeToBe(c, name, false, timeout) } <ins> func isNodeReadySetAsExpected(node *api.Node, wantReady bool) bool { // Check the node readiness condition (logging all). for i, cond := range node.Status.Conditions { Logf("Node %s condition %d/%d: type: %v, status: %v", node.Name, i+1, len(node.Status.Conditions), cond.Type, cond.Status) // Ensure that the condition type is readiness and the status // matches as desired. if cond.Type == api.NodeReady && (cond.Status == api.ConditionTrue) == wantReady { Logf("Successfully found node %s readiness to be %t", node.Name, wantReady) return true } } return false } </ins> // waitForNodeToBe returns whether node name's readiness state matches wantReady // within timeout. If wantReady is true, it will ensure the node is ready; if // it's false, it ensures the node is in any state other than ready (e.g. not

Discussion:
I ran e2e tests against docker 1.7.0-rc2 release, found a bunch of issues. Here is one I think it belongs to kubernetes for sure. 1) ResizeNode test failed, the machine is removed from instance group: But kubectl get nodes still returns 3 ndoes: This might be caused by the new docker binary I am testing against here. This is not the issue I am filing here. 2) Now networking test is running later, I noticed that the test is putting a pod on each node: nettest-gwtc4 on node e2e-test-dawnchen-minion-5l11 I haven't checked networking code in detail yet, not sure the issue is test itself, or scheduler issue. cc/ since you recently changed this. cc/
The networking test doesn't use the scheduler, it manually fills in the host field.
Ok, then we should filter out NotReady nodes from testing; otherwise, the test itself has the dependencies on other tests.
Yes, that test is doing a questionable thing.
Agreed.
I implemented skipping not-ready nodes in . Is it enough to close this issue, or is there something else to be done here?
I think that should fix the issue. ?
status: waiting for merge of