jiebi/CodeConvo huggingface dataset:
Change:
<ins> // +build linux </ins> /* Copyright 2016 The Kubernetes Authors.

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): master Environment: OS: MacOS Kernel (e.g. ): Darwin Klauss-MacBook- 15.6.0 Darwin Kernel Version 15.6.0: Mon Aug 29 20:21:34 PDT 2016; root:xnu-3248.60.11~1/RELEASEX8664 x86_64 What happened: Build failed: What you expected to happen: Successfully built How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: N/A
cc , any suggestion?
attempted to fix this error in a recent PR.
I'll take a look. node_e2e should not be built on mac. It's weird.
I checked our cross build, everything is good: Are you sure you are using head? Have your code included
similar issue after , refer to the following output. Is the used to remove node_e2e on Mac? I'll check it and try to fix this issue :).
by running , it will just build everything on the current platform. That's why e2e_node and even other kubelet servers are built on Mac with . The problem is that whether guarantee building on Mac? From , it seems that K8s could build on Mac before. However, broke that.
, are you still working on this ? If not, I'd like to contribute to this one :). Here's what I found recently: The latest build command is: But when I checked , the is not included in it: I'm going to find what happened when build ; it seems is not included on Mac, which triggers this build error. If any comments/suggestion, please let me know.
/ , there's the root cause: the is only built on linux because of build flag (), that makes can not find related functions on Mac.
Yeah, for now we can add in to solve the problem. :) Feel free to fix it if you're interested. :)
, thanks very much; is better than a new file. The PR was updated accordingly ().
Change:
// change the reclamation policy of the PV for the next test pv.Spec.PersistentVolumeReclaimPolicy = api.PersistentVolumeReclaimDelete <del> w, _ = testClient.PersistentVolumes().Watch(api.ListOptions{}) </del> <ins> w, err = testClient.PersistentVolumes().Watch(api.ListOptions{}) if err != nil { t.Errorf("Failed to watch PersistentVolumes: %v", err) } </ins> defer w.Stop() <del> _, _ = testClient.PersistentVolumes().Create(pv) _, _ = testClient.PersistentVolumeClaims(api.NamespaceDefault).Create(pvc) </del> <ins> _, err = testClient.PersistentVolumes().Create(pv) if err != nil { t.Errorf("Failed to create PersistentVolume: %v", err) } _, err = testClient.PersistentVolumeClaims(api.NamespaceDefault).Create(pvc) if err != nil { t.Errorf("Failed to create PersistentVolumeClaim: %v", err) } </ins> waitForPersistentVolumePhase(w, api.VolumeBound)

Discussion:
PersistentVolume integration tests fail sometimes: There are some interesting reports in the log like: Thans for report.
It turns out that volume integration tests have no logs at all, was not checked and I don't really know what's going on there. adds error checks to help me find out what's wrong there. Still, I suspect there are some troubles with etcd, not related to the test itself.
This flake affects also TestPersistentVolumeMultiPVs:
Extended logging got merged just now, please post links to logs when it breaks again!
Marking as P1 as per
I have no real usable logs, but I think it could be fixed by , it hasn't flaked since it was merged. And I have (in merge queue) to further stabilize the tests.
Not blocking this on 1.3.
It hasn't flaked for almost a month, can we close this?
Closing this issue since previous fixes made the flake go away.
Change:
func (az *Cloud) getAzureClientConfig(servicePrincipalToken *adal.ServicePrincipalToken) *azclients.ClientConfig { azClientConfig := &azclients.ClientConfig{ <ins> CloudName:               az.Config.Cloud, </ins> Location:                az.Config.Location, SubscriptionID:          az.Config.SubscriptionID, ResourceManagerEndpoint: az.Environment.ResourceManagerEndpoint,

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : PR() already proves that old api-version on Azure stack works on global Azure too, we could support azure stack in azure cloud provider lib, and then make sure following components works in Azure stack: CSI drivers: azure disk, azure file CCM Since it's mainly api-version change, we could also add e2e tests against global Azure too. Why is this needed: /assign /priority important-soon /sig cloud-provider /area provider/azure
there is blocking issue here(also need azure stack supports latest data model struct): just making the change in interfaces and not go-sdk but facing this error, since we don't have a switch inside go-sdk, we only do switch in azure cloud provider lib,
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
Change:
<ins> /* Copyright 2019 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package openstack import ( "k8s.io/kubernetes/test/e2e/framework" ) func init() { framework.RegisterProvider("openstack", newProvider) } func newProvider() (framework.ProviderInterface, error) { return &Provider{}, nil } // Provider is a structure to handle OpenStack clouds for e2e testing type Provider struct { framework.NullProvider } </ins>

Discussion:
What happened: When specifying "openstack" as cloud-provider of e2e test, the test is failed like What you expected to happen: We can run e2e test with openstack cloud provider. How to reproduce it (as minimally and precisely as possible): Just kick the following command: ` Anything else we need to know?: This issue doesn't happen on v1.13, so this issue seems to happen during this dev cycle for v1.14. Environment: Kubernetes version (use ): master for v1.14 Cloud provider or hardware configuration: OpenStack OS (e.g: ): Ubuntu 16.04.5 LTS Kernel (e.g. ): 4.4.0-142-generic Install tools: kubeadm Others:
/sig openstack /sig testing
The exception raises at
The reason of this issue comes from
Ideally it is nice to put a new directory for registering the cloud provider.
/assign
I was wondering we could remove "openstack" provider specific tests and conditions from e2e tests, but there are storage tests which are related to OpenStack in e2e tests. So it is nice to add registration for OpenStack at this time.
Change:
import ( "net" <ins> "strings" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" )

Discussion:
Since this PR got merged, the ELB e2e test, which was consistently succeeding, is now consistently failing: Revert now that is in, and fix the tests that were relying on it. (details) Commit by arob Revert now that is in, and fix the tests that were relying on it. The file was modified The file was modified The file was modified I'm going to roll it back to confirm.
Change:
return } <ins> // Watch returns a watch.Interface that watches the requested pods. func (c *pods) Watch(label, field labels.Selector, resourceVersion string) (watch.Interface, error) { return c.r.Get(). Prefix("watch"). Namespace(c.ns). Resource("pods"). Param("resourceVersion", resourceVersion). SelectorParam("labels", label). SelectorParam("fields", field). Watch() } </ins> // Bind applies the provided binding to the named pod in the current namespace (binding.Namespace is ignored). func (c *pods) Bind(binding *api.Binding) error { return c.r.Post().Namespace(c.ns).Resource("pods").Name(binding.Name).SubResource("binding").Body(binding).Do().Error()

Discussion:
PodInterface should have Watch method behaving in the same way as ServiceInterface.Watch does. Use case: a monitoring system (namely Prometheus) expects to get the list of monitored servers performing a DNS-SD query. Special service (similar to kube2sky shipped with Kubernetes) mirrors status of running Pods into etcd, which is in turn monitored by SkyDNS server and exported as DNS-SD. Schematically the data flow looks like this: Kubernetes -kube2sky -etcd -SkyDNS -Prometheus. The biggest challenge is to deliver list of all running pods from Kubernetes to kube2sky. Currently kube2sky can only poll Kubernetes with PodInterface.List() each N seconds, which is not efficient. Having a Watch method would be much better.
cc Do you know why we do not support watch?
Every object should support Watch.
Watching status doesn't currently work -- that's .
I agree with OP. This is just an accident of history; some boilerplate in the client isn't completely filled out. As Brian mentions, not every field is currently watchable but that's being addressed elsewhere.
This is relevant to your interests potentially w/ your work on
This is a pretty simple change if someone wants to get their feet wet. :)
I'll work on it.
Change:
volumeID:     pvSource.VolumeHandle, specVolumeID: spec.Name(), csiClient:    client, <ins> readOnly:     readOnly, </ins> } return mounter, nil }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The field passed to is never set. In where is a object that is initialized in the method in Notice the field is never set. What you expected to happen: The field should be set to How to reproduce it (as minimally and precisely as possible): Create a CSI volume and set to true. Check the value of in the CSI call. It should be true, but is false. CC Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I think is only used for mounting pod volume path to container, here(for ), we can set to , just like other volume plugins. I can help to fix this.
What about the case when a user wants to mount a volume for one of containers in a POD as read only, but the actual volume has ReadOnly False? I would like to suggest an alternative solution which passes the value of ReadOnly attribute, taken from POD's spec.
Thank you and for jumping on this! I feel like the other volume plugins have the wrong behavior here. The purpose of the call is to mount the volume. Therefore, the should receive the pod volume mount readonly field. That said, as mentioned , I think the fact that " is used for mounting pod volume path to container" might be hiding a bug: that is never set correctly. I haven't had a chance to validate this but my reading of the code suggests that the is never set. But because the container mount uses , even though the plugin did not get the correct readonly value, the mount ends up getting mounted with the correctly readonly value. Thoughts?
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<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
We discussed the proposed fixes in the Kubernetes CSI implementation meeting today (see ). We decided it would be better for CSI to be consistent with the other plugins (and still broken), and have CSI fixed, along with all the other plugins, whenever we fix the issue (likely post-1.10). Therefore, I will accept fix and we will close Then we can remove the 1.10 tag from this issue and track it independent of the 1.10 release.
Spoke with offline. Details here: Based on that conversation, I don't think there is anything else we need to do here.
Change:
}, }, }, <del> NodeName: nodeName, </del> <ins> NodeName: p.NodeName, </ins> }, }) } <ins> func startNewLoggingPod(f *framework.Framework, podName string, nodeName string, totalLines int, loggingDuration time.Duration) *loggingPod { pod := newLoggingPod(podName, nodeName, totalLines, loggingDuration) pod.Start(f) return pod } </ins> func waitForSomeLogs(f *framework.Framework, config *loggingTestConfig) error { podHasIngestedLogs := make([]bool, len(config.Pods)) podWithIngestedLogsCount := 0

Discussion:
Pods should be run in parallel with checking the logs from the backend to fit into the timeout.
Change:
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="-30" y="416.75" width="364" height="146"/> </g> <g> <del> <rect style="fill: #ffffff" x="418.774" y="551" width="176.225" height="121"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="418.774" y="551" width="176.225" height="121"/> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="506.886" y="583.4"> <tspan x="506.886" y="583.4">Distributed</tspan> <tspan x="506.886" y="599.4">Watchable</tspan> <tspan x="506.886" y="615.4">Storage</tspan> <tspan x="506.886" y="631.4"></tspan> <tspan x="506.886" y="647.4">(implemented via etcd)</tspan> </text> </g> <g> </del> <rect style="fill: #ffffff" x="201.314" y="594.318" width="154.6" height="38"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="201.314" y="594.318" width="154.6" height="38"/> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="278.614" y="617.218">

Discussion:
CA Advisor runs inside docker containers, but I don't believe it's correct to show the Kubelet and Proxy processes as inside the docker box on the minion. Also, shouldn't the internet-firewall-really load balance across minion proxies instead of be connected to just one SPOF minion, treating that connection more like a logical connection across all minion proxies?
This is the desired state, which is admittedly not the current state. Yeah, this is a good point. k8s currently relies on its environment for load balancing. Maybe or can speak to the desired state here.
We should just review the diagram and make it correctly reflect the state of 1.0.
Change:
// NewCgroupNotifier returns a linuxCgroupNotifier, which performs cgroup control operations required // to receive notifications from the cgroup when the threshold is crossed in either direction. func NewCgroupNotifier(path, attribute string, threshold int64) (CgroupNotifier, error) { <ins> // cgroupv2 does not support monitoring cgroup memory thresholds using cgroup.event_control. // Instead long term, on cgroupv2 kubelet should rely on combining usage of memory.low on root pods cgroup with inotify notifications on memory.events and or PSI pressure. // For now, let's return a fake "disabled" cgroup notifier on cgroupv2. // https://github.com/kubernetes/kubernetes/issues/106331 if libcontainercgroups.IsCgroup2UnifiedMode() { return &disabledThresholdNotifier{}, nil } </ins> var watchfd, eventfd, epfd, controlfd int var err error watchfd, err = unix.Open(fmt.Sprintf("%s/%s", path, attribute), unix.O_RDONLY|unix.O_CLOEXEC, 0)

Discussion:
Start kubelet on a cgroupv2 image with kubelet config option or the flag enabled. Kubelet will periodically log something like: This is because the kernel memcg notifications relies on kubelet's which uses evenfd on file which is cgroupv1 specific and not supported on cgroupv2. Kubelet will disable kernel memcg notifications on cgroupv2 if they are unsupported and consider long term support for more cgroupv2 "compatible" ways to monitor for memory pressure. The closest analogous cgroupv2 concept is using inotify notifications on file and or combination with PSI pressure. This requires to be set on pod cgroup which requires the MemoryQOS feature to be enabled Start kubelet on a cgroupv2 image with enabled.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node /cc
Change:
filenameWidgetServerside = "../../../../test/fixtures/pkg/kubectl/cmd/apply/widget-serverside.yaml" ) <del> func readConfigMapList(t *testing.T, filename string) []byte { </del> <ins> func readConfigMapList(t *testing.T, filename string) [][]byte { </ins> data := readBytesFromFile(t, filename) cmList := corev1.ConfigMapList{} if err := runtime.DecodeInto(codec, data, &cmList); err != nil { t.Fatal(err) } <del> cmListBytes, err := runtime.Encode(codec, &cmList) if err != nil { t.Fatal(err) </del> <ins> var listCmBytes [][]byte for _, cm := range cmList.Items { cmBytes, err := runtime.Encode(codec, &cm) if err != nil { t.Fatal(err) } listCmBytes = append(listCmBytes, cmBytes) </ins> } <del> return cmListBytes </del> <ins> return listCmBytes </ins> } func readBytesFromFile(t *testing.T, filename string) []byte {

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 What happened: The dry run output listed all the resources that would be configured: deployments, HPAs, services, and an ingress: This was expected. However, it then listed all resources again (except for the HPAs) as being pruned: The config was then applied with: As expected, no resources were actually pruned. What you expected to happen: should actually display which resources are going to be pruned. How to reproduce it (as minimally and precisely as possible): a YAML file to with it: run + prune: should be listed as both configured and pruned it again with pruning: that the deployment is configured but not pruned, even though the dry run said it would be. Anything else we need to know?: Was trying to write a devops script that gave a warning before any resources would be pruned. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): (Lubuntu 18.04) Kernel (e.g. ):Install tools: Others:
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
I can reproduce it, and i will try to fix it.
Change:
newClaimArray("claim11-1", "uid11-1", "1Gi", "", v1.ClaimPending, storageutil.StorageClassAnnotation), // Binding will be completed in the next syncClaim newClaimArray("claim11-1", "uid11-1", "1Gi", "", v1.ClaimPending, storageutil.StorageClassAnnotation, annStorageProvisioner), <del> noevents, noerrors, wrapTestWithProvisionCalls([]provisionCall{provision1Success}, testSyncClaim), </del> <ins> []string{"Normal ProvisioningSucceeded"}, noerrors, wrapTestWithProvisionCalls([]provisionCall{provision1Success}, testSyncClaim), </ins> }, { // Provision failure - plugin not found

Discussion:
is quite confusing when provisioning for a PVC fails and then succeeds: it shows the PVC as , i.e. everything is OK the last logged event is , i.e. something went wrong What of the above is correct? We should log also the success:
fixed by
Change:
} } <ins> dataDir := getVolumeDeviceDataDir(m.specName, m.plugin.host) // remove ~/${pv}/data/vol_data.json first, then remove the other dir. volDataFile := path.Join(dataDir, volDataFileName) err = os.Remove(volDataFile) if err != nil && !os.IsNotExist(err) { return err } // remove ~/${pv}/data err = os.Remove(dataDir) if err != nil && !os.IsNotExist(err) { return err } // remove ~/${pv} pvPath := filepath.Dir(dataDir) err = os.Remove(pvPath) if err != nil && !os.IsNotExist(err) { return err } </ins> return nil }

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: dir crated in would not be automatically removed. What you expected to happen: when a pod delete the, the dir would be removed How to reproduce it (as minimally and precisely as possible): create a pod using csi raw block volume and delete it Anything else we need to know?: ! pod using pv--6195-49a0-b262- actually has been deleted and the volume has been unmounted, but the dir still exists. ! {pv}/data still exists Environment: Kubernetes version (use ): 1.15 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 storage /assign
I am afraid that the fix won't work for all volume plugins. I randomly checked where some volume plugins symlinks a device: iscsi: aws: So, iSCSI would be cleaned with this PR, but just as a coincidence, not as deliberate design. And AWS would still leave orphaned . I am not convinced that this we don't have a plugin that does not use subdirectories. I think a better approach is necessary. Perhaps of every plugin should clean up everything that created?
thanks for your advice, I would try to find a better approach
/reopen
Reopened this issue. <detailsIn response to : /reopen </details
is being reverted because it broke CSI block volume cleanup
/assign
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 is this still an issue?
I am adding CSI directories cleanup in
This should be fixed by /close
Closing this issue. <detailsIn response to : This should be fixed by /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
Change:
"github.com/spf13/pflag" "k8s.io/kubernetes/contrib/mesos/pkg/hyperkube" "k8s.io/kubernetes/contrib/mesos/pkg/scheduler/service" <del> "k8s.io/kubernetes/pkg/util" </del> "k8s.io/kubernetes/pkg/util/flag" "k8s.io/kubernetes/pkg/util/logs" "k8s.io/kubernetes/pkg/version/verflag"

Discussion:
When I tried to use the following command to build kubernetes: I encountered the following errors: I'm using Ubuntu 14.04 and the code from master branch. will submit a patch then to fix this problem.
whoa, I just landed in the exact same place, I am trying to build k8s on a CentOS7 box. Tried with removing the unused utils and works like a charm !