jiebi/CodeConvo huggingface dataset:
Change:
"strings" "time" <ins> "gopkg.in/gcfg.v1" </ins> "k8s.io/kubernetes/pkg/api" apiservice "k8s.io/kubernetes/pkg/api/service" "k8s.io/kubernetes/pkg/api/unversioned"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"4+", GitVersion:"v1.4.0-alpha.3.317+", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-01T05:48:36Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"4+", GitVersion:"v1.4.0-alpha.3.317+", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-01T05:48:36Z", GoVersion:"go1.7", Compiler:"gc", Platform:"linux/amd64"} What happened: Dynamic provisioned volumes in different zones with master failed to deleted What you expected to happen: Since the volume can be dynamic provisioned when the zones differs from master, then it should be deleted after delete the PVC which created them. How to reproduce it (as minimally and precisely as possible): up an all-in-one cluster. The instance is created in zone us-central1-a. several storageClass. One in zone us-central1-a. Another in zone us-central1-b. several PVC. pvc1 using storageClass1(zone us-central1-a), pvc2 using storageClass2(zone us-central1-b). PV/volume were provisioned in proper size/mode/zone. PVCs. with volume in zone us-central1-b failed with error can not find the volume.

Anything else do we need to know: Name: pvc--70d1-11e6-b17e- Labels: failure- failure- Status: Failed Claim: default/pvc5 Reclaim Policy: Delete Access Modes: RWO Capacity: 4Gi Message: Delete of volume "pvc--70d1-11e6-b17e-" failed: GCE persistent disk not found: "kubernetes-dynamic-pvc--70d1-11e6-b17e-" Source: Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine) PDName: kubernetes-dynamic-pvc--70d1-11e6-b17e- FSType: Partition: 0 ReadOnly: false Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message 11m 11m 1 {persistentvolume-controller } Warning VolumeFailedDelete Delete of volume "pvc--70d1-11e6-b17e-" failed: GCE persistent disk not found: "kubernetes-dynamic-pvc--70d1-11e6-b17e-" creationTimestamp: '2016-09-01T22:49:26.439-07:00' description: '{"":"pvc--70d1-11e6-b17e-","":"pvc5","":"default"}' id: '' kind: compute#disk name: kubernetes-dynamic-pvc--70d1-11e6-b17e- selfLink: sizeGb: '4' status: READY type: zone:
Kubernetes can delete GCE PDs only in zones it manages. I.e. either in the same zone as the master or, when multizone is enabled in GCE config, in all zones in the same region. This should not be allowed in the first place. Kubernetes should not create disks outside zones it manages and report an error instead. So... please use following , it will be allow creation/deletion of disks in all zones in us-central1 region: And I'll fix Kubernetes to report an error when creating a disk in all other zones.
Change:
} func getFakeCSINodeLister(csiNode *storagev1.CSINode) fakeframework.CSINodeLister { <ins> csiNodeLister := fakeframework.CSINodeLister{} </ins> if csiNode != nil { <del> return fakeframework.CSINodeLister(*csiNode) </del> <ins> csiNodeLister = append(csiNodeLister, *csiNode.DeepCopy()) </ins> } <del> return fakeframework.CSINodeLister{} </del> <ins> return csiNodeLister </ins> } func getNodeWithPodAndVolumeLimits(limitSource string, pods []*v1.Pod, limit int64, driverNames ...string) (*framework.NodeInfo, *storagev1.CSINode) {

Discussion:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.
Change:
return utilerrors.NewAggregate(errs) } <del> if strings.HasSuffix(gvk.Kind, "List") { </del> <ins> if (gvk == schema.GroupVersionKind{Version: "v1", Kind: "List"}) { </ins> return utilerrors.NewAggregate(v.validateList(obj)) }

Discussion:
<!-- 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: I've created a CRD with the name . There is no validation specified on the CRD object. Creating the CRD itself succeeds, but attempting to create CRD resources with of that type fails with a validation error. What you expected to happen: I expect to be able to create CRD resources of type without a validation error. How to reproduce it (as minimally and precisely as possible): A normal working CRD example, : Applying this succeeds as expected: Simply changing the name of the CRD kind to breaks however, : CRD creates, but the actual resource fails validation: If you supply the object does create correctly. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Digitalocean VM cluster OS (e.g. from /etc/os-release): Server (Ubuntu 14.04.5) Client (Ubuntu 16.04.4) Kernel (e.g. ): Server (4.4.0-111-generic) Client (4.13.0-38-generic) Install tools: Others:
/sig api-machinery /area custom-resources
is a special suffix for name. When you create a object using , which will be render as instead of plain . That's why error occurs due to missing item list.
This sounds like a bug in , not a thing that should be "fixed" by restricting names.
I think the magic suffix is somewhat unexpected, but in the case that it doesn't change -- I would expect a warning or error when creating a CRD with that name. As for this specific behavior, I would consider it a bug -- there's no indication that the kubectl validation is against a different than the one explicitly specified in the resource, and confusingly disabling validation causes the operation to succeed normally (creating the explicitly defined resource , regardless of magic suffix).
cc
cc
PTAL . It is a kubectl bug.
Thanks! Fix works for me
Change:
} if test.statusCode != 0 { if resp.StatusCode != test.statusCode { <del> t.Errorf("%d: unexpected response: %#v", resp) </del> <ins> t.Errorf("%d: unexpected response: %#v", i, resp) </ins> } continue } if resp.StatusCode != http.StatusOK { <del> t.Errorf("%d: unexpected response: %#v", resp) </del> <ins> t.Errorf("%d: unexpected response: %#v", i, resp) </ins> } var itemOut metav1alpha1.Table <del> if _, err = extractBody(resp, &itemOut); err != nil { </del> <ins> body, err := extractBody(resp, &itemOut) if err != nil { </ins> t.Fatal(err) } if !reflect.DeepEqual(test.expected, &itemOut) { <ins> t.Log(body) </ins> t.Errorf("%d: did not match: %s", i, diff.ObjectReflectDiff(test.expected, &itemOut)) } }

Discussion:
Making an API request for table output and specifying the parameter causes a server error in parameter conversion, and an inaccurate error message in response: server log: E0804 09:41:14. ] apiserver received an error that is not an metav1.Status: converting (url.Values).[]string to (v1alpha1.TableOptions).v1alpha1.IncludeObjectPolicy: couldn't copy '[]string' into 'v1alpha1.IncludeObjectPolicy'; didn't understand types
Ugh, typed strings.
Change:
} function kube::release::gcs::stage_and_hash() { <ins> kube::build::ensure_tar </ins> # Split the args into srcs... and dst local -r args=( "$@" ) local -r split=$((${#args[@]}-1)) # Split point for src/dst args

Discussion:
Since I've been having troubles with installation, I've digged a bit and found out that the permissions inside Kubernetes tarballs changed between 0.16.0 and 0.17.0. I've downloaded both tarballs, extracted them into separate directories and then extracted the Kubernetes server tarballs. This is what I get: I suppose, there has been a concious decision to restrict the world's access to those binaries. However, this breaks the installation routine mentioned above and probably makes life a bit more difficult in several other places. I'd be thankful for a correction if this wasn't intended or a pointer to the appropriate commit it this is legit -- I'd correct the installation.
assigning this to you to decide who the eventual assignee should be :)
Any news on this front? 0.20.1 is still restricted.
Apologies for the issue. It wasn't intentional -- likely an artifact of build scripts being run by different people? I'll check out 0.20.2 as I build it to make sure it has the right perms.
Apologies, but 0.20.2 didn't include fixed permissions. I now understand the issue, : "make release" builds a tarball using the permissions on files in your local git tree. I had "umask 027" set when I cloned, so those in-the-repo files had no world-readable perms. Setting "umask 022" before running "make release" is not enough -- it has to be part of creating the local tree when cloning. I'll update instructions and the next release (20.3 or 21.0) should fix this issue. And longer term, we need to put a bit more effort into releasing from a known-good environment and not rely on a developer's workstation's idiosyncrasies -- sorry this bit you.
I can't repro Trying again a different way, but I don't think the umask before clone should do anything (in particular, umasks aren't "sticky" on files, they're sticky to processes.)
And let's pretend on my personal fork isn't woefully out of date (who uses master on their personal fork? I should really just delete that that thing.) Comment updated.
Ah, I see the problem now.

works fine for the server tar, but the full tar also packages examples, etc., and for that, tar tends to just pick up the permissions of the git tree. Got it.
I'll take this. I'm going to write a script to build official bits, and this is easy enough to fix along the way.
Seems not fixed as of Kubernetes 1.0.7
sorry about that. is doing the 1.1.1 release and has been improving release scripts -- is 1.1.1 good re: permissions?
was not built by .
Reassigning to as release-oncall. Quinton, I can mentor or advise as necessary.
And yeah, is fine: There's no real bug here. There was a process issue that occurred with 1.0.7. We can rebuild the binaries if we need to.
FYI, leaving this issue closed, as per 's comment above. If anyone disagrees, please re-open this issue.
Change:
"testing" "time" <ins> "k8s.io/apimachinery/pkg/api/errors" </ins> "k8s.io/apimachinery/pkg/api/meta" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured"

Discussion:
Kubernetes version (use ): Kubernetes HEAD Environment: Cloud provider or hardware configuration: linux OS (e.g. from /etc/os-release): Kernel (e.g. ):NAME=Fedora25 What happened: apiserver panic What you expected to happen: No panic How to reproduce it (as minimally and precisely as possible): Testcase is going to be sent as a PR
Fixed by
Change:
ginkgo.By("by waiting for hugepages resource to become available on the local node") gomega.Eventually(func() string { return pollResourceAsString(f, "hugepages-2Mi") <del> }, 30*time.Second, framework.Poll).Should(gomega.Equal("100Mi")) </del> <ins> }, 30*time.Second, framework.Poll).Should(gomega.Equal("10Mi")) </ins> }) runHugePagesTests(f)

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: -tests Since when has it been failing: Unsure Testgrid link: Reason for failure: Unable to pre allocate 50x2MiB huge pages, probably due to memory pressure caused by kernel level caching. If requesting an substantial amount of huge page memory (like the tests), it is recommended to to it as early after boot as possible, or by using the kernel cmd line. Eg. this one: Anything else we need to know: will fix this issue, but in awaiting for that, we can just decrease the page count in the tests.
/sig node /cc derekwaynecarr
I think the reason of railure should be because a single hugepage of x86 is 2MiB as and a single page is 4KiB, not 2KiB.
Yes, is correct. Thanks for catching the typo :smile:
Looks like we still have some flakes in the huge page test, even tho the test now only requests of huge page memory. Happens way less frequently than previously tho. This is probably because the kernel is caching a lot of stuff, making it hard for the kernel to fix it. Ill do some testing with dropping the caches (no user facing stuff will happen, only kernel level) before trying to pre allocate huge pages. /reopen
Reopened this issue. <detailsIn response to : Looks like we still have some flakes in the huge page test, even tho the test now only requests of huge page memory. Happens way less frequently than previously tho. 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
/close
Closing this issue. <detailsIn response to : /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:
b2.create(ctx, pod2claim1, pod2) framework.ExpectNoError(e2epod.WaitForPodRunningInNamespace(ctx, f.ClientSet, pod2), "start pod 2") <del> // Allow allocation of pod1 claim2, claim3 to proceed. It should fail now </del> <ins> // Allow allocation of second claim in pod1 to proceed. It should fail now </ins> // and the other node must be used instead, after deallocating // the first claim. ginkgo.By("move first pod to other node")

Discussion:
What happened: Shortly after was merged, the "multiple nodes reallocation works" E2E DRA test started to fail randomly. Please provide links to example occurrences, if any: /sig node /kind bug needs to stay green. No response master n/a No response No response No response No response
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:
import ( "fmt" <del> scheduling "k8s.io/api/scheduling/v1alpha1" </del> <ins> scheduling "k8s.io/api/scheduling/v1beta1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" )

Discussion:
/kind bug What happened: When I try to create a priorityclass object like: It fails with And when I try create it with yaml file like: It works. What you expected to happen: Create a priorityclass object with kubectl.
/sig cli
Do you have --runtime- set in kube-apiserver?
No, if set this, it works.
Agree this is a bug. v1beta1 should be preferred.
/sig scheduling
Change:
assert.Equal(t, ns1.Name, createdNamespace2.Name) // assert.Contains(t, createdNamespace2.Annotations, "A") <ins> ns1.DeletionTimestamp = &unversioned.Time{Time: time.Now()} namespaceWatch.Modify(&ns1) assert.Equal(t, ns1.Name, GetStringFromChan(nsDeleteChan)) assert.Equal(t, "all", GetStringFromChan(rsDeleteChan)) assert.Equal(t, "all", GetStringFromChan(serviceDeleteChan)) assert.Equal(t, "all", GetStringFromChan(secretDeleteChan)) </ins> close(stop) } <ins> func RegisterDeleteCollection(client *core.Fake, resource string) chan string { deleteChan := make(chan string, 100) client.AddReactor("delete-collection", resource, func(action core.Action) (bool, runtime.Object, error) { deleteChan <- "all" return true, nil, nil }) return deleteChan } func RegisterDelete(client *core.Fake, resource string) chan string { deleteChan := make(chan string, 100) client.AddReactor("delete", resource, func(action core.Action) (bool, runtime.Object, error) { deleteAction := action.(core.DeleteAction) deleteChan <- deleteAction.GetName() return true, nil, nil }) return deleteChan } func GetStringFromChan(c chan string) string { select { case str := <-c: return str case <-time.After(5 * time.Second): return "" } } </ins> func GetNamespaceFromChan(c chan runtime.Object) *api_v1.Namespace { namespace := GetObjectFromChan(c).(*api_v1.Namespace) return namespace

Discussion:
In PR the specific resource types are handled explicitly. Need to delete them in more generic way, in a similar way that namespace controller does.
- switching this to 1.6 as it's too late for 1.5. ok? (please switch it right back if you disagree)
did fix this?
Please close or move to next-candidate with work remaining to be done.
Yes fixed by
Change:
--dry-run[=false]: If true, only print the object that would be sent, without sending it. --env=[]: Environment variables to set in the container --expose[=false]: If true, a public, external service is created for the container(s) which are run <del> --generator="": The name of the API generator to use.  Default is 'deployment/v1beta1' if --restart=Always, otherwise the default is 'job/v1'. </del> <ins> --generator="": The name of the API generator to use.  Default is 'deployment/v1beta1' if --restart=Always, otherwise the default is 'job/v1'.  This will happen only for cluster version at least 1.2, for olders we will fallback to 'run/v1' for --restart=Alwyas, 'run-pod/v1' for others. </ins> --hostport=-1: The host port mapping for the container port. To demonstrate a single-machine container. --image="": The image for the container to run. -l, --labels="": Labels to apply to the pod(s).

Discussion:
Tested with: Most of the simple basic starting guides direct users to create a cluster with . If I run kubectl 1.2 against a 1.1 cluster, I'll get the following behavior now I happen to know I can get the old behavior by doing but I don't expect an average user to know that or be able to find it easily. I'm mainly concerned that we will be breaking recommended flow for GKE users if they happen to use a new kubectl before their cluster's master is upgraded. We can just update our docs, but breaking a "porcelain" command seems like poor form. Other options include defaulting to the generator for a few patch releases, and/or making do some kind of version check so it can fallback to the generator if deployments/jobs are not available. thoughts?
We should update those docs and document how to achieve stable behavior: .
This would ideally use API discovery, though, to check whether the API exists.
How hard would it be to check whether Deployment existed? We had the same issue in 1.1, btw, with Job.
I'd accept a hack, also, which checked the k8s version if there wasn't enough discovery info in 1.1.
We have the same issue with Job in 1.2, also.
Fix is in
Change:
"k8s.io/klog/v2" <del> "k8s.io/apimachinery/pkg/types" </del> "k8s.io/apimachinery/pkg/util/sets" utilfeature "k8s.io/apiserver/pkg/util/feature" pluginapi "k8s.io/kubelet/pkg/apis/deviceplugin/v1beta1" kubefeatures "k8s.io/kubernetes/pkg/features" "k8s.io/kubernetes/pkg/kubelet/cm/devicemanager/checkpoint" <del> "k8s.io/kubernetes/pkg/kubelet/cm/util/cdi" </del> kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" )

Discussion:
Kubelet should stop using annotations to pass CDI device IDs to CRI runtimes. CDIDevices CRI field should be used for this purpose. This should be done when Kubelet that doesn't support CRI field reaches EOL and two major CRI runtimes support CRI field. Here is a PR comment that gives more details about this: Kubelet started using CDIDevices CRI field in . Previous version 1.27 will reach EOL .CRI-O started using it in . Previous version 1.27 will reach EOL together with Kubernetes 1.27.Containerd started using it in . Version 1.7 will reach EOL in a 6 months after Containerd 2.0 release Previous version 1.6 doesn't support CDI injections and should not be considered. So, safer option would be to wait until Containerd 1.7 reaches EOL. However it's relatively safe to do it earlier when 1.7.0 and 1.7.1 have little chances to be in real use. Containerd v1.7.0 and v1.7.1 is not used by the Linux distributions from , so it's safe to remove annotations support from the Kubelet in 1.31 in my opinion.
/sig node
/triage accepted /priority important-longterm
/assign
Change:
GO_OUT="${KUBE_ROOT}/_output/local/bin/${host_os}/${host_arch}" APISERVER_LOG=/tmp/kube-apiserver.log <del> "${GO_OUT}/kube-apiserver"  </del> <ins> sudo "${GO_OUT}/kube-apiserver"  </ins> -v=${LOG_LEVEL}  --address="${API_HOST}"  --port="${API_PORT}" 

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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
looks like started a few days ago ! /sig cluster-lifecycle
cc
fix was sent earlier
/sig cluster-lifecycle
thanks :) i saw it yesterday and forgot to raise the issue. i should have checked the PR queue :)
Change:
// equivalent returns true if the two services are equivalent.  Fields which are expected to differ between // federated services and the underlying cluster services (e.g. ClusterIP, NodePort) are ignored. <del> func equivalent(federationService, clusterService v1.Service) bool { clusterService.Spec.ClusterIP = federationService.Spec.ClusterIP for i := range clusterService.Spec.Ports { clusterService.Spec.Ports[i].NodePort = federationService.Spec.Ports[i].NodePort </del> <ins> func equivalent(clusterService, federationService v1.Service) bool { federationService.Spec.ClusterIP = clusterService.Spec.ClusterIP for i := range federationService.Spec.Ports { federationService.Spec.Ports[i].NodePort = clusterService.Spec.Ports[i].NodePort } if federationService.Spec.ExternalTrafficPolicy == v1.ServiceExternalTrafficPolicyType("") { federationService.Spec.ExternalTrafficPolicy = clusterService.Spec.ExternalTrafficPolicy </ins> } if federationService.Name != clusterService.Name || federationService.Namespace != clusterService.Namespace {

Discussion:
Test pull-kubernetes-federation-e2e-gce for PR is failing. pull-kubernetes-federation-e2e-gce https://k8s- pull-kubernetes-federation-e2e-gce test this
/sig federation /assign
cc
Details on the types of failures and frequency: In the last two days in particular, the following tests have been timing out: [] Federated Services [Feature:Federation] with clusters Federated Service should create and update matching services in underlying clusters [] Federated Services [Feature:Federation] with clusters DNS should be able to discover a federated service [] Federated Services [Feature:Federation] with clusters Federated Service should recreate service shard in underlying clusters when service shard is deleted cc:
Thanks. And yes we are aware of it. is working on a fix - PR .
Hi I'm trying to find out how to follow up on this. Will there be some sort of notification for the PRs affected this?
I just re-queue that test on your PR. note that the test isn't blocking, so your PR can be reviewed/merged without this test passing.
good to know. Thanks!
you can't re-open an issue unless you authored it or you are assigned to it. <detailsIn response to : /reopen 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. I understand the commands that are listed . </details
/reopen
Reopening to have an issue to track this. This was thought to be resolved, and was made blocking in There's still something up, and it was reverted in I believe sig-federation is going to look at this more next week in order to figure out a more permanent solution to this.
Closing this in favor of issue which has linked runs which more accurately describe the problem.