jiebi/CodeConvo huggingface dataset:
Change:
driver1 := &storagev1.CSIDriver{ ObjectMeta: metav1.ObjectMeta{ Name: "inline-driver-" + string(uuid.NewUUID()), <ins> Labels: map[string]string{ "test": f.UniqueName, }, </ins> }, Spec: storagev1.CSIDriverSpec{

Discussion:
https://k8s- CSIInlineVolumes should support ephemeral VolumeLifecycleMode in CSIDriver API 8/5 https://k8s- No response /sig storage
/triage accepted
/assign
Change:
"k8s.io/kubernetes/test/e2e/framework/metrics" "k8s.io/kubernetes/test/e2e/manifest" testutils "k8s.io/kubernetes/test/utils" <ins> // ensure auth plugins are loaded _ "k8s.io/client-go/plugin/pkg/client/auth" </ins> ) var (

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: E2E keeps failing with internal Ginkgo failure of "Node 1 disappeared before completing BeforeSuite" on my PR. https://k8s- What you expected to happen: Not that. How to reproduce it (as minimally and precisely as possible): Run /retest on my PR. It's happened 5 times in a row. Anything else we need to know?: I am almost certain my change does not affect that test suite in any way.
cc
Worked on https://k8s- this morning: https://k8s-
Does this repo on an empty changelist?
Looks like it repos on ci: https://k8s-
Talked with gke dev oncall... internal dashboards look fine, doesn't seem like a gke issue.
Most interesting thing on is maybe the prow bump?
I'm seeing this too on my PR
Trying on a clean PR:
Did something bad happen between versions 342 and 346 on 1.11.0-alpha.2? CI fails to start starts: PR:
Maybe this has something to do with
I'm not sure. That was adding permissions back to nodes so they can delete themselves. It had broken downgrades, so it was reverted. It fixed this: https://k8s-
Testing the theory in
looks like no
https://k8s- so absolutely nothing changed on the test-infra side between the last pass at 9:10 and first failure at 9:55 (prow updated before 9a, same kubetest image, test-infra commit) Seems to be failing here : https://k8s- compared to passing run https://k8s- /unassign /assign
The client go auth plugins are by import. kubectl imports the gcp provider explicitly, but the e2e test apparently doesn't. is in the range when the e2e test started failing, and the description of that PR indicates it trimmed lots of dependencies. I'd look at whether the e2e test had only imported that auth plugin indirectly via one of those removed dependencies in that PR. If the e2e test requires that auth plugin, it should import it like kubectl and the kubeapiserver does:
Are you saying the e2e suite imports kubeadm code?

On Fri, May 11, 2018, 19:57 Jordan Liggitt <:
e2e imports kubeadm util: which imports preflight: which imported kubeapiserveroptions prior to : which imported: which imported the apiserver authenticator: which imported the auth plugins:
potential fix in
Thanks Great bug :^)
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" unversionedvalidation "k8s.io/apimachinery/pkg/apis/meta/v1/validation" "k8s.io/apimachinery/pkg/labels" <ins> apimachineryvalidation "k8s.io/apimachinery/pkg/util/validation" </ins> "k8s.io/apimachinery/pkg/util/validation/field" "k8s.io/kubernetes/pkg/api" apivalidation "k8s.io/kubernetes/pkg/api/validation"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: We have some cron jobs with longish names (~60 characters), and noticed that the corresponding jobs weren't being created by the cronjob controller because the name was too long. Here's what happened: There's a 63-character limit on job names (because for some reason on job creation the name gets copied into a label, where the limit is 63 chars). For example, if I try to create a job with a long name, I get the error message: By itself, this is fine. I can just make a job with a shorter name. However! If I create a cron job, the cron job controller will create jobs named . So the job's name is 11 characters longer than the job name. This means that if I create a cron job with a 63-character name, it'll result in a job name that's 74 characters, which the API will refuse to accept. This means the cron job never gets scheduled. Some possible resolutions: validation on cron job creation that refuses to let you create jobs with names 52 characters the cron job controller truncate cronjobs names remove the 63-character limit on job names (this seems difficult) There's actually a deeper problem here at play: Kubernetes' resource name limit is 253 characters. But the limit for resouce labels is 63 characters. So when a job is created, the name (which is allowed to be up to 255 chars) gets copied into a label, which has a lower limit. So the job creation fails. (these are the ) What you expected to happen: When I create a cron job, I expect it to either to create the cron job, or jobs correctly from that cron job How to reproduce it (as minimally and precisely as possible): a cronjob with a name that's more than 52 characters that it does not schedule jobs, with an error message like Anything else we need to know?: Kubernetes version: 1.7.3 Cloud provider: AWS OS: Ubuntu 16.04 Kernel: 4.4.0 example of a job definition with a long name This job definition is invalid:
There are no sig labels on this issue.

Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig apps
cc
Change:
} func (mounter *Mounter) Mount(source string, target string, fstype string, options []string) error { <del> return nil </del> <ins> return unsupportedErr </ins> } func (mounter *Mounter) Unmount(target string) error { <del> return nil </del> <ins> return unsupportedErr </ins> } // GetMountRefs finds all other references to the device referenced // by mountPath; returns a list of paths. func GetMountRefs(mounter Interface, mountPath string) ([]string, error) { <del> return []string{}, nil </del> <ins> return []string{}, unsupportedErr </ins> } func (mounter *Mounter) List() ([]MountPoint, error) { <del> return []MountPoint{}, nil </del> <ins> return []MountPoint{}, unsupportedErr </ins> } func (mounter *Mounter) IsMountPointMatch(mp MountPoint, dir string) bool {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Calls to on unsupported platforms do not report any error and potentially misbehave. What you expected to happen: I would expect an error to be reported, that can be consumed by the caller. How to reproduce it (as minimally and precisely as possible): for and were failing on darwin, and no error was being reported. See: & Environment: OS (e.g. from /etc/os-release): I have been testing on osx/darwin, which is not a supported platform.
/sig storage
/assign
Change:
PREEMPTIBLE_NODE=${PREEMPTIBLE_NODE:-false} PREEMPTIBLE_MASTER=${PREEMPTIBLE_MASTER:-false} <ins> # TODO(#26183): Provide a way to differentiate master OS distro and node OS # distro. </ins> OS_DISTRIBUTION=${KUBE_OS_DISTRIBUTION:-gci} <del> # For GCI, leaving it blank will auto-select the latest GCI image on the `dev` # channel. </del> <ins> # By default a cluster will be started with the master on GCI and nodes on # containervm. If you are updating the containervm version, update this # variable. CVM_VERSION=container-v1-3-v20160517 </ins> MASTER_IMAGE=${KUBE_GCE_MASTER_IMAGE:-} MASTER_IMAGE_PROJECT=${KUBE_GCE_MASTER_PROJECT:-google-containers} <del> NODE_IMAGE=${KUBE_GCE_NODE_IMAGE:-container-v1-3-v20160517} NODE_IMAGE_PROJECT=${KUBE_GCE_NODE_PROJECT:-google-containers} </del> <ins> NODE_IMAGE=${KUBE_GCE_NODE_IMAGE:-"${MASTER_IMAGE}"} NODE_IMAGE_PROJECT=${KUBE_GCE_NODE_PROJECT:-"${MASTER_IMAGE_PROJECT}"} </ins> CONTAINER_RUNTIME=${KUBE_CONTAINER_RUNTIME:-docker} RKT_VERSION=${KUBE_RKT_VERSION:-0.5.5}

Discussion:
As of (specifically ), running against GCE without setting a node image defaults it to containervm, whereas before it defaulted it to the master image. For example, my config of: brings up a coreos master and then launches nodes with images. Before the above-referenced change this gave me my expected coreos nodes. Was this change intentional? The easiest fix that comes to mind for me is only doing the new containervm defaulting if is gci. cc
Yeah, this was something I was concerned too while making the change. However, the decision seems to have been that we decided to default to GCI, yet still default to the debian based containervm. Also, if we are to seriously start supporting hybrid clusters, i.e., master and nodes run on different OS distros, which seems true according to , this old assumption of defaults to needs to disappear anyways. cc/ Thoughts?
That sounds reasonable to me. We clearly didn't think about your use case whilst making this change.
I don't see the issue with defaulting to non-hybrid while supporting hybrid.. Defaulting seems totally reasonable even in a world where hybrid support is possible. A user could explicitly control that they want hybrid via setting them to different values regardless of the defaulting, or wherever hybrid is toggled on different defaulting could be done. I left a few questions on the referenced original issue which, if/when answered, might help me in making a PR to fix this for my usecase more cleanly.
Agreed. I am making a fix to this.
Change:
}, }, } <del> glog.V(2).Infof("azureDisk - update(%s): vm(%s) - detach disk", nodeResourceGroup, vmName) </del> <ins> glog.V(2).Infof("azureDisk - update(%s): vm(%s) - detach disk(%s)", nodeResourceGroup, vmName, diskName) </ins> ctx, cancel := getContextWithCancel() defer cancel() <del> resp, err := as.VirtualMachinesClient.CreateOrUpdate(ctx, nodeResourceGroup, vmName, newVM) if as.CloudProviderBackoff && shouldRetryHTTPRequest(resp, err) { glog.V(2).Infof("azureDisk - update(%s) backing off: vm(%s)", nodeResourceGroup, vmName) retryErr := as.CreateOrUpdateVMWithRetry(nodeResourceGroup, vmName, newVM) if retryErr != nil { err = retryErr glog.V(2).Infof("azureDisk - update(%s) abort backoff: vm(%s)", nodeResourceGroup, vmName) } } if err != nil { glog.Errorf("azureDisk - azure disk detach failed, err: %v", err) </del> <ins> if _, err := as.VirtualMachinesClient.CreateOrUpdate(ctx, nodeResourceGroup, vmName, newVM); err != nil { glog.Errorf("azureDisk - detach disk(%s) failed, err: %v", diskName, err) </ins> } else { <del> glog.V(4).Info("azureDisk - azure disk detach succeeded") </del> <ins> glog.V(2).Infof("azureDisk - detach disk(%s) succeeded", diskName) </ins> // Invalidate the cache right after updating as.cloud.vmCache.Delete(vmName) }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: retry azure disk attach operation produce too many API calls Not the default value is 6 which means if AttachDisk operation failed, it will retry 6 more times, when disk quota is full on a VM, it produces too many API calls. Retry attach disk behavior is not necessary since it AttachVolume operation fails, k8s attachdetach-controller will retry once a minute until it succeeds. default setting in What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.10, v1.11, v1.12 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug /sig azure /assign
Change:
gomega.Eventually(func() error { return checkMirrorPodDisappear(f.ClientSet, mirrorPodName, ns) }, time.Minute, time.Second*2).Should(gomega.BeNil()) }) }) })

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: Several tests Eg. this run: Since when has it been failing: Unknown Testgrid link: Reason for failure: (happens to all the images). Pods in the e2e test suites use pull policy , , and it looks like the test during DiskPressure, resulting in kubelet removing some of the pre pulled images. Anything else we need to know: The runs after each test. This should also be the case in the test too.
/assign /sig node
These tests are now constantly failing due to missing images. This makes it hard to see if some of the stuff we do now, or have done in the last few weeks, breaks some of the tests. PR should hopefully fix this, but it is not in the 1.16 milestone, but has and . Should we get this merged into master so that we can see if if fixes the problem, or should we wait until code thaw? Any thoughts? /cc /cc /cc
/priority important-longterm
Thanks for all the work you've put into this ! I think we should add to the milestone
+1 to - thanks for your hard work :)
still has a lot of failing tests. What are the next steps? /reopen
Reopened this issue. <detailsIn response to : still has a lot of failing tests. What are the next steps? 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
Yes, it has over the few last weeks become quite a mess... Looks like fixed some of the issues about image eviction problems, but there are still a few left. I think I have a solution, so ill try to submit a ~PR in a few hours~ edit: will do it tomorrow. A lot of new tests started failing 8-28, and that may be related to , but I am not totally sure..
Looks like fixed the flaking in ! The last 7 runs was executed after that was merged! ! We still have a lot of failing tests, but those are not flaky; they are failing (ref. comment above).

Ill create a new issue about all the failing tests where we can track them each together. Closing this issue, as this was only filed for the flaking becuase of the evicted images. :smile: /close cc
Closing this issue. <detailsIn response to : Looks like fixed the flaking in ! The last 7 runs was executed after that was merged! We still have a lot of failing tests, but those are not flaky; they are failing (ref. comment above). cc 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:
NonMergingList    []MergeItem MergingIntList    []int `patchStrategy:"merge"` NonMergingIntList []int <ins> MergeItemPtr      *MergeItem `patchStrategy:"merge" patchMergeKey:"name"` </ins> SimpleMap         map[string]string }

Discussion:
PATCH http://IP:8080/api/v1beta3/namespaces/dev--ea6f-49cb-b5bb-/replicationcontrollers/redis-master {"spec":{"replicas":0}} answer: { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "the server responded with the status code 415 but did not return more information", "details": {}, "code": 415 } Before v0.15.0 it had worked well.
That error is returned by go-restful because it did not find any valid route with the same content type as specified in the request: Can you try setting the content-type in your request as is described here: cc
well, I've the same issue which is not fixed by setting the value, at least with the "strategic merge patch". Here's the request: Here's the response body: And here's the log trace of the request in the apiserver pod:
Come from a typo, purposed PR here:
Btw, I'm still having strange issues with sub-objects. Note that it appears only is the sub-object is already set. Here's the request: Here's the API log:
Looks like a bug in strategic merge -- it doesn't deal with pointers correctly:
cc
is it possible to have a milestone for this so I can tell if I should merger ? Thanks.
Change:
federation_api "k8s.io/kubernetes/federation/apis/federation/v1beta1" fake_federation_release_1_4 "k8s.io/kubernetes/federation/client/clientset_generated/federation_release_1_4/fake" . "k8s.io/kubernetes/federation/pkg/federation-controller/util/test" <ins> "k8s.io/kubernetes/pkg/api/unversioned" </ins> api_v1 "k8s.io/kubernetes/pkg/api/v1" <ins> extensionsv1 "k8s.io/kubernetes/pkg/apis/extensions/v1beta1" </ins> kube_release_1_4 "k8s.io/kubernetes/pkg/client/clientset_generated/release_1_4" fake_kube_release_1_4 "k8s.io/kubernetes/pkg/client/clientset_generated/release_1_4/fake" <ins> "k8s.io/kubernetes/pkg/client/testing/core" </ins> "k8s.io/kubernetes/pkg/runtime" "github.com/stretchr/testify/assert"

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:
PROVIDER_VARS="${PROVIDER_VARS:-} ENABLE_IP_ALIASES" fi <ins> # Enable GCE Alpha features. if [[ -n "${GCE_ALPHA_FEATURES:-}" ]]; then PROVIDER_VARS="${PROVIDER_VARS:-} GCE_ALPHA_FEATURES" fi </ins> # Admission Controllers to invoke prior to persisting objects in cluster # If we included ResourceQuota, we should keep it at the end of the list to prevent incrementing quota usage prematurely. ADMISSION_CONTROL=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,Priority,ResourceQuota

Discussion:
The environment variable GCEALPHAFEATURES is not set correctly in the test custer.
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/network: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
Change:
return devicePath, err } <del> func (util *FCUtil) DetachDisk(c fcDiskUnmounter, mntPath string) error { if err := c.mounter.Unmount(mntPath); err != nil { return fmt.Errorf("fc detach disk: failed to unmount: %snError: %v", mntPath, err) </del> <ins> func (util *FCUtil) DetachDisk(c fcDiskUnmounter, devName string) error { // Remove scsi device from the node. if !strings.HasPrefix(devName, "/dev/") { return fmt.Errorf("fc detach disk: invalid device name: %s", devName) </ins> } <ins> arr := strings.Split(devName, "/") dev := arr[len(arr)-1] removeFromScsiSubsystem(dev, c.io) </ins> return nil }

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?: /kind bug What happened: When user uses fc volume plugin, device file on operating system such as /dev/sdX remains after deleting a Pod. After deleting the Pod, PVC and PV, cluster admin or external-provisioner might delete the disk from the storage, therefore the block device on the worker node should be cleaned up. The photon volume plugin already has this functionality in the removeFromScsiSubsystem(). Also the gce volume plugin has similar functionality in the udevadmChangeToDrive() too. photon: echo 1 /sys/block/<dev name/device/delete gce: udevadm trigger --action=change --property-match=DEVNAME=%s Also os-brick library in the OpenStack Cinder component uses same way with photon driver. What you expected to happen: The device file on operating system such as /dev/sdX will be cleaned up after deleting PVs. Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: KVM OS (e.g. from /etc/os-release): Fedora 25 Kernel (e.g. ):Install tools: local-up- Others:
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig storage
I'll work on this.
Reiterating the mentions to trigger a notification: <detailsIn response to : I'll work on 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
Change:
} wg.Wait() } <del> // getPhase returns the phase of a pod given its container info. // TODO(dchen1107): push this all the way down into kubelet. func getPhase(spec *api.PodSpec, info api.PodInfo) api.PodPhase { if info == nil { return api.PodPending } running := 0 waiting := 0 stopped := 0 failed := 0 succeeded := 0 unknown := 0 for _, container := range spec.Containers { if containerStatus, ok := info[container.Name]; ok { if containerStatus.State.Running != nil { running++ } else if containerStatus.State.Termination != nil { stopped++ if containerStatus.State.Termination.ExitCode == 0 { succeeded++ } else { failed++ } } else if containerStatus.State.Waiting != nil { waiting++ } else { unknown++ } } else { unknown++ } } switch { case waiting > 0: // One or more containers has not been started return api.PodPending case running > 0 && unknown == 0: // All containers have been started, and at least // one container is running return api.PodRunning case running == 0 && stopped > 0 && unknown == 0: // All containers are terminated if spec.RestartPolicy.Always != nil { // All containers are in the process of restarting return api.PodRunning } if stopped == succeeded { // RestartPolicy is not Always, and all // containers are terminated in success return api.PodSucceeded } if spec.RestartPolicy.Never != nil { // RestartPolicy is Never, and all containers are // terminated with at least one in failure return api.PodFailed } // RestartPolicy is OnFailure, and at least one in failure // and in the process of restarting return api.PodRunning default: return api.PodPending } } </del>

Discussion:
Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.
Change:
if err != nil { return err } <ins> if m.inhibitLock != 0 { m.dbusCon.ReleaseInhibitLock(m.inhibitLock) } </ins> m.inhibitLock = lock return nil }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: ! What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.20.1 Cloud provider or hardware configuration: OS (e.g: ): 7 Kernel (e.g. ): Linux zsm-test-2 3.10.0-1160.11.1.el7.x8664 SMP Fri Dec 18 16:34:56 UTC 2020 x8664 x8664 x8664 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others:
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