jiebi/CodeConvo huggingface dataset:
Change:
it looks like something is up on master. Clean checkout, touch , then -- produces a delta.
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
That comes out clean. ` That comes out clean. That dir, and who knows how many others, is missing some metadata to allow conversions
looks like it might be the v2alpha1 conversion referencing a v1 type... if the generation processes both the v1 and v2alpha1 packages, it finds the v1 conversion. if it only processes the v2alpha1 package, it doesn't and reverts to the reflection-driven path
this breaks: this works: given a clean build leaves no diff, I think master is fine. the script looks like it doesn't include all required dependencies to rebuild a single package
The tool doesn't know - each pkg i supposed to define enough to make itself hermetic
That are not many input dirs. The generator does not see any custom conversion funcs in v1. As expected, adding v1 to the inputs gives the correct output:
/assign fixed in

Discussion:
*/ // +k8s:conversion-gen=k8s.io/kubernetes/pkg/apis/batch <ins> // +k8s:conversion-gen=k8s.io/kubernetes/pkg/apis/batch/v1 </ins> // +k8s:conversion-gen-external-types=k8s.io/api/batch/v1beta1 // +k8s:defaulter-gen=TypeMeta // +k8s:defaulter-gen-input=../../../../vendor/k8s.io/api/batch/v1beta1

*/ // +k8s:conversion-gen=k8s.io/kubernetes/pkg/apis/batch <ins> // +k8s:conversion-gen=k8s.io/kubernetes/pkg/apis/batch/v1 </ins> // +k8s:conversion-gen-external-types=k8s.io/api/batch/v2alpha1 // +k8s:defaulter-gen=TypeMeta // +k8s:defaulter-gen-input=../../../../vendor/k8s.io/api/batch/v2alpha1
Change:
/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

Discussion:
"//pkg/apis/apps:go_default_library", "//pkg/apis/core:go_default_library", "//pkg/apis/core/validation:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/api/equality:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1/validation:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library",

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"

restoreStrategy := statefulSet.Spec.UpdateStrategy statefulSet.Spec.UpdateStrategy = oldStatefulSet.Spec.UpdateStrategy <del> if !reflect.DeepEqual(statefulSet.Spec, oldStatefulSet.Spec) { </del> <ins> if !apiequality.Semantic.DeepEqual(statefulSet.Spec, oldStatefulSet.Spec) { </ins> allErrs = append(allErrs, field.Forbidden(field.NewPath("spec"), "updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden.")) } statefulSet.Spec.Replicas = restoreReplicas
Change:
<!-- 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?: What happened: Not able to change the default storage class. What you expected to happen: Default storage class to change. How to reproduce it (as minimally and precisely as possible): But after few mins. Anything else we need to know?: Tried to remove the annotation but no luck. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: minikube OS (e.g. from /etc/os-release): Buildroot 2018.05 Kernel (e.g. ): 4.16.14 Install tools: minikube Others:
/assign
Those labels are not set on the issue: <detailsIn response to : /remove-sig api-machinery 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 cluster-lifecycle
The cause is that kube-addon-manager is reconciling the standard storage class.
Those labels are not set on the issue: <detailsIn response to : /remove-sig api-machinery 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
Thanks for looking into it. Sorry for native question, I want to keep only ceph as a default storage class how can I do that?
hi I'm not really sure about the actual command to fix this. Basically, you could log into the VM and do the same modification as the PR above does, then restart minikube.
Has the fix made it into minikube yet? I'm still seeing the issue in 0.31.0
Looking at PR , the fix was made in kubernetes core, not minikube. The error still exists in minikube:

Discussion:
annotations: storageclass.beta.kubernetes.io/is-default-class: "true" labels: <del> addonmanager.kubernetes.io/mode: Reconcile </del> <ins> addonmanager.kubernetes.io/mode: EnsureExists </ins> provisioner: kubernetes.io/host-path
Change:
<!-- 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: ip-masq-agent should be scheduled on all the nodes and has the same toleration as the deamon set . See the difference: What you expected to happen: ip-masq-agent tolerate NoSchedule and NoExecute so that it will be scheduled in all nodes. How to reproduce it (as minimally and precisely as possible): Create a node with taint operation=NoSchedule. ip-masq-agent will not be scheduled in that node. Anything else we need to know?: I don't believe this is intended behavior. But if it is, let me know and I will close this issue. Environment: Kubernetes version (use ): HEAD /assign /assign /assign
/sig cluster-lifecycle

Discussion:
- key: config path: ip-masq-agent tolerations: <ins> - effect: NoSchedule operator: Exists - effect: NoExecute operator: Exists </ins> - key: "CriticalAddonsOnly" operator: "Exists"
Change:
Hi, I am currently working on k8s cloud provider and I ran in pkg/cloudprovider package. Turned out that some providers code have unused variables and logic problems. Here is the report: session.New is deprecated some bugs and unused values oauth2.NoContext is deprecated, overwritten ctx and miss error checks missing error check unused values missing error check, loop logic issues Hope this report can help to cloud provider working groups. :)
/kind bug /sig cloud-provider /sig vmware
PR open for vsphere cloud provider
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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
virtualMachineConfigSpec.DeviceChange = append(virtualMachineConfigSpec.DeviceChange, deviceConfigSpec) fileAlreadyExist := false task, err := dummyVM.Reconfigure(ctx, virtualMachineConfigSpec) <ins> if err != nil { glog.Errorf("Failed to reconfig. err: %v", err) return "", err } </ins> err = task.Wait(ctx) if err != nil { fileAlreadyExist = isAlreadyExists(vmdisk.diskPath, err)

} t.Logf("Found InstanceID(%s) = %sn", nodeName, instanceID) <del> instanceID, err = i.InstanceID(context.TODO(), nonExistingVM) </del> <ins> _, err = i.InstanceID(context.TODO(), nonExistingVM) </ins> if err == cloudprovider.InstanceNotFound { t.Logf("VM %s was not found as expectedn", nonExistingVM) } else if err == nil {
Change:
We had mutating webhooks on delete operation. After updating to Kubernetes 1.11, it is failing. Stacktrace: I tried to debug and this is what I found: is nil. Calling causes this error. I see that the code path has not changed since 1.10. But we don't see the same error in 1.10 minikube cluster. I can't explain that. We have stopped using mutating webhook on delete operation anyway, since it does not make much sense. But I thought I should file a bug just in case. /kind bug /sig api-machinery
cc:
thanks for the report... is this on a custom resource or a native resource? edit: nevermind, found in the stack
It is a CRD.
fix is in , pick to 1.11.x in conversion of unstructured objects (used internally for CRDs) changed in 1.11 as part of CRD versioning, which made them actually go through the conversion stack
/assign

Discussion:
} // convert attr.VersionedObject to the internal version in the underlying admission.Attributes <del> return a.plugin.scheme.Convert(attr.VersionedObject, attr.Attributes.GetObject(), nil) </del> <ins> if attr.VersionedObject != nil { return a.plugin.scheme.Convert(attr.VersionedObject, attr.Attributes.GetObject(), nil) } return nil </ins> } // note that callAttrMutatingHook updates attr

if err != nil { return apierrors.NewInternalError(err) } <ins> if len(patchObj) == 0 { return nil } // if a non-empty patch was provided, and we have no object we can apply it to (e.g. a DELETE admission operation), error if attr.VersionedObject == nil { return apierrors.NewInternalError(fmt.Errorf("admission webhook %q attempted to modify the object, which is not supported for this operation", h.Name)) } </ins> objJS, err := runtime.Encode(a.plugin.jsonSerializer, attr.VersionedObject) if err != nil { return apierrors.NewInternalError(err)
Change:
<!-- 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 /sig testing What happened: Tests from are spawning pods with memory limits (30 MB). Running the tests using Windows nodes will cause the Windows nodes to end up in NotReady state. This happens because the Docker service couldn't start that container (because of the low memory limit) and it hangs. This is a known issue. [1] Increasing the memory limit to a more reasonable value (50 MB) solves the issue. [1] What you expected to happen: The Docker service shouldn't hang just because of the low memory limit imposed by a test. How to reproduce it (as minimally and precisely as possible): a Kubernetes deployment with Windows nodes (Windows Server 1803) the tests, or just spawn the following pod: the node status: the Windows node, check Docker's responsiveness by issuing a docker CLI command (`). Observe that the CLI will not receive any answer and it will hang. Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.1 Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): Windows nodes (Windows Server 1803) Kernel (e.g. ): N/A Install tools: N/A Others:
/sig windows
This was actually addressed by , but the PR message had the wrong Issue ID. The already merged, so this issue can be closed.

Discussion:
Resources: v1.ResourceRequirements{ Limits: v1.ResourceList{ v1.ResourceCPU:    *resource.NewMilliQuantity(100, resource.DecimalSI), <del> v1.ResourceMemory: *resource.NewQuantity(30*1024*1024, resource.DecimalSI), </del> <ins> v1.ResourceMemory: *resource.NewQuantity(50*1024*1024, resource.DecimalSI), </ins> }, }, },
Change:
[X] "goproxy" to "" [X] "jessie-dnsutils" to "" [X] "redis" to "" [X] "serve-hostname" to ""
/assign /assign
we can use to iterate
/sig testing
tip for uploading is here -
should be published to now. I'm rerunning for the other 3 images.
I think the and images were published successfully this time. :
can you please try ?
should now be published too thanks to PR.
related to

Discussion:
docker push ${REGISTRY}/${IMAGE}-${arch}:${TAG} done <ins> kube::util::ensure-gnu-sed </ins> # Make archs list into image manifest. Eg: 'amd64 ppc64le' to '${REGISTRY}/${IMAGE}-amd64:${TAG} ${REGISTRY}/${IMAGE}-ppc64le:${TAG}' manifest=$(echo $archs | ${SED} -e "s~[^ ]*~$REGISTRY/$IMAGE-&:$TAG~g") docker manifest create --amend ${REGISTRY}/${IMAGE}:${TAG} ${manifest}

CROSS_BUILD_COPY qemu-QEMUARCH-static /usr/bin/ <ins> # WARNING: Please note that the script below removes the security packages from arm64 and ppc64el images # as they do not exist anymore in the debian repositories for jessie. So we do not recommend using this # image for any production use and limit use of this image to just test scenarios. COPY fixup-apt-list.sh / RUN ["/fixup-apt-list.sh"] </ins> RUN apt-get -q update &&  apt-get install -y dnsutils &&  apt-get clean

<ins> #!/usr/bin/env bash # Copyright 2017 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. DEB_ARCH=$(dpkg --print-architecture) # http://security.debian.org/debian-security/dists/jessie/updates/InRelease is missing # entries for some platforms, so we just remove the last line in sources.list in # /etc/apt/sources.list which is "deb http://deb.debian.org/debian jessie-updates main" case ${DEB_ARCH} in arm64|ppc64el) sed -i '/debian-security/d' /etc/apt/sources.list ;; esac exit 0 </ins>
Change:
As of , all Kubernetes clusters with RBAC bootstrap roles for AWS, regardless of whether they are running on AWS. The hardcoded RBAC bootstrap policy should only include roles that are used by all clusters, regardless of addons, configuration, or cloud provider. The ClusterRole(Binding)s should be removed from the bootstrap policy, and instead configured by the provisioning tools. /sig aws /sig cloud-provider /sig auth
/assign I can help do it. :)

Discussion:
}, }, { <del> ObjectMeta: metav1.ObjectMeta{Name: "system:aws-cloud-provider"}, Rules: []rbacv1.PolicyRule{ rbacv1helpers.NewRule("get", "patch").Groups(legacyGroup).Resources("nodes").RuleOrDie(), eventsRule(), }, }, { </del> // a role making the csrapprover controller approve a node client CSR ObjectMeta: metav1.ObjectMeta{Name: "system:certificates.k8s.io:certificatesigningrequests:nodeclient"}, Rules: []rbacv1.PolicyRule{

rbacv1helpers.NewClusterBinding("system:kube-controller-manager").Users(user.KubeControllerManager).BindingOrDie(), rbacv1helpers.NewClusterBinding("system:kube-dns").SAs("kube-system", "kube-dns").BindingOrDie(), rbacv1helpers.NewClusterBinding("system:kube-scheduler").Users(user.KubeScheduler).BindingOrDie(), <del> rbacv1helpers.NewClusterBinding("system:aws-cloud-provider").SAs("kube-system", "aws-cloud-provider").BindingOrDie(), </del> rbacv1helpers.NewClusterBinding("system:volume-scheduler").Users(user.KubeScheduler).BindingOrDie(), // This default binding of the system:node role to the system:nodes group is deprecated in 1.7 with the availability of the Node authorizer.

creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults <del> name: system:aws-cloud-provider roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:aws-cloud-provider subjects: - kind: ServiceAccount name: aws-cloud-provider namespace: kube-system - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults </del> name: system:basic-user roleRef: apiGroup: rbac.authorization.k8s.io

creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults <del> name: system:aws-cloud-provider rules: - apiGroups: - "" resources: - nodes verbs: - get - patch - apiGroups: - "" resources: - events verbs: - create - patch - update - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" creationTimestamp: null labels: kubernetes.io/bootstrapping: rbac-defaults </del> name: system:basic-user rules: - apiGroups:
Change:
<!-- 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?: What happened: patched out the Size field (was PR ), it will cause issue again. See also and . What you expected to happen: PVC resizes of Cinder volumes successfully. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/kind bug /sig storage /sig openstack
/assign

Discussion:
ID:               volumeV3.ID, Name:             volumeV3.Name, Status:           volumeV3.Status, <ins> Size:             volumeV3.Size, </ins> } if len(volumeV3.Attachments) > 0 {
Change:
Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT What happened: TestNsenterExistsFile test is failing during make test What you expected to happen: The test should have passed. How to reproduce it (as minimally and precisely as possible): git clone run make test Anything else we need to know?: Fail logs: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others:
/sig storage
If you run the test with root user, It will fail. I have make a fix:
thanks for the patch .. its working.

Discussion:
import ( "io/ioutil" "os" <ins> "os/user" </ins> "path/filepath" "strings" "testing"

} func TestNsenterExistsFile(t *testing.T) { <ins> user, err := user.Current() if err != nil { t.Error(err) } isRoot := user.Username == "root" </ins> tests := []struct { name           string prepare        func(base, rootfs string) (string, error)

return path, nil }, <del> expectedOutput: false, expectError:    true, </del> <ins> expectedOutput: isRoot,  // ExistsPath success when running as root expectError:    !isRoot, // ExistsPath must fail when running as not-root </ins> }, { name: "relative symlink to existing file",
Change:
<!-- 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?: What happened: I visited the Kubernetes 1.11 release blog post and clicked on the link to the article on resizing persistent volumes. The server returned a 404. What you expected to happen: I expected to navigate to the article on resizing persistent volumes in Kubernetes. How to reproduce it (as minimally and precisely as possible): Visit the release announcement blog post (), scroll down to the "4 Day Features Blog Series" section, and click on the link to the article on resizing persistent volumes. Anything else we need to know?: The link currently points to: The correct link is: Environment: Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
Reiterating the mentions to trigger a notification: <detailsIn response to : <!-- This form is for bug reports and feature requests ONLY! --/kind bug /kind feature What happened: I visited the Kubernetes 1.11 release blog post and clicked on the link to the article on resizing persistent volumes. The server returned a 404. I expected to navigate to the article on resizing persistent volumes in Kubernetes. Visit the release announcement blog post (), scroll down to the "4 Day Features Blog Series" section, and click on the link to the article on resizing persistent volumes. The link currently points to: The correct link is: Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A 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
It should be reported to kubernetes/website, but doesn't matter.

Discussion:
echo -n Attempt "$(($attempt+1))" to check for SSH to master local output local ok=1 <del> output=$(ssh -oStrictHostKeyChecking=no -i "${AWS_SSH_KEY}" ubuntu@${KUBE_MASTER_IP} uptime 2> $LOG) || ok=0 </del> <ins> output=$(ssh -oStrictHostKeyChecking=no -i "${AWS_SSH_KEY}" ${SSH_USER}@${KUBE_MASTER_IP} uptime 2> $LOG) || ok=0 </ins> if [[ ${ok} == 0 ]]; then if (( attempt > 30 )); then echo

echo -n Attempt "$(($attempt+1))" to check for salt-master local output local ok=1 <del> output=$(ssh -oStrictHostKeyChecking=no -i "${AWS_SSH_KEY}" ubuntu@${KUBE_MASTER_IP} pgrep salt-master 2> $LOG) || ok=0 </del> <ins> output=$(ssh -oStrictHostKeyChecking=no -i "${AWS_SSH_KEY}" ${SSH_USER}@${KUBE_MASTER_IP} pgrep salt-master 2> $LOG) || ok=0 </ins> if [[ ${ok} == 0 ]]; then if (( attempt > 30 )); then echo