jiebi/CodeConvo huggingface dataset:
Change:
newJobSchedule string } tests := []struct { <del> name                 string fields               fields args                 args deltaTimeForQueue    time.Duration roundOffTimeDuration time.Duration </del> <ins> name              string fields            fields args              args deltaTimeForQueue time.Duration </ins> }{ { name: "spec.template changed", fields: fields{ <del> queue:          workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "test-update-cronjob"), </del> <ins> queue:          &fakeQueue{RateLimitingInterface: workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), "test-update-cronjob")}, </ins> recorder:       record.NewFakeRecorder(10), jobControl:     jc, cronJobControl: cjc,

Discussion:
pull-kubernetes-unit TestController2updateCronJob/spec.schedulechanged TestController2_updateCronJob /sig apps /assign
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
This is important to resolve before promotion to v1
looks like the cause was
This function should be related.
Another one:
When the flake happen, there are messages like When the system is overloaded, it would happen. is trying to replace the current queue in tests with a mock.
Yeah, I spoke with to make sure we use a mock of the queue so we only get the most important bit of information ignoring the remaining parts
Change:
for _, v := range vmMoList[0].Guest.Net { if vs.cfg.Network.PublicNetwork == v.Network { for _, ip := range v.IpAddress { <del> if net.ParseIP(ip).To4() != nil { </del> <ins> if !net.ParseIP(ip).IsLinkLocalUnicast() { </ins> nodehelpers.AddToNodeAddresses(&addrs, v1.NodeAddress{ Type:    v1.NodeExternalIP,

Discussion:
What happened: IP addresses losing in k8s node status in a pure ipv6 vsphere environment. all interfaces of nodes in this cluster are ipv6 only The error logs in kubelet as the following: What you expected to happen: It will be very appreciated if we can get ipv6 addresses from vsphere cloud provider as ipv4 env How to reproduce it (as minimally and precisely as possible): deploy k8s cluster in vsphere pure ipv6 envirenment Anything else we need to know?: From the code we can know that while the provider retrieves VM’s IP, It uses To4() function for all ip addresses from vsphere platform, this function can’t handle ipv6 addresses as mentioned in guild: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vsphere OS (e.g: ):Kernel (e.g. ):Install tools: ansible Network plugin and version (if this is a network-related bug): calico v3.5.6 Others:
If you agree with this I can fix it.
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
/sig cloud-provider
cc /remove-sig contributor-experience
/cc
please help to review, I think I can fix the issue by PR /sig cloud-provider Thanks a lot
/assign
Change:
import ( "fmt" <del> "reflect" </del> <ins> apiequality "k8s.io/apimachinery/pkg/api/equality" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" unversionedvalidation "k8s.io/apimachinery/pkg/apis/meta/v1/validation" "k8s.io/apimachinery/pkg/labels"

Discussion:
/kind bug When deploying a StatefulSet, I included a PVC that specified for the storage capacity. worked perfectly. Running again without making any changes failed with the error: After comparing the server-side yaml to my original, I noticed that it had changed the storage capacity of my PVC to . Changing my original from to allowed me to then successfully run . There is clearly a string representation being used to compare those changes rather than converting to bytes and comparing the numeric representation. How to reproduce it (as minimally and precisely as possible): Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-06-27T22:29:25Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-06-21T11:34:22Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Azure AKS
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
cc This is probably an issue for any resource.Quantity type.
/sig api-machinery
the issue is use of in statefulset update validation, instead of : explicitly compares quantity objects semantically:
/sig apps
fix is in with picks open to 1.11, 1.10, 1.9
Change:
"type": "string" }, "protocol": { <del> "type": "string" </del> <ins> "type": "string", "nullable": true </ins> } }, "required": [

Discussion:
With in a CRD we get: This is because gnostic's OpenAPI proto types have no nullable support. Luckily CRDs keep working because in the upper error case we don't stop serving, just set the SSA schema to nil.
Thanks for reporting!
I think it should be "This is because gnostic's OpenAPI v2 proto types have no nullable support.". The problem is that we're not supposed to pass-in v3.
Source:
OK, We'll write a test and fix this, thanks Stefan!
/reopen This still happens in slightly different shape: This comes from :
That's a fairly different bug but yes, thanks!
Is this related to the stating that use of "anyOf" wouldn't be allowed after 1.16? We're seeing issue on OpenFaaS after going to 1.17.5 and 1.18. Usually upgrading K8s versions hasn't caused breaking changes and we're trying to figure out where to start with this one.
No. That post was about structural schemas. v1 CRDs are limited to structural schemas. v1beta1 CRDs can continue to create non-structural schemas until v1beta1 is no longer served (in 1.22) Also, is not completely disallowed, specific restrictions inside an clause (like ) are what are not allowed ("logical constraints using oneOf, allOf, anyOf, not are allowed").
extracted the newly found issue to to track separately with isolated reproducer /close
Closing this issue. <detailsIn response to : extracted the newly found issue to to track separately 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:
func verifyPrefixOfSecretResource(t *testing.T, wantPrefix string, test *transformTest) { // implementing this brute force approach instead of fancy channel notification to avoid test specific code in prod. // wait for config to be observed <del> verifyIfKMSTransformersSwapped(t, wantPrefix, test) </del> <ins> verifyIfKMSTransformersSwapped(t, wantPrefix, "", test) </ins> // run storage migration secretsList, err := test.restClient.CoreV1().Secrets("").List(

Discussion:
transformation expandless | 14m1s Failed; === RUN TestEncryptionConfigHotReload TestEncryptionConfigHotReload When I see this flake, 10-09 is the first one.(But the job history in the testgrid only started from 10-03) some PR that may be related: /sig auth /cc
/cc
/triage accepted
/cc failed two times in recent 3 runs:
/reopen as of this is still .
Reopened this issue. <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. </details
Change:
} else { volumePluginDir = gciVolumePluginDirLegacy } <del> } else if node != nil && framework.NodeOSDistroIs("gci") { </del> <ins> } else if node != nil && framework.NodeOSDistroIs("gci", "ubuntu") { </ins> if getNodeVersion(node).AtLeast(versionutil.MustParseGeneric(gciVolumePluginDirVersion)) { volumePluginDir = gciVolumePluginDir } else {

Discussion:
https://k8s- https://k8s- It passes on COS. /cc
I can look into this, since likely this was introduced because of latest changes I made.
This looks like a timing thing - because I can see message in logs , but I think 5 minutes is not enough for the pod to come up after installing flexvolume.
That's strange, the dummy driver just sets up a tmpfs so it should be fairly quick. I wonder if there's something else blocking pod creation?
the driver is not being installed on kubelet I am doing some more investigating, have my own cluster up.
On ubuntu, we set the flexvolume install dir to --volume-plugin-dir=/home/kubernetes/fl exvolume Small oversight, I'll make a PR shortly
They are still failing, I am having another look e: Same as before, it is not installing on the node. I started my test cluster using (basically...) the same kubetest command sooo allow me to try again. e2: it's a false alarm. The tests are not using a commit with my fix in it yet zzzz
Change:
}, }, expectedUpdateCalls: []fakecloud.UpdateBalancerCall{ <ins> {Service: etpLocalservice1, Hosts: []*v1.Node{node1, node2, node3}}, {Service: etpLocalservice2, Hosts: []*v1.Node{node1, node2, node3}}, </ins> {Service: service3, Hosts: []*v1.Node{node1, node2, node3}}, }, }, {

Discussion:
In 1.26 the service controller in the Kubernetes cloud controller manage (KCCM) introduced a new mechanism for syncing load balancers based on predicates. The predicates applied will depend on "service classes", specifically if it's or , see: This implementation is not well suited for internal GCP load balancers which use InstanceGroups. from Google, feel free to correct me: any cluster has all nodes grouped together into an instance group. Service of have individual GCP load balancers, but these load balancers end up referencing the same instance group (which is the cluster's instance group). This means that the inclusion/exclusion predicates for any service, will trickle down and impact the cluster's global instance group, thereby impacting other services which don't necessarily apply the same set of predicates. Ex: services exclude nodes, whereas do not. A Node going will therefore be removed from all backends for services, however on GCP with load balancer solution based on InstanceGroups: this means that the same node will be removed from all backends for services too. This is NOT a problem on = 1.27 using the feature , because all services on 1.27 using that feature gate will have the same set of predicates. Node updates requiring the removal of the instance from load balancers belonging to services of should not impact other services of . Bring up a cluster using "Internal load balancers" on GCP. Define two services, one being and the other . Have one node go . The instance corresponding to that Node might be removed from the InstanceGroup backend of the service. This will depend on the order the services are synced, if the service is synced last then the instance will be removed. This is actually not really that bad, because the only different predicate between both is the readiness condition - and a node should go back to if all is fine, and finally be included. But I wanted to raise this for issue for completeness sake so that it is known. <details</details<detailsGCP </details<details</details<details</details<details</details<details</details
/sig network /sig cloud-provider /cc
/triage accepted
Change:
if prevItem == nil { return nil, admission.NewForbidden(a, fmt.Errorf("unable to get previous usage since prior version of object was not found")) } <del> prevUsage := evaluator.Usage(prevItem) deltaUsage = quota.Subtract(deltaUsage, prevUsage) </del> <ins> // if we can definitively determine that this is not a case of "create on update", // then charge based on the delta.  Otherwise, bill the maximum metadata, err := meta.Accessor(prevItem) if err == nil && len(metadata.GetResourceVersion()) > 0 { prevUsage := evaluator.Usage(prevItem) deltaUsage = quota.Subtract(deltaUsage, prevUsage) } </ins> } if quota.IsZero(deltaUsage) { return quotas, nil

Discussion:
With the migration to podutils and adding some presubmits (from periodic jobs) we are seeing some failures in presubmits. The error seems to have issues finding the right node to create.
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 /sig testing
any leads on solving this one?
see notes on slack -
/assign
this looks good now!
Change:
}, }, { <ins> name: "handles empty object name", infos: []*resource.Info{ { Mapping: &meta.RESTMapping{ Resource: schema.GroupVersionResource{Group: "group", Version: "version", Resource: "theresource"}, }, Namespace: "ns-foo", }, }, fakeClient: func() *dynamicfakeclient.FakeDynamicClient { return dynamicfakeclient.NewSimpleDynamicClient(scheme) }, timeout:     10 * time.Second, expectedErr: "resource name must be provided", validateActions: func(t *testing.T, actions []clienttesting.Action) { if len(actions) != 0 { t.Fatal(spew.Sdump(actions)) } }, }, { </ins> name: "times out", infos: []*resource.Info{ {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: I created a job with metadata.generateName twice and waited for completion, but got: panic: interface conversion: runtime.Object is unstructured.UnstructuredList, not unstructured.Unstructured What you expected to happen: kubectl to wait for the last job to complete. How to reproduce it (as minimally and precisely as possible): kubectl create -f kubectl create -f kubectl wait --for=condition=complete -f (shortened): apiVersion: batch/v1 kind: Job metadata: generateName: my-job- Anything else we need to know?: Environment: Kubernetes version (use ): 1.11.3 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I have to choose a sig, but I am not sure which one is right...
Reiterating the mentions to trigger a notification: <detailsIn response to : I have to choose a sig, but I am not sure which one is right... 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
/sig cli /sig apps
/assign
kubectl get -f also doesn't work as expected.
/remove-sig apps
Change:
type unsetConfigTest struct { description string <del> config      clientcmdapi.Config //initiate kubectl config args        []string            //kubectl config unset args expected    string              //expect out </del> <ins> config      clientcmdapi.Config args        []string expected    string expectedErr string </ins> } func TestUnsetConfigString(t *testing.T) {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5.3 Environment: Cloud provider or hardware configuration: minikube 0.17.1 How to reproduce it (as minimally and precisely as possible): config Note that there's only one context. the property of a non-existent context config Note that a context named foo was created just because I tried to unset a property. What you expected to happen: should give an informative message saying that context doesn't exist. Anything else we need to know: This is probably low-hanging fruit.
/sig cli
/assign i will take a look for this
GitHub didn't allow me to assign the following users: a, look, for, this, i, will, take. Note that only can be assigned. <detailsIn response to : /assign i will take a look for this 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 this, this is a bug, have open PR fix this. thanks
/kind bug
Change:
# See https://github.com/golang/go/issues/16086 for details. go install ./cmd/... <del> # Use eval to preserve embedded quoted strings. eval "goflags=(${GOFLAGS:-})" </del> # Filter out arguments that start with "-" and move them to goflags. targets=() for arg; do

Discussion:
What happened: When building kubernetes from source for 1.10 it was possible to limit the parallel linker calls using GOFLAGS="-p 1". (I understand that the new format is GOFLAGS="-p=1" so I am using that) With kubernetes 1.11 the build aborts: What you expected to happen: The build should complete, using just one process for linking. How to reproduce it (as minimally and precisely as possible): export GOFLAGS="-p=1" make -j1 Anything else we need to know?: The environment is quite memory constrained, therefore preventing the build to fork a linker for each CPU is required. Any other option instead of the GOFLAGS would work as well. Environment: Kubernetes version (use ): 12.0 OS (e.g. from /etc/os-release): Arch Linux ARM Others: go version go1.11.1 linux/arm64
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
/sig testing
This is because a change in go 1.11, see , and related go issues: , etc. I've opened a PR to address this: .
/assign
Change:
pod := StartInPodWithInlineVolume(client, t.Namespace, "inline-volume-tester", command, volumes, t.ReadOnly, t.Node) defer func() { // pod might be nil now. <del> StopPod(client, pod) </del> <ins> StopPodAndDependents(client, pod) </ins> }() framework.ExpectNoError(e2epod.WaitForPodRunningInNamespaceSlow(client, pod.Name, pod.Namespace), "waiting for pod with inline volume") runningPod, err := client.CoreV1().Pods(pod.Namespace).Get(context.TODO(), pod.Name, metav1.GetOptions{})

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: I0722 06:26:18.056] I0722 06:26:18.057] [Driver: csi-hostpath] I0722 06:26:18.057] I0722 06:26:18.057] [Testpattern: Generic Ephemeral-volume (default fs) [Feature:GenericEphemeralVolume] (late-binding)] ephemeral skipped 448 lines unfoldmore I0722 06:30:33.845] Jul 22 06:30:33.845: INFO: Wait up to 5m0s for pod "inline-volume-tester2-hhcbd" to be fully deleted I0722 06:31:06.117] Jul 22 06:31:06.117: INFO: Pod inline-volume-tester-74jqh has the following logs: /dev/sda1 on /mnt/test-0 type ext4 (rw,nosuid,nodev,noexec,relatime,commit=30) I0722 06:31:06.117] I0722 06:31:06.117] Jul 22 06:31:06.117: INFO: Deleting pod "inline-volume-tester-74jqh" in namespace "ephemeral-9141" I0722 06:31:06.155] Jul 22 06:31:06.155: INFO: Wait up to 5m0s for pod "inline-volume-tester-74jqh" to be fully deleted I0722 06:31:38.264] Jul 22 06:31:38.264: FAIL: no dangling PVCs I0722 06:31:38.264] Expected I0722 06:31:38.265] <[]v1.PersistentVolumeClaim | len:1, cap:1: [ I0722 06:31:38.265] { I0722 06:31:38.265] TypeMeta: {Kind: "", APIVersion: ""}, I0722 06:31:38.

265] ObjectMeta: { skipped 315 lines unfold_more I0722 06:32:16.896] STEP: Destroying namespace "ephemeral-9141" for this suite. I0722 06:32:16.931] Jul 22 06:32:16.931: INFO: Namespace ephemeral-9141 was already deleted I0722 06:32:16.932] STEP: Destroying namespace "ephemeral-522" for this suite. I0722 06:32:16.966] Jul 22 06:32:16.966: INFO: Namespace ephemeral-522 was already del Anything else we need to know: /cc /sig storage /priority critical-urgent /milestone v1.19
I have tracked this down and it looks like that changes were made in that affected how Pods were being deleted in the e2e framework (specifically commit ). This caused failures in other tests, so the commit was reverted in I will have a fix open shortly that uses foreground deletion only for these storage tests. /assign /cc Side note: I see already saw this
Change:
"//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/uuid:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/wait:go_default_library", <ins> "//vendor/k8s.io/client-go/kubernetes:go_default_library", </ins> "//vendor/k8s.io/client-go/kubernetes/typed/certificates/v1beta1:go_default_library", <ins> "//vendor/k8s.io/client-go/rest:go_default_library", </ins> "//vendor/k8s.io/client-go/util/cert:go_default_library", ], )

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): TESTING REQUEST Spawned from: It would be nice with some e2e tests for the Node Authorizer so consumers of it (kubeadm, GCE, GKE, etc.) could easily make sure it's enabled and working, just by editing when running e2e's. I wrote a quick bash script of what it could do: The bash script above is in no way comprehensive enough, but on the other hand it took ~5mins to write :) For now (1.7), we might use something like this bash script in our kubeadm e2e CI job to make sure the Node Authorizer/Admission plugin is enabled correctly. cc
was assigned for triaging this... Does such an e2e test already exist somewhere? said that he could take this on if not...
no negative e2e test exists (make sure things the Node authorizer disallows fail) negative integration tests exist at negative e2e tests for this will be tricky, since you'll need node credentials and a specific authz and admission config.
See the above bash script, I was able to do it purely from kubectl by impersonating the group and node user... If we feature-gate this e2e test, we can run it for the deployments that actually have unique node credentials
cc this maybe could be a good task for you... :)
Cool, thanks for point me this.
You basically only have to implement these commands as an e2e test initially (by impersonating a node in the cluster). Then when that's done, we can check if there are more than these four cases that needs to be verified. This should go under a separate and be enabled in deployments (like kubeadm) where nodes have unique credentials.
I didn't find a way to simulate a node credential, do you have any good idea ? after reading the integration testing code, I fell it's enough the guarantee the quality, WDYT?