jiebi/CodeConvo huggingface dataset:
Change:
ConfigSyncPeriod metav1.Duration } <del> // Currently two modes of proxying are available: 'userspace' (older, stable) or 'iptables' // (newer, faster). If blank, use the best-available proxy (currently iptables, but may // change in future versions).  If the iptables proxy is selected, regardless of how, but // the system's kernel or iptables versions are insufficient, this always falls back to the // userspace proxy. </del> <ins> // Currently, four modes of proxying are available total: 'userspace' (older, stable), 'iptables' // (newer, faster), 'ipvs', and 'kernelspace' (Windows only, newer). // // If blank, use the best-available proxy (currently iptables, but may change in // future versions). If the iptables proxy is selected, regardless of how, but // the system's kernel or iptables versions are insufficient, this always falls // back to the userspace proxy. </ins> type ProxyMode string const ( <del> ProxyModeUserspace ProxyMode = "userspace" ProxyModeIPTables  ProxyMode = "iptables" ProxyModeIPVS      ProxyMode = "ipvs" </del> <ins> ProxyModeUserspace   ProxyMode = "userspace" ProxyModeIPTables    ProxyMode = "iptables" ProxyModeIPVS        ProxyMode = "ipvs" ProxyModeKernelspace ProxyMode = "kernelspace" </ins> ) // IPVSSchedulerMethod is the algorithm for allocating TCP connections and

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When running , and passing the flag which was introduced in , the following error occurs: What you expected to happen: The proxy should work as it used to, supporting this mode. How to reproduce it (as minimally and precisely as possible): ./kube- --proxy-mode=kernelspace Anything else we need to know?: This was introduced after the validation was refactored in which regressed validation for . IPVS validation (and thus support) was later , but we need another mode for Windows. Environment: Kubernetes version (use ): v1.10.0-alpha.0.684+ Cloud provider or hardware configuration: n/a OS (e.g. from ): Windows Server Core 1709 Kernel (e.g. ): Install tools: Others:
/sig windows /sig network
Tentatively adding milestone so we can track getting consensus on release-blocking status.
/priority critical-urgent
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
# Get default service account credentials of the VM. GCE_METADATA_INTERNAL="http://metadata.google.internal/computeMetadata/v1/instance" function get-credentials { <del> curl --fail --retry 5 --retry-delay 3 ${CURL_RETRY_CONNREFUSED} --silent --show-error "${GCE_METADATA_INTERNAL}/service-accounts/default/token" -H "Metadata-Flavor: Google" -s | python -c  </del> <ins> curl --fail --retry 5 --retry-delay 3 ${CURL_RETRY_CONNREFUSED} --silent --show-error "${GCE_METADATA_INTERNAL}/service-accounts/default/token" -H "Metadata-Flavor: Google" -s | ${PYTHON} -c  </ins> 'import sys; import json; print(json.loads(sys.stdin.read())["access_token"])' }

Discussion:
What happened: Pick an OS image where python is python3 and the cluster will not come up. What you expected to happen: Cluster should come up. How to reproduce it (as minimally and precisely as possible): Switch the default OS image to use an OS which has python3 as the default python. Run cluster/kube- for GCE. 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 cloud-provider
/assign
Change:
var listener net.Listener addresses := hcs.nodeAddresses.List() <del> hcI.listeners = make([]net.Listener, 0, len(addresses)) </del> hcI.httpServers = make([]httpServer, 0, len(addresses)) // for each of the node addresses start listening and serving

Discussion:
When a LoadBalancer Service with Local ExternalTrafficPolicy was deleted normally, an error log "use of closed network connection" was always generated in kube-proxy log, which confused people that there was something wrong: Do not generate error log when it's expected. a LoadBalancer Service with Local ExternalTrafficPolicy it No response <detailsv1.26.0 </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 network
Change:
defer stopFn() // Run scheduler. <del> informerFactory.Start(ctx.Done()) informerFactory.WaitForCacheSync(ctx.Done()) go scheduler.Run(ctx) </del> <ins> informerFactory.Start(tCtx.Done()) informerFactory.WaitForCacheSync(tCtx.Done()) go scheduler.Run(tCtx) </ins> // Send pods to be scheduled. for _, p := range tc.waitSchedulingPods { <del> _, err = fakeClient.CoreV1().Pods("").Create(ctx, p, metav1.CreateOptions{}) </del> <ins> _, err = fakeClient.CoreV1().Pods("").Create(tCtx, p, metav1.CreateOptions{}) </ins> if err != nil { t.Fatal(err) }

Discussion:
/kind failing-test /kind flake First seen in an unrelated PR, but also occurs in periodic jobs. /sig scheduling
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 This feature is reverted once, and I fixed the flake, I'm cherry-pick that back again.
Change:
func (o *createContextOptions) complete(cmd *cobra.Command) error { args := cmd.Flags().Args() if len(args) != 1 { <del> cmd.Help() return fmt.Errorf("Unexpected args: %v", args) </del> <ins> return helpErrorf(cmd, "Unexpected args: %v", args) </ins> } o.name = args[0]

Discussion:
The '-context' does not seem to add any value
add priority and team please.
Blocked on
/sig cli
Change:
} if _, exists := configMap.Data[keyName]; exists { <del> return fmt.Errorf("cannot add key %s, another key by that name already exists in data: %v", keyName, configMap.Data) </del> <ins> return fmt.Errorf("cannot add key %q, another key by that name already exists in Data for ConfigMap %q", keyName, configMap.Name) </ins> } if _, exists := configMap.BinaryData[keyName]; exists { <del> return fmt.Errorf("cannot add key %s, another key by that name already exists in binaryData: %v", keyName, configMap.BinaryData) </del> <ins> return fmt.Errorf("cannot add key %q, another key by that name already exists in BinaryData for ConfigMap %q", keyName, configMap.Name) </ins> } return nil }

Discussion:
What happened: What you expected to happen: Human readable error output. Anything else we need to know?: The same is happening when in duplicate key while creating a with binaries. !!! The error output will be all the of the binary itself !!! Environment: Kubernetes version (use ):
/sig cli
/cc
Change:
} csiAttacher := attacher.(*csiAttacher) <ins> // FIXME: We need to ensure this goroutine exits in the test. </ins> go func(spec *volume.Spec, nodename string, fail bool) { attachID, err := csiAttacher.Attach(spec, types.NodeName(nodename)) if fail != (err != nil) {

Discussion:
Which test(s) are flaking: TestAttacherWithCSIDriver Reason for failure: This is flaking rarely enough that it is not caught by our CI jobs, which currently tolerate up to 2 unit test failures per run (!). With that toleration removed in , this flake has been seen (). Reproducible with the following steps: a test binary for the affected package: the affected test using the tool (setting the timeout to a generous timeout relative to the normal test runtime of .02 seconds): failures are seen, look at the logs to see the details about the error: /sig storage cc
/assign can you help investigate this flake?
I have found the root cause. /assign
filed to address this issue.
Change:
<del> {% set cluster_state = 'new' -%} {% set host_name = pillar.get('master_name', '') -%} {% set etcd_cluster_array = pillar.get('initial_etcd_cluster', '').split(',') -%} {% set etcd_cluster = '' -%} {# We use vars dictionary to pass variables set inside the for loop, because jinja defines new variables inside the for loop that hide variables from the outside. #} {% set vars = {'etcd_cluster': '', 'cluster_state': cluster_state} -%} {% for host in etcd_cluster_array -%} {% if etcd_cluster != '' -%} {% set cluster_state = 'existing' -%} {% set etcd_cluster = etcd_cluster ~ ',' -%} {% endif -%} {% set etcd_cluster = etcd_cluster ~ 'etcd-' ~ host ~ '=http://' ~ host ~ ':' ~ server_port -%} {% do vars.update({'etcd_cluster': etcd_cluster, 'cluster_state': cluster_state}) -%} {% endfor -%} {% set etcd_cluster = vars.etcd_cluster -%} {% set cluster_state = vars.cluster_state -%} </del> { "apiVersion": "v1", "kind": "Pod",

Discussion:
test grid: Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Additional Context:
/sig release
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
cc Do we want to keep this job and fix it, or do something different considering the debs/rpms efforts?
I think we should keep this job as long as we build packages for Google infra (those are using different specs then packages for OBS).
fixed it for debs: The corresponding RPM job is also faster now:
Change:
) func TestTimeBudget(t *testing.T) { <del> budget := &timeBudget{ </del> <ins> budget := &timeBudgetImpl{ </ins> budget:    time.Duration(0), maxBudget: time.Duration(200), }

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:
// TODO: Get rid of [DisabledForLargeClusters] tag when issue #56138 is fixed. It("should be able to switch session affinity for LoadBalancer service with ESIPP on [Slow] [DisabledForLargeClusters]", func() { <ins> // L4 load balancer affinity `ClientIP` is not supported on AWS ELB. framework.SkipIfProviderIs("aws") </ins> svc := getServeHostnameService("service") svc.Spec.Type = v1.ServiceTypeLoadBalancer svc.Spec.ExternalTrafficPolicy = v1.ServiceExternalTrafficPolicyTypeLocal

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?: What happened: What you expected to happen: The test should either succeed or be skipped on AWS How to reproduce it (as minimally and precisely as possible): Run this test on an AWS cluster with the AWS cloud provider configured Anything else we need to know?: The test sets the service's session affinity to here: The AWS cloud provider specifically only supports : Environment: Kubernetes version (use ): Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
cc
/cc
Thanks for the investigation, given the information so far, we should just skip this test on AWS. Will prepare a PR soon.
Change:
echo "$ brew install md5sha1sum bash jq" fi echo <ins> exit 9 </ins> fi # This variable can be injected, as in the verify script.

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?: What happened: tried to update godeps on mac OSX Eventual error out with osx bash is old and doesn't know what the flag is for declare. What you expected to happen: successfully finish running the scripts How to reproduce it (as minimally and precisely as possible): see above Anything else we need to know?: Environment: OS (e.g. from /etc/os-release): mac os 10.13.5
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
/cc since you use a mac
/cc
What version of OSX and what version of bash are you using?
The licenses script is important but horrible.
worked last time I tried (some days ago, on 10.13.5.
Default bash version in OSX is pretty old, you can check your current version with The option is only available on version 4 or newer, so you have to install a new bash version The shebang line in the script will use the first bash in your PATH, which should be the new one.
so this error is actually being thrown by . there's actually a version check in that script to ensure you're running bash 4 () I'm curious though.. because you have declare, but just not the -A flag... but somehow you're passing the version check, which I know fails on bash 3 (just tested it). Seems weird.
I think that the problem is that there is no inside the sentence so it warns the user but it continues running.
huh, you're right. I do have bash 4. I think I have an incorrect root cause. I made assumptions. My apologies. I'll try and take another look at it next week.
Change:
By("verifying PD is present in node0's VolumeInUse list") framework.ExpectNoError(waitForPDInVolumesInUse(nodeClient, diskName, host0Name, nodeStatusTimeout, true /* should exist*/)) <del> if nodeOp == deleteNode { </del> <ins> if disruptOp == deleteNode { </ins> By("getting gce instances") gceCloud, err := framework.GetGCECloud() framework.ExpectNoError(err, fmt.Sprintf("Unable to create gcloud client err=%v", err))

Discussion:
When pod is evicted, pod is terminated. After this change , attach/detach controller should be able to detach the pod correctly so that new pod which uses the same volume will start up. We need to have an e2e test for this scenario.
what environment is good for this e2e test? GCE or GKE or AWS? I see we have which has func, Can you comment on why is insufficient to cover this issue?
does the pod need to be evicted? Or would be ok to delete the pod and then check that the PD is detached. Then create a new pod using the same PD and test that it attaches?
[MILESTONENOTIFIER] Milestone Removed Important: This issue was missing labels required for the v1.9 milestone for more than 3 days: kind: Must specify exactly one of , or . <details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
ping ^^
sorry for the delay. Here we want to test the detach behavior of evicted pods. So delete a pod directly is different from it. When Pod is evicted, the containers will be killed and the pod status is terminated. But the pod api object is not deleted from API server. Before PR , such evicted pods will not trigger detach operation because the pod api object is not deleted from api server. So the purpose of the test is to make sure detach operation is triggered for such evicted pods.
Thanks Do you have a suggestion for how to force a pod to be evicted?
You could have the pod do some memory intensive application
ah, like my use of in the io-streaming pr :-)
- Here's another option to cause eviction: .
Change:
--image "${MASTER_IMAGE}"  --tags "${MASTER_TAG}"  --network "${NETWORK}"  <del> --scopes "storage-ro" "compute-rw"  </del> <ins> --scopes "storage-ro,compute-rw"  </ins> --can-ip-forward  --metadata-from-file  <del> "startup-script=${KUBE_ROOT}/cluster/gce/configure-vm.sh"  "kube-env=${KUBE_TEMP}/master-kube-env.yaml"  --disk name="${MASTER_NAME}-pd" device-name=master-pd mode=rw boot=no auto-delete=no </del> <ins> "startup-script=${KUBE_ROOT}/cluster/gce/configure-vm.sh,kube-env=${KUBE_TEMP}/master-kube-env.yaml"  --disk "name=${MASTER_NAME}-pd,device-name=master-pd,mode=rw,boot=no,auto-delete=no" </ins> } # TODO(mbforbes): Make $1 required.

Discussion:
This happens over and over. Scary messages. WARNING: Lists should be separated by commas, try "--allow=tcp,udp,icmp,esp,ah,sctp". If you intend to use udp, icmp, esp, ah, sctp for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--scopes=storage-ro,compute-rw". If you intend to use compute-rw for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--metadata-from-file=startup-script=/usr/local/google/home/thockin/src/kubernetes/hack/e2e-internal/../../cluster/../cluster/gce/../../cluster/../cluster/gce/configure-,kube-env=/tmp/kubernetes.MURmzX/master-kube-". If you intend to use kube-env=/tmp/kubernetes.MURmzX/master-kube- for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--disk=name=e2e-test-thockin-master-pd,device-name=master-pd,mode=rw,boot=no,auto-delete=no". If you intend to use device-name=master-pd, mode=rw, boot=no, auto-delete=no for positional arguments, put them before the flag.
That's a new one. gcloud started getting a little more anal here. Exciting. cc
They changed list argument syntax a while back, but the warnings are new. Time to update startup scripts I guess.
Change:
volumeName, err := framework.CreatePDWithRetry() Expect(err).NotTo(HaveOccurred()) defer func() { <del> framework.ExpectNoError(framework.DeletePDWithRetry(volumeName)) </del> <ins> // - Get NodeName from the pod spec to which the volume is mounted. // - Force detach and delete. pod, err := f.PodClient().Get(config.Prefix+"-client", metav1.GetOptions{}) Expect(err).NotTo(HaveOccurred(), "Failed getting pod %q.", config.Prefix+"-client") detachAndDeletePDs(volumeName, []types.NodeName{types.NodeName(pod.Spec.NodeName)}) </ins> }() defer func() {

Discussion:
https://k8s-
See flakes on . This test needs to be quarantined until it's deflaked.
This test has been moved in the flaky suite ()
Could you please help triage and fix this test? CC
and I are looking into it...
After comparing the relevant passing and failing test logs in the Flaky suite, this appears to just be a timing issue. doesn't give the PD enough time to detach (5 min timeout). Adding above the delete allows a 10 minute detach window before deletion. This is the pattern we've used in other GCEPD tests and have yet to see similar flakes. I'll have a PR up in a bit to add the detach wait. If there's not more flakes for a week after it's merged, I'll submit a PR to pull the Flaky tag.
So I notice this happens when I upgrade a deployment that moves the pod to another node. I can pretty much recreate it at will now. Is the solution to wait 5 minutes before allowing a pod to be created after it was deleted?
After checking the log, there is something wrong at the node side when reconciler tries to unmount the device (global mount path) because there are still some references to the mount. But unmounting local mount point is successfully. Need to investigate more about this issue.
Change:
NumberAvailable:        1, }, <del> msg:  "Waiting for rollout to finish: 1 of 2 updated pods are available...n", </del> <ins> msg:  "Waiting for daemon set "foo" rollout to finish: 1 of 2 updated pods are available...n", </ins> done: false, }, {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: In our CI, we run multiple times in parallel when we update multiple deployments. This lets us see the status of all deployments as they run. When a deployment succeeds, the final message tells us the name of the deployment. However, the intermediate "Waiting for rollout to finish" messages do not say the name of the deployment. This means that in order to look at multiple rollouts in parallel, we need to manually pipe through another command to prefix it with the rollout name. What you expected to happen: Each line to mention the rollout name. How to reproduce it (as minimally and precisely as possible): Update any deployment, run , note that intermediate status names don't contain the deployment name. Anything else we need to know?: Arguably another fix would be to allow you to pass multiple rollouts to and have kubectl handle polling multiple deployments in parallel. Environment: This is still true on master by code inspection.
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