jiebi/CodeConvo huggingface dataset:
Change:
} if isManagedDisk { managedDisk := &compute.ManagedDiskParameters{ID: &diskURI} <ins> if diskEncryptionSetID == "" { if vm.StorageProfile.OsDisk != nil && vm.StorageProfile.OsDisk.ManagedDisk != nil && vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet != nil && vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet.ID != nil { // set diskEncryptionSet as value of os disk by default diskEncryptionSetID = *vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet.ID } } </ins> if diskEncryptionSetID != "" { managedDisk.DiskEncryptionSet = &compute.DiskEncryptionSetParameters{ID: &diskEncryptionSetID} }

Discussion:
<!-- 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: Azure data disk should use same encryption key as os disk if key is not provided by user, otherwise user would mess up with too many keys What you expected to happen: How to reproduce it (as minimally and precisely as possible): 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Change:
"fmt" "os" "path/filepath" <ins> "strings" </ins> ) // FindInPath returns the full path of the plugin by searching in the provided path

Discussion:
is identified with with severity rating as high. This is found using snyk scan while running against k/k master We're not using directly however, it gets tagged for vulnerability scans as we use . The fix is already present in and we can bump the dep. Bump dep to which has the mentioned CVE fix. and check Kubernetes version (use ): n/a Cloud provider or hardware configuration: any OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: n/a Network plugin and version (if this is a network-related bug): n/a Others: n/a /sig architecture /area code-organization for the dependency
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
Change:
return result, nil } if resourceVersion < oldest { <del> return nil, fmt.Errorf("too old resource version: %d (%d)", resourceVersion, oldest) </del> <ins> return nil, errors.NewInternalError(fmt.Errorf("too old resource version: %d (%d)", resourceVersion, oldest)) </ins> } // Binary seatch the smallest index at which resourceVersion is not smaller than

Discussion:
We sorta fixed this-- now it's a real status error, but we left the status code 500, so it still produces stack traces and potentially confuses clients. we should figure out the correct status code.
I think there is a lot more going on related to this in . Clients are re-listing after the error but not rewatching.
/sub
It turned out this was not causing job e2e flakes. Just sending 500s that were confusing. So lowering priority.
How about a NewBadRequest error?
that certainly sounds like an improvement.
Change:
buf.ReadFrom(rc) hostsFileContent := buf.String() <del> if !strings.Contains(hostsFileContent, "123.45.67.89tfoo") || !strings.Contains(hostsFileContent, "123.45.67.89tbar") { </del> <ins> if !strings.Contains(hostsFileContent, "123.45.67.89tfootbar") { </ins> return fmt.Errorf("expected hosts file to contain entries from HostAliases. Got:n%+v", hostsFileContent) }

Discussion:
What would you like to be : Currently, specifying multiple aliases for a single host using results in a line for each alias in . Example: leads to an file containing something like Why is this needed: Having multiple entries for the same IP address in can break DNS resolution for some software. See for more details <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/sig node
Change:
} By("Waiting for the target pod to stop running") <del> if err := f.WaitForPodNoLongerRunning(pod.Name); err != nil { framework.Failf("Pod did not stop running: %v", err) } </del> <ins> waitErr := f.WaitForPodNoLongerRunning(pod.Name) </ins> By("Retrieving logs from the target pod") logOutput, err := framework.GetPodLogs(f.Client, f.Namespace.Name, pod.Name, "portforwardtester")

Discussion:
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
So far I haven't found anything in the logs. The pfpod container starts, the e2e test receives all the data from it. At that time, the container should exit and the pod should be stopped. For some reason, either the container doesn't stop, or the kubelet doesn't see it stop. It's hard to tell which because the logs don't have enough information to make that determination.
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
Might be the same issue as
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
Builds: kubernetes-e2e-gce-etcd3 kubernetes-e2e-gci-gce Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
Adding to assignee list b/c of ssh tunnel flakes (i.e.

this issue has multiple, different root causes)
Builds: ci-kubernetes-e2e-gce-etcd3 ci-kubernetes-e2e-gci-gce-etcd3 ci-kubernetes-e2e-gci-gce-proto kubernetes-e2e-gce-etcd3 kubernetes-e2e-gci-gce-kubenet kubernetes-e2e-gci-gce-proto kubernetes-e2e-gci-gce-release-1.4 kubernetes-e2e-gci-gke-prod-smoke Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Port forwarding [] With a server that expects a client request should support a client that connects, sends no data, and disconnects [Conformance] {Kubernetes e2e suite}
Closing this issue as the corresponding test has been removed from cc:
Change:
], ) <ins> go_test( name = "go_default_test", srcs = ["azure_auth_test.go"], embed = [":go_default_library"], deps = [ "//vendor/github.com/Azure/go-autorest/autorest/adal:go_default_library", "//vendor/github.com/Azure/go-autorest/autorest/azure:go_default_library", "//vendor/github.com/stretchr/testify/assert:go_default_library", ], ) </ins> filegroup( name = "package-srcs", srcs = glob(["**"]),

Discussion:
<!-- 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: There are no unit tests yet for pkg , we should add unit tests. What you expected to happen: How to reproduce it (as minimally and precisely as possible): 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:
/assign
Change:
// Verify PodReady is not set (since sandboxcreation is blocked) _, err = getTransitionTimeForPodConditionWithStatus(p, v1.PodReady, false) framework.ExpectNoError(err) <del> ginkgo.By("update pod related volume resource to unblock sandbox creation") e2epod.NewPodClient(f).Update(ctx, p.Name, func(pod *v1.Pod) { pod.Spec.Volumes = []v1.Volume{ { Name: "secret", VolumeSource: v1.VolumeSource{ Secret: &v1.SecretVolumeSource{ SecretName: "secret", }, }, }, } pod.Spec.Containers[0].VolumeMounts = []v1.VolumeMount{ { Name:      "secret", MountPath: "/config", }, } }) // Verify PodReadyToStartContainers is set (since sandboxcreation is unblocked) if checkPodReadyToStart { _, err = getTransitionTimeForPodConditionWithStatus(p, v1.PodReadyToStartContainers, true) framework.ExpectNoError(err) } </del> } }

Discussion:
Two serial tests from sig-node are keep failing: E2eNode Suite. E2eNode Suite. pls see: [1] [2] <fmt.wrapError | 0x40005e7840: failed to update pod "pod--65da-42b7-a6a5-": Pod "pod--65da-42b7-a6a5-" is invalid: spec: Forbidden: pod updates may not change fields other than ,,, (only additions to existing tolerations), (allow it to be set to 1 if it was previously negative) core.PodSpec{ Volumes: []core.Volume{ { Name: "cm", Name: "secret", VolumeSource: core.VolumeSource{ ... // 3 identical fields AWSElasticBlockStore: nil, GitRepo: nil, Secret: nil, Secret: &core.SecretVolumeSource{SecretName: "secret", DefaultMode: &420}, NFS: nil, ISCSI: nil, ... // 9 identical fields FC: nil, AzureFile: nil, ConfigMap: &core.ConfigMapVolumeSource{ LocalObjectReference: core.LocalObjectReference{Name: "does-not-exist"}, DefaultMode: &420, }, ConfigMap: nil, VsphereVolume: nil, AzureDisk: nil, ... // 7 identical fields }, }, }, InitContainers: {{Name: "init1", Image: "", Command: {"sh", "-c", "sleep 5s"}, TerminationMessagePath: "/dev/termination-log", ...}}, Containers: []core.Container{ { ... // 9 identical fields ResizePolicy: nil, RestartPolicy: nil, VolumeMounts: []core.VolumeMount{ { Name: "cm", Name: "secret", ReadOnly: false, MountPath: "/config", ... // 3 identical fields }, }, VolumeDevices: nil, LivenessProbe: nil, ... // 10 identical fields }, }, EphemeralContainers: nil, RestartPolicy: "Always", ... // 28 identical fields } happened since 18/10/23 run the e2e testcases manually No response <details</details<detailsImpacts all </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
/assign /cc
cc
failed on x86 as well:
/sig node
/unassign
is merged today. /cc
will take a look at this ASAP /assign
and I are sorry for the issue this caused. We decided to open to fix this issue. I think this test was more complicated than we thought. Sorry for this.
Change:
diskName := av.volumeName[(strings.LastIndex(av.volumeName, "/") + 1):] <ins> kind := v1.AzureManagedDisk </ins> volSource := v1.VolumeSource{ AzureDisk: &v1.AzureDiskVolumeSource{ DiskName:    diskName, DataDiskURI: av.volumeName, <ins> Kind:        &kind, </ins> ReadOnly:    &readOnly, }, }

Discussion:
I am trying to run Azure e2e tests: The test creates a volume in the cloud + runs a pod with the volume as in-line. The pod never starts: The test creates a "blob" disk, while the Azure machine expects "managed" disk. Does anyone run storage e2e tests on Azure regularly? Was it ever working? Managed disks are provisioned . Should the test suite create "managed" disks by default too? Environment: Kubernetes version (use ): v1.17.0-alpha.0.1089+-dirty
/sig azure
/sig cloud-provider
managed disk should be the default, the azure disk storage class in the test case may have
The volume is created outside of kubernetes dynamic provisioning to test pre-provisioned and inline volumes: I wonder if anyone actually runs the tests.
Change:
platform( name = "rbe_with_network", parents = ["@rbe_default//config:platform"], <ins> # https://cloud.google.com/remote-build-execution/docs/remote-execution-environment#remote_execution_properties </ins> remote_execution_properties = """ properties: { name: "dockerNetwork" value: "standard" } <ins> properties: { name: "dockerPrivileged" value: "true" } </ins> {PARENT_REMOTE_EXECUTION_PROPERTIES} """, )

Discussion:
Repro: Errors tend to look something like this:
should demonstrate that this package's unit tests are flaky, see initial comments /assign
/assign Looks like a race in probe watcher stop?
GitHub didn't allow me to assign the following users: chardch. 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
The probe watcher stop is explicitly setup as a synchronization point. We expect all goroutines started by that module to finish at most 11s after stop is called (10s is the timeout for a socket). I'll take a look at trying to reproduce this and getting the klogs that the pluginwatcher should output.
No longer seem able to repro this:
I have also seen in my test environment, I will try reproducing this and let you know how it goes!
no luck in reproducing:
Many time I've seen this test is failing with older version golang compare to new one.! like or
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
Same problem here.
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

/assign
/sig testing
Switching to running bazel in does not change the result
Looks like this has to do with needing a privileged container
Change:
defer runtime.HandleCrash() for event := range outStream { <del> if event.ContainerName == recordEventContainerName { </del> <ins> if event.VictimContainerName == recordEventContainerName { </ins> klog.V(1).Infof("Got sys oom event: %v", event) eventMsg := "System OOM encountered" if event.ProcessName != "" && event.Pid != 0 {

Discussion:
What happened: A SystemOOM event was not reported even when the memory limit hit was the root cgroup memory limit. What you expected to happen: A SystemOOM event should have been reported. How to reproduce it (as minimally and precisely as possible): Do not set or , and set to disable memory eviction on the kubelet. Run a pod without memory limits which slowly consumes memory, such as with from Use arguments -mem-alloc-size", "100Mi", "-mem-alloc-sleep", "10s". This should trigger an OOM on the root cgroup, but no event will be generated. Anything else we need to know?: cAdvisor populates ContainerName and VictimContainerName from matching the regexp: instead in the kubelet. cc
/sig node /priority important-soon
Change:
var replicaSetColumns = []string{"NAME", "DESIRED", "CURRENT", "AGE"} var jobColumns = []string{"NAME", "DESIRED", "SUCCESSFUL", "AGE"} var serviceColumns = []string{"NAME", "CLUSTER-IP", "EXTERNAL-IP", "PORT(S)", "AGE"} <del> var ingressColumns = []string{"NAME", "RULE", "BACKEND", "ADDRESS", "AGE"} </del> <ins> var ingressColumns = []string{"NAME", "HOSTS", "ADDRESS", "PORTS", "AGE"} </ins> var petSetColumns = []string{"NAME", "DESIRED", "CURRENT", "AGE"} var endpointColumns = []string{"NAME", "ENDPOINTS", "AGE"} var nodeColumns = []string{"NAME", "STATUS", "AGE"}

Discussion:
We should show a nicely formatted map, with tls and ports. This 50% works. Today we have: Which works well enough, but printing a single Ingress involves hand managing tabs and newlines till the entire Ingress is printed, i.e: So when we start mixing different Ingress types, we get jarring output: This is because the columns are formatted per the top ingress and don't match the bottom one. The tabbed writer used by kubectl to align columns gets confused on the whole.
you can assign this to me, will fix this next-candidate.
thanks!
Sounds like we should keep it to a single line () and move everything else to describe. Makes this bug easier.
yeah, we will move this to a single line, this is the principle.
was this finished for 1.3?
the code is already finished on my local branch. I will open a PR as I confirmed it.
what do you think if print ingress like this: Also the original resource is:
That would fall right off the screen. I think we have to stick to just printing the ips in , and everything else in . You can print hoststs alone, and optimize for small ingresses by doing something like we do for endpoints (show a small number of characters then do "..."). The problem with trying to print everything on one line is you can't represent the fanout cleanly, ie you might do: But with multiple hosts: Doesn't work, because /bar and secret2 only applies to
I agree with this, maybe we should just remove these rules from get ingress output or just leave host here.
SGTM are you going to send a pr?
yes, ready to.
Change:
}, expectedTrace: []*spanExpectation{ { <del> name: "KubernetesAPI", </del> <ins> name: "DELETE /api/v1/nodes/{:name}", </ins> attributes: map[string]func(*commonv1.AnyValue) bool{ "http.user_agent": func(v *commonv1.AnyValue) bool { return strings.HasPrefix(v.GetStringValue(), "tracing.test")

Discussion:
When enable apiserver tracing, the webhook request spans only show spanName as /, mostly because use http request operations as default span name, which is hard to understand. ! Following the open-telemetry standard of spanName, it's recommended to use as spanName. ! SpanName of webhook request should be , like ! APIServerTracing feature gates of apiserver a pod tracing dashboard No response <details18 </details<detailsNone </details<details</details<details</details<details</details<details</details
I make a fix for this.
/sig api-machinery instrumentation
Do you know if this is fixed in later versions of opentelemetry?
/triage accepted /assign
Looks like might be related
not yet, I think we can fix this in otel upstream, but it's hard to backport to otel , which is the version of otel used in Kubernetes
Good point. It think fixing it here is a good idea in that case.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
could I take on this issue?
yes. Feel free to work on this.
! I test locally by 1.29 kubernetes and start a sample webhook, looks like the client span has already conforms to semantic conventions , which should be in the form of "HTTP {METHODNAME}"
! For apiserver as a server, now the spanName is still KubernetesAPI, which I think we could enhance it into "HTTP get_account/{accountId}" format
After digging for a while, I found one solution to implement this, I draft this idea in , could you help review about whether this is a correct way to implement it?
Change:
exit 1 fi <ins> if ! _out="$(diff -Naupr ${KUBE_ROOT}/vendor ${_kubetmp}/vendor)"; then echo "Your vendored results are different:" echo "${_out}" echo "Godeps Verify failed." exit 1 fi </ins> echo "Godeps Verified." # ex: ts=2 sw=2 et filetype=sh

Discussion:
noticed that my own dependency update got the wrong commit in , but verify-godeps didn't fail the PR. I think it is broken. I noticed that it also didn't fail even when I manually edited files in vendor/.
So, it turns out that verify-godeps tries to verify the file but NOT the contents of the vendor/ dir. That is easy to fix, but it flags a handful of errors. PR(s) will be forthcoming.
It looks like ginkgo () and one other delta I can not explain: Ryan, can you see what is up with that dep, maybe we have the wrong hash or we need to git add that file or something?
Change:
}, { "ImportPath": "github.com/codegangsta/negroni", <del> "Comment": "v0.1.0-62-g8d75e11", </del> <ins> "Comment": "v0.1-62-g8d75e11", </ins> "Rev": "8d75e11374a1928608c906fe745b538483e7aeb2" }, {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug report Kubernetes version (use ): Environment: Cloud provider or hardware configuration: vsphere OS (e.g. from /etc/os-release):Kernel (e.g. ): 4.9.24-coreos Install tools: Others: What happened: After bringing a cluster up, there are no container metrics in the kubelet at /metrics What you expected to happen: I expect to see the metrics, but there are none How to reproduce it (as minimally and precisely as possible): Anything else we need to know: If I try and access the metrics in cAdvisor directly on port 4194 instead of on port then I see the following type of error for all of the metrics:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig node
This appears to be a v1.7 issue. If I run 1.6.6 I get these metrics. Seems like something has happened in 1.7. I'm running the 1.7 beta because I need nodePort for cni, so now I'm stuck.
Can you triage the issue since?
cc/
Can you help verifying is this is a new regression introduced in 1.7 cadvisor through node-e2e? Thanks!
I've tried this on both cos and cvm in 1.7 cluster, and no container metrics show up. However, I created a 1.6.4 GKE cluster, and container metrics are there. This is a regression in 1.7. Will figure out what is wrong here.
Here is a corresponding cadvisor issue
Even the user still can get the container metrics / stats from kubelet /summary api (recommended way), but since this is a regression introduced in 1.7 release, and we aren't dropping prometheus support, let's fix this for 1.7. Thanks!
Fixed in Will close this issue after building new cadvisor release and cherrypick into 1.7
Thanks for the quick find everyone! I'll be happy to give this a go on the next release!

I'm still facing this same issue. My kubernetes cluster is deployed with kubeadm on Centos 7. I run a k8S v1.8.1 cluster. When I try to fetch containers metrics this way: http://localhost:8001/api/v1/proxy/nodes/node1:0/metrics http://localhost:8001/api/v1/proxy/nodes/node1:/metrics http://localhost:8001/api/v1/proxy/nodes/node1:/metrics I find no metrics. kubelet is started with . If I start kubelet with . metrics are available through .