jiebi/CodeConvo huggingface dataset:
Change:
Noticing this is in our gce 5k-node cluster tests. It has been continuously failing for 4 runs now already: https://k8s- https://k8s- (and 39 and 40) The e2e test concerned is - Volume plugin streaming [Slow] NFS should write files of various sizes, verify size, validate content And it is failing due to: cc
cc - Could one of you PTAL or redirect as apt?
FTR, it is passing on small scale - https://k8s- I took a quick look at the and the following PR catches my attention at first sight: test: e2e: support NFS test on overlayfs
Do we have some umbrella issue for failing correctness tests on large scale atm?
Not really, we have , though.
does look very suspicious. Before, the NFS server test image would use the container image layer for its data, and this change makes it use emptydir tmpfs instead. for the large scale tests, do you guys have default memory limits for pods? That could potentially explain why it's failing on large scale tests and not the regular tests. A possible fix could be to change it to use regular emptydir so it's not subject to any memory limits.
FMU we're not setting any memory limits for pods explicitly and it's the same e2e test running on both the large cluster and the small cluster. I'm not sure if there's sth (like an admission plugin) which secretly sets memory limits for pods based on cluster size - I'd be quite surprised if that's the case.
Hmm or it could be that in the scale test, the nodes are more loaded, so resources could be more constrained. In any case, I think it's better for this test to not write to tmpfs, because it can write gigs of data.
I would be surprised a bit if that was the case - as this test was passing for quite some time (https://k8s-). So mostly unless sth changed around this e2e test or with storage/kubernetes, it doesn't seem to be so. Anyhow, not writing gigs of data to tmpfs does sound good to me :) One more thing to note is we're using the following config for our large cluster:
Yah so this test got changed from using disk to using memory by , which is when this test started failing. So I suspect it is related to either a memory limit or memory pressure.
That seems to have . Thanks
More references FTR: https://k8s- https://k8s- https://k8s-

Discussion:
mountName := fmt.Sprintf("path%d", i) volumes[i].Name = mountName if src == "" { <del> volumes[i].VolumeSource.EmptyDir = &v1.EmptyDirVolumeSource{Medium: v1.StorageMediumMemory} </del> <ins> volumes[i].VolumeSource.EmptyDir = &v1.EmptyDirVolumeSource{} </ins> } else { volumes[i].VolumeSource.HostPath = &v1.HostPathVolumeSource{ Path: src,
Change:
This is not 100% reproducable in my cluster. There is 20% chance of failing in my environment.
/area hw-accelerators mentioned a root cause that might be due to unit tests sharing the same Unix socket and interfering with each others. cc
Can you please share latest commit id of your code base using ?
Thanks very much, can you try the follow command please:
/assign
The latest commit id of my code base:
I found this is not 100% reproducable in my cluster. There is 20% chance of failing in my environment.
Result of go test command:
/sig scheduling
Thanks!
Hi, does these unit tests pass with PR
I run 100 times without failure.
Good to here that, Nice work! Thanks!

Discussion:
pluginapi.RegisterDevicePluginServer(m.server, m) go m.server.Serve(sock) <del> // Wait till grpc server is ready. for i := 0; i < 10; i++ { services := m.server.GetServiceInfo() if len(services) > 0 { break } time.Sleep(1 * time.Second) </del> <ins> _, conn, err := dial(m.socket) if err != nil { return err </ins> } <ins> conn.Close() </ins> log.Println("Starting to serve on", m.socket) return nil

// Register registers the device plugin for the given resourceName with Kubelet. func (m *Stub) Register(kubeletEndpoint, resourceName string) error { <del> conn, err := grpc.Dial(kubeletEndpoint, grpc.WithInsecure(), </del> <ins> conn, err := grpc.Dial(kubeletEndpoint, grpc.WithInsecure(), grpc.WithBlock(), grpc.WithTimeout(10*time.Second), </ins> grpc.WithDialer(func(addr string, timeout time.Duration) (net.Conn, error) { return net.DialTimeout("unix", addr, timeout) }))

e.clientConn.Close() } <del> // dial establishes the gRPC communication with the registered device plugin. </del> <ins> // dial establishes the gRPC communication with the registered device plugin. https://godoc.org/google.golang.org/grpc#Dial </ins> func dial(unixSocketPath string) (pluginapi.DevicePluginClient, *grpc.ClientConn, error) { <del> c, err := grpc.Dial(unixSocketPath, grpc.WithInsecure(), </del> <ins> c, err := grpc.Dial(unixSocketPath, grpc.WithInsecure(), grpc.WithBlock(), grpc.WithTimeout(10*time.Second), </ins> grpc.WithDialer(func(addr string, timeout time.Duration) (net.Conn, error) { return net.DialTimeout("unix", addr, timeout) }),

func TestPodContainerDeviceAllocation(t *testing.T) { flag.Set("alsologtostderr", fmt.Sprintf("%t", true)) <del> var logLevel string flag.StringVar(&logLevel, "logLevel", "4", "test") flag.Lookup("v").Value.Set(logLevel) </del> res1 := TestResource{ resourceName:     "domain1.com/resource1", resourceQuantity: *resource.NewQuantity(int64(2), resource.DecimalSI),
Change:
/kind bug What happened: https://k8s-
/sig azure
I find the root cause, and can fix it.
/kind bug
/cc
Cool, thanks

Discussion:
"github.com/stretchr/testify/assert" ) <del> func newTestScaleSet() *scaleSet { ss := newScaleSet(getTestCloud()) </del> <ins> func newTestScaleSet(scaleSetName string, vmList []string) *scaleSet { cloud := getTestCloud() setTestVirtualMachineCloud(cloud, scaleSetName, vmList) ss := newScaleSet(cloud) </ins> return ss.(*scaleSet) } <del> func setTestVirtualMachineScaleSets(ss *scaleSet, scaleSetName string, vmList []string) { </del> <ins> func setTestVirtualMachineCloud(ss *Cloud, scaleSetName string, vmList []string) { </ins> virtualMachineScaleSetsClient := newFakeVirtualMachineScaleSetsClient() scaleSets := make(map[string]map[string]compute.VirtualMachineScaleSet) scaleSets["rg"] = map[string]compute.VirtualMachineScaleSet{

}, ID:         &ID, InstanceID: &instanceID, <del> Location:   &ss.Cloud.Location, </del> <ins> Location:   &ss.Location, </ins> } } virtualMachineScaleSetVMsClient.setFakeStore(ssVMs) <del> ss.Cloud.VirtualMachineScaleSetsClient = virtualMachineScaleSetsClient ss.Cloud.VirtualMachineScaleSetVMsClient = virtualMachineScaleSetVMsClient </del> <ins> ss.VirtualMachineScaleSetsClient = virtualMachineScaleSetsClient ss.VirtualMachineScaleSetVMsClient = virtualMachineScaleSetVMsClient </ins> } func TestGetScaleSetVMInstanceID(t *testing.T) {

} func TestGetInstanceIDByNodeName(t *testing.T) { <del> ss := newTestScaleSet() </del> testCases := []struct { description string scaleSet    string

} for _, test := range testCases { <del> setTestVirtualMachineScaleSets(ss, test.scaleSet, test.vmList) </del> <ins> ss := newTestScaleSet(test.scaleSet, test.vmList) </ins> real, err := ss.GetInstanceIDByNodeName(test.nodeName) if test.expectError { assert.Error(t, err, test.description)
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Now that the local provisioner uses mount propagation, the provisioner e2e test should also test adding mount points after the provisioner has started
would you have time to look into this?
/assign
FYI:

Discussion:
By("Deleting provisioner daemonset") deleteProvisionerDaemonset(config) }) <ins> It("should discover dynamicly created local persistent volume mountpoint in discovery directory", func() { By("Starting a provisioner daemonset") createProvisionerDaemonset(config) By("Creating a volume in discovery directory") dynamicVolumePath := path.Join(config.discoveryDir, fmt.Sprintf("vol-%v", string(uuid.NewUUID()))) setupLocalVolumeProvisionerMountPoint(config, dynamicVolumePath, config.node0) By("Waiting for the PersistentVolume to be created") _, err := waitForLocalPersistentVolume(config.client, dynamicVolumePath) Expect(err).NotTo(HaveOccurred()) By("Deleting provisioner daemonset") deleteProvisionerDaemonset(config) By("Deleting volume in discovery directory") cleanupLocalVolumeProvisionerMountPoint(config, dynamicVolumePath, config.node0) }) </ins> }) Context("StatefulSet with pod anti-affinity", func() {
Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Kubelet constantly crashes trying to evict pods under memory pressure What you expected to happen: kubelet to be able to evict pods How to reproduce it (as minimally and precisely as possible): Fresh 1.9.1 Kubernetes, installed via kubeadm Here are relevant eviction parameters for kubelet Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"", GitTreeState:"archive", BuildDate:"2018-01-05T20:28:28Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-01-04T11:40:06Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: 8GiB of RAM OS (e.g. from /etc/os-release): Gentoo Kernel (e.g. ): Linux 4.9.34-gentoo SMP Sat Jan 13 23:06:16 MSK 2018 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux Install tools: Others:
contains the following code I think there is a bug in that it is iterating through InitContainers but getting resources of regular containers. I have a pod that has 3 initContainers. Looks like this could be a copy&paste error.
/sig node
indeed there's a mismatch between initContainers and spec containers, I'll take a look.
looks like we need to do the following and the problem was introduced in cc
- Indeed, I'll open a PR for this
reopening until it is cherrypicked to 1.9
It was cherry-picked in 1.9.3.
/close

Discussion:
} // podRequest returns the total resource request of a pod which is the <del> // max(sum of init container requests, sum of container requests) </del> <ins> // max(max of init container requests, sum of container requests) </ins> func podRequest(pod *v1.Pod, resourceName v1.ResourceName) resource.Quantity { containerValue := resource.Quantity{Format: resource.BinarySI} if resourceName == resourceDisk && !utilfeature.DefaultFeatureGate.Enabled(features.LocalStorageCapacityIsolation) {

for i := range pod.Spec.InitContainers { switch resourceName { case v1.ResourceMemory: <del> containerValue.Add(*pod.Spec.Containers[i].Resources.Requests.Memory()) </del> <ins> if initValue.Cmp(*pod.Spec.InitContainers[i].Resources.Requests.Memory()) < 0 { initValue = *pod.Spec.InitContainers[i].Resources.Requests.Memory() } </ins> case resourceDisk: <del> containerValue.Add(*pod.Spec.Containers[i].Resources.Requests.StorageEphemeral()) </del> <ins> if initValue.Cmp(*pod.Spec.InitContainers[i].Resources.Requests.StorageEphemeral()) < 0 { initValue = *pod.Spec.InitContainers[i].Resources.Requests.StorageEphemeral() } </ins> } } if containerValue.Cmp(initValue) > 0 {
Change:
Once cloud-controller-manager is started we should remove the taint. right?
/sig cluster-lifecycle
/area cloudprovider do you have anymore information on this? I can't reproduce this on existing nodes before the CCM was created or new nodes to a cluster.
i can recreate this using by setting along with a CLOUDCONFIG + CLOUDPROVIDER env vars
If you're running a local cluster then how are you running the CCM? The only way the taint gets removed is if the instance was found in the cloud provider and setup (labels, addresses, etc) OK. The code can be found
the local cluster is started within a openstack vm. so it's a one vm cluster. thanks for the pointer, will check it out
/assign
- So ... when i use local-up-cluster, the kubelet starts up before the cloud-controller-manager. So the shared informer that calls is never triggered. This patch seems to fix the issue. Note that RBAC stuff needed to be setup for as well for the to succeed.

Discussion:
nodeStatusUpdateFrequency: nodeStatusUpdateFrequency, } <del> nodeInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc: cnc.AddCloudNode, </del> <ins> // Use shared informer to listen to add/update of nodes. Note that any nodes // that exist before node controller starts will show up in the update method cnc.nodeInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{ AddFunc:    cnc.AddCloudNode, UpdateFunc: cnc.UpdateCloudNode, </ins> }) return cnc

} } <ins> func (cnc *CloudNodeController) UpdateCloudNode(_, newObj interface{}) { if _, ok := newObj.(*v1.Node); !ok { utilruntime.HandleError(fmt.Errorf("unexpected object type: %v", newObj)) return } cnc.AddCloudNode(newObj) } </ins> // This processes nodes that were added into the cluster, and cloud initialize them if appropriate func (cnc *CloudNodeController) AddCloudNode(obj interface{}) { node := obj.(*v1.Node)
Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug I think this is a bug, but let me know if it is not. What happened: When feature-gate TaintNodesByCondition is true, we were surprised to find out that nodes that are continues to get pod scheduled onto it. What you expected to happen: Nodes that are don't get new pod scheduled. How to reproduce it (as minimally and precisely as possible): Set for kube-scheduler Drain a node and see pods continue to be scheduled to the node. Anything else we need to know?: From glancing the code, it appears that is removed when the feature gate is on. However, spec.Unschedulable appears to be checked only in Environment: Kubernetes version (use ): 1.9.2 Cloud provider or hardware configuration: baremetal OS (e.g. from /etc/os-release): CentOS 7.4 Kernel (e.g. ): 4.14.14 Install tools: custom Others:
/sig scheduling
ping I saw you touched this part of codes.
, good catch ! The options in my mind are Added a new predication for Unschedulable Taint nodes when cordon/uncordon
- From discussion with we might want to check node.Spec.Unschedulable when checking the taints ? (i.e on the predicate responsible for checking taints).
That's OK to me, just one comment that there maybe two same predicate error :).

Discussion:
// PodToleratesNodeTaints checks if a pod tolerations can tolerate the node taints func PodToleratesNodeTaints(pod *v1.Pod, meta algorithm.PredicateMetadata, nodeInfo *schedulercache.NodeInfo) (bool, []algorithm.PredicateFailureReason, error) { <ins> if nodeInfo == nil || nodeInfo.Node() == nil { return false, []algorithm.PredicateFailureReason{ErrNodeUnknownCondition}, nil } if nodeInfo.Node().Spec.Unschedulable { return false, []algorithm.PredicateFailureReason{ErrNodeUnschedulable}, nil } </ins> return podToleratesNodeTaints(pod, nodeInfo, func(t *v1.Taint) bool { // PodToleratesNodeTaints is only interested in NoSchedule and NoExecute taints. return t.Effect == v1.TaintEffectNoSchedule || t.Effect == v1.TaintEffectNoExecute
Change:
Copying the issue from Here is my CRD CRD Data Outputs Expected to see the resource list when kubectl get dpl Versions
/sig api-machinery /area custom-resources /kind bug
Can you check if the title is right for this case?
/cc
If you collide with another short name, you have to qualify with a group. It should follows normal resolution rules for priority
this isn't CRD-specific. isn't a colliding shortname. it expanded dpl -deployments, then resolved deployments against preferred group order, instead of limiting resolution to the group(s) that had the shortname
updated description to narrow the report to the case which is a bug
Did a little research, turn out kubectl will take as it's short name: I can give a shot to solve this problem, unless it's by design... : )
FYI. PR .
/assign

Discussion:
} if resource.Resource == item.ShortForm.Resource { resource.Resource = item.LongForm.Resource <ins> resource.Group = item.LongForm.Group </ins> return resource } }

{ name:     "hpa-priority", arg:      "hpa", <del> expected: schema.GroupVersionResource{Resource: "superhorizontalpodautoscalers"}, </del> <ins> expected: schema.GroupVersionResource{Resource: "superhorizontalpodautoscalers", Group: "autoscaling"}, </ins> srvRes: []*metav1.APIResourceList{ { GroupVersion: "autoscaling/v1",

}, }, }, <ins> { name:     "resource-override", arg:      "dpl", expected: schema.GroupVersionResource{Resource: "deployments", Group: "foo"}, srvRes: []*metav1.APIResourceList{ { GroupVersion: "foo/v1", APIResources: []metav1.APIResource{ { Name:       "deployments", ShortNames: []string{"dpl"}, }, }, }, { GroupVersion: "extension/v1beta1", APIResources: []metav1.APIResource{ { Name:       "deployments", ShortNames: []string{"deploy"}, }, }, }, }, }, </ins> } ds := &fakeDiscoveryClient{}
Change:
If you create a Service without a selector and manually set endpoints, and then make a request via the Service websockets proxy on the API server the network connection is initiated from the APIserver's network namespace, not the client. This means that using this technique a user can access IP address that they may not be privileged to access (for example services in other namespaces). We should restrict the API proxy to only target Pods within the namespace of the Service.
/sig-network
/sig network

Discussion:
ServiceNodeExclusion utilfeature.Feature = "ServiceNodeExclusion" // owner @brendandburns <del> // stable: v1.10 </del> <ins> // deprecated: v1.10 </ins> // // Enable the service proxy to contact external IP addresses. Note this feature is present // only for backward compatability, it will be removed in the 1.11 release.

// unintentionally on either side: apiextensionsfeatures.CustomResourceValidation: {Default: true, PreRelease: utilfeature.Beta}, <del> // backward compatability features that enable backwards compatability but should be removed soon. ServiceProxyAllowExternalIPs: {Default: false, PreRelease: utilfeature.Beta}, </del> <ins> // features that enable backwards compatability but are scheduled to be removed ServiceProxyAllowExternalIPs: {Default: false, PreRelease: utilfeature.Deprecated}, </ins> }

Alpha = prerelease("ALPHA") Beta  = prerelease("BETA") GA    = prerelease("") <ins> // Deprecated Deprecated = prerelease("DEPRECATED") </ins> ) // FeatureGate parses and stores flag gates for known features from

} arr := strings.SplitN(s, "=", 2) k := Feature(strings.TrimSpace(arr[0])) <del> _, ok := known[k] </del> <ins> featureSpec, ok := known[k] </ins> if !ok { return fmt.Errorf("unrecognized key: %s", k) }

return fmt.Errorf("invalid value of %s: %s, err: %v", k, v, err) } enabled[k] = boolValue <ins> if boolValue && featureSpec.PreRelease == Deprecated { glog.Warningf("enabling deprecated feature gate %s", k) } </ins> // Handle "special" features like "all alpha gates" if fn, found := f.special[k]; found {
Change:
/kind bug What happened: Kubelet CSI client checks for an exact version match. What you expected to happen: Kubelet CSI client checks for a Major.Minor.X match. It should not check that the patch level matches. cc:
/sig storage

Discussion:
vers := rsp.GetSupportedVersions() glog.V(4).Info(log("driver reports %d versions supported: %s", len(vers), versToStr(vers))) <ins> // If our supported version is still at 0.X.X, then check // also the minor number. If our supported version is >= 1.X.X // then check only the major number. </ins> for _, v := range vers { <del> //TODO (vladimirvivien) use more lenient/heuristic for exact or match of ranges etc if verToStr(v) == verToStr(ver) { </del> <ins> if ver.GetMajor() == uint32(0) && (ver.GetMajor() == v.GetMajor() && ver.GetMinor() == v.GetMinor()) { supported = true break } else if ver.GetMajor() != uint32(0) && ver.GetMajor() == v.GetMajor() { </ins> supported = true break }

mustFail bool err      error }{ <ins> {testName: "supported version", ver: &csipb.Version{Major: 0, Minor: 0, Patch: 0}}, </ins> {testName: "supported version", ver: &csipb.Version{Major: 0, Minor: 1, Patch: 0}}, <del> {testName: "unsupported version", ver: &csipb.Version{Major: 0, Minor: 0, Patch: 0}, mustFail: true}, </del> <ins> {testName: "supported version", ver: &csipb.Version{Major: 0, Minor: 1, Patch: 10}}, {testName: "supported version", ver: &csipb.Version{Major: 1, Minor: 1, Patch: 0}}, {testName: "supported version", ver: &csipb.Version{Major: 1, Minor: 0, Patch: 10}}, {testName: "unsupported version", ver: &csipb.Version{Major: 10, Minor: 0, Patch: 0}, mustFail: true}, {testName: "unsupported version", ver: &csipb.Version{Major: 0, Minor: 10, Patch: 0}, mustFail: true}, </ins> {testName: "grpc error", ver: &csipb.Version{Major: 0, Minor: 1, Patch: 0}, mustFail: true, err: errors.New("grpc error")}, }
Change:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: I created a custom resource definition with -this is important - scope "Cluster". Then I created an element of that kind. Then I fetched the element and saw that the "metadata.selfLink" attribute had an incorrect value. The path did not contain the custom resource name. Trying to fetch the element using API results in 404 response. What you expected to happen: The "metadata.selfLink" of an instance of a custom resource should be correct. How to reproduce it (as minimally and precisely as possible): Prepare a custom resource definition with scope: Cluster (important! with scope Namespaced the selfLink is correct) in a file (slightly modified standard example from here: ) Create it: Now prepare a custom object in a file my- with this content: And create it: Now get the custom object list: The result is: As you can see the selfLink is . This is wrong, it should be . Using the selfLink as it is causes 404 when fetching the resource via API. Anything else we need to know?: This only happens when the custom resource definition has scope: Cluster. Environment: Kubernetes version (use ): v1.9.2 Cloud provider or hardware configuration: 2017 Macbook Pro OS (e.g. from /etc/os-release): macOS High Sierra 10.13.3 Kernel (e.g. ): Darwin Kernel Version 17.4.0 Install tools: minikube 0.24.1
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
Reiterating the mentions to trigger a notification: <detailsIn response to : </details
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
/assign
Created the PR:
/cc

Discussion:
selfLinkPrefix := "" switch crd.Spec.Scope { case apiextensions.ClusterScoped: <del> selfLinkPrefix = "/" + path.Join("apis", crd.Spec.Group, crd.Spec.Version) + "/" </del> <ins> selfLinkPrefix = "/" + path.Join("apis", crd.Spec.Group, crd.Spec.Version) + "/" + crd.Status.AcceptedNames.Plural + "/" </ins> case apiextensions.NamespaceScoped: selfLinkPrefix = "/" + path.Join("apis", crd.Spec.Group, crd.Spec.Version, "namespaces") + "/" }

t.Fatal(err) } <del> if e, a := "/apis/mygroup.example.com/v1beta1/foo", createdCurletInstance.GetSelfLink(); e != a { </del> <ins> if e, a := "/apis/mygroup.example.com/v1beta1/curlets/foo", createdCurletInstance.GetSelfLink(); e != a { </ins> t.Errorf("expected %v, got %v", e, a) } }