jiebi/CodeConvo huggingface dataset:
Change:
"//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/errors:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", </ins> "//staging/src/k8s.io/cli-runtime/pkg/genericclioptions:go_default_library", "//staging/src/k8s.io/cli-runtime/pkg/printers:go_default_library", "//staging/src/k8s.io/cli-runtime/pkg/resource:go_default_library",

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: When using kubectl auth can-i <verb<resourcesthe "verb" isn't check and returns yes on any resource regardless of what the verb is. What you expected to happen: I expected the cli to register an error like when you don't have enough arguments. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): client version GitVersion: 1.19.2 server version: GitVersion: 1.19.0 Cloud provider or hardware configuration: Mac OS X OS (e.g: ): n/a Kernel (e.g. ): Darwin Install tools: brew Network plugin and version (if this is a network-related bug): n/a 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 cli
This is working as intended. The authorization layer can answer questions about arbitrary verbs, and the response to can-i mirrors the response you would get from a subjectaccessreview permission check. Getting a "yes" response to arbitrary verbs likely means you are a superuser and would be authorized for any operation.
Wouldn't a superuser only have access to the Kubernetes verbs that exist and not the arbitrary verbs that it is allowed to query that is defined here () This seems to go against the selfsubjectaccessreview which will return a set of actions that a user can perform. Arbitrary verbs seem like they shouldn't be allowed from that definition.
No, the cluster-admin superuser role allows verbs which allows any verb
Change:
set -o nounset set -o pipefail <ins> echo "Note: This assumes that swagger spec has been updated. Please run hack/update-swagger-spec.sh to ensure that." </ins> KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "${KUBE_ROOT}/hack/lib/init.sh" kube::golang::setup_env

Discussion:
Ref: verify-swagger-spec is always passing on both travis and jenkins even when the swagger spec is not updated. It fails when run locally if the spec is not updated. Need to figure out why does it not fail on travis and jenkins.
It is failing now: https://travis- All I did was add some echo statements :)
Sent to fix this
Change:
container: .container-$(ARCH) .container-$(ARCH): bin/$(BIN)-$(ARCH) <del> docker build --pull -t $(IMAGE):$(TAG) --build-arg ARCH=$(ARCH) . ifeq ($(ARCH),amd64) docker rmi $(LEGACY_AMD64_IMAGE):$(TAG) 2>/dev/null || true docker tag $(IMAGE):$(TAG) $(LEGACY_AMD64_IMAGE):$(TAG) endif </del> <ins> docker build --pull -t $(IMAGE_WITH_ARCH):$(TAG) --build-arg ARCH=$(ARCH) . </ins> touch $@ push: .push-$(ARCH) .push-$(ARCH): .container-$(ARCH) <del> gcloud docker -- push $(IMAGE):$(TAG) touch $@ push-legacy: .push-legacy-$(ARCH) .push-legacy-$(ARCH): .container-$(ARCH) ifeq ($(ARCH),amd64) gcloud docker -- push $(LEGACY_AMD64_IMAGE):$(TAG) endif </del> <ins> gcloud docker -- push $(IMAGE_WITH_ARCH):$(TAG) </ins> touch $@ # Useful for testing, not automatically included in container image

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 feature This issue if for tracking the work related to pushing manifest list for kubernetes images(infra and test) List of images for which manifest need to be created: - [x] kubernetes to use manifest pause image - [x] dns - - - - - [ ] dashboard [x] Manifest images for k8s release images -
/assign
/cc
/sig cluster-lifecycle
/sig testing
/area test-infra /sig release
/reopen
I'd add dashboard to this as well, based off the issue at
can you provide a status update on this issue? I'd really want this fully working in v1.10... :)
I've created one more PR for pushing manifest for few more images, reference - I'll try my best to push into v1.10 release
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 /remove-lifecycle stale
/remove-lifecycle stale
/remove-lifecycle rotten
A problem related to manifests and was addressed here:
An update of this issue would be welcomed to track the status of all affected images, since I think at least some of the linked issues have progressed.
/sig testing
all the k8s core images are now fat manifest, hence closing this task. Will create a separate task for creating manifest for ecosystem images(e.g dashboard, metric-server etc...)
did you have a issue open tracking other images? I noticed today that kube-addon-manager (cluster/addons/addon-manager) is multi-arch but not using a manifest list yet.
Change:
// Start syncing node list from cloudprovider. if syncNodeList && nc.isRunningCloudProvider() { go util.Forever(func() { <del> if err = nc.SyncCloudNodes(); err != nil { </del> <ins> if err := nc.SyncCloudNodes(); err != nil { </ins> glog.Errorf("Error syncing cloud: %v", err) } }, period)

Discussion:
stack trace here: it's due to a shared variable:
Hi thanks for reporting the issue with a patch! Do you want to submit a PR so that you can take the credit for your fix? :)
done , Yu-Ju Hong wrote: 585.241.9488 (voice) 650.649.6071 (fax)
FYI, I think the same bug may still exist in your new PR.
There are multiple p
There are multiple PRs in flight, so I don't know which one you have in mind. One of them removes probing logic from controller altogether.
I was referring to , but I didn't read that PR closely so the bug may longer exist there. Again, just a FYI. :)
Change:
Help:    "Storage operation end to end duration in seconds", Buckets: []float64{.1, .25, .5, 1, 2.5, 5, 10, 15, 25, 50, 120, 300, 600}, }, <del> []string{"volume_plugin", "operation_name"}, </del> <ins> []string{"plugin_name", "operation_name"}, </ins> ) func init() {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-storage] [Serial] Volume metrics should create metrics for total time taken in volume operations in P/V Controller Since when has it been failing: 6/1 Testgrid link: https://k8s- Reason for failure: Probably caused by Anything else we need to know:
cc
cc
this is possibly caused by renaming one label of the metric from "pluginname" to "volumeplugin". Having a fix under testing now
/assign
GitHub didn't allow me to assign the following users: yuxiangqian. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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 opening this let us know if we can help! /priority important-soon /milestone v1.15 /cc
is working on a fix
apologies for the late reply. fix PR is in for review
Change:
# Vars set: #   AWS_IMAGE function detect-image () { <del> case "${KUBE_OS_DISTRIBUTION}" in </del> <ins> case "${OS_DISTRIBUTION}" in </ins> trusty|coreos) detect-trusty-image ;;

Discussion:
If e.g. coreos doesn't work with kube-up, we should point users to an installation method that works. Also consider offering hints like "vivid no longer gets security updates, consider using wily or official"
Change:
} } <del> err = m.cpuManager.Allocate(pod, &container) if err != nil { return lifecycle.PodAdmitResult{ Message: fmt.Sprintf("Allocate failed due to %v, which is unexpected", err), Reason:  "UnexpectedAdmissionError", Admit:   false, </del> <ins> if m.cpuManager != nil { err = m.cpuManager.Allocate(pod, &container) if err != nil { return lifecycle.PodAdmitResult{ Message: fmt.Sprintf("Allocate failed due to %v, which is unexpected", err), Reason:  "UnexpectedAdmissionError", Admit:   false, } </ins> } } }

Discussion:
Recently merged PR () broke clusters brought up with only GA APIs+features. See conformance test at /sig node /priority critical-urgent /kind bug /milestone v1.18 /assign
Change:
epSlice.Labels[discovery.LabelServiceName] = endpoints.Name epSlice.Labels[discovery.LabelManagedBy] = controllerName <del> // clone all annotations but EndpointsLastChangeTriggerTime </del> <ins> // clone all annotations but EndpointsLastChangeTriggerTime and LastAppliedConfigAnnotation </ins> for annotation, val := range endpoints.Annotations { <del> if annotation == corev1.EndpointsLastChangeTriggerTime { </del> <ins> if annotation == corev1.EndpointsLastChangeTriggerTime || annotation == corev1.LastAppliedConfigAnnotation { </ins> continue } epSlice.Annotations[annotation] = val

Discussion:
If I modify a custom endpoint, the kubectl annotation is mirrored to the generated endpoint slice Since the kubect last-applied-configuration tracks the status of the object, it shouldn't be mirrored since it doesn't apply to the generated object a custom endpoint an update on any of the fields the generated endpoint slice annotations /sig network
ping
if we agree this is a bug, the fix is just and adding some tests of course :)
Thanks for catching this! Agree this is a bug that we should fix.
/triage accepted
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue 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
Hey, I'm on it!
Hi While I have made the update mentioned in the above comment, I feel a bit lost on where to add/update tests. I understand that I probably shouldn't raise a PR without trying to add a few tests for this issue. So could you possibly guide me to the correct files(s) I should be looking into where the annotations for updated EndpointSlices are being tested?
Hey I think the easiest place to add tests might be here: You could add another test case where the Endpoints object had this label and then ensure that label was not copied over to an EndpointSlice.
Alright I'll check out these tests. Thank you!
/assign
Change:
// read the base directory tree searching for plugin descriptors // fails silently (descriptors unable to be read or unmarshalled are logged but skipped) err = filepath.Walk(base, func(path string, fileInfo os.FileInfo, walkErr error) error { <del> if fileInfo.IsDir() || fileInfo.Name() != PluginDescriptorFilename || walkErr != nil { </del> <ins> if walkErr != nil || fileInfo.IsDir() || fileInfo.Name() != PluginDescriptorFilename { </ins> return nil }

Discussion:
New kubectl plugin loader introduced by does not check before deref'ing . This occurs if the plugins directory does not exist or the user running doesn't have permission on the plugin directory.
Change:
} for _, testCase := range testCases { <del> actualContent := string(hostsFileContent(testCase.hostIP, testCase.hostName, testCase.hostDomainName, testCase.hostAliases)) assert.Equal(t, testCase.expectedContent, actualContent, "hosts file content not expected") </del> <ins> actualContent := managedHostsFileContent(testCase.hostIP, testCase.hostName, testCase.hostDomainName, testCase.hostAliases) assert.Equal(t, testCase.expectedContent, string(actualContent), "hosts file content not expected") </ins> } }

Discussion:
Currently, kubelet mounts hosts file for pods. For hostNetwork pods, the behavior is different and instead, kubelet relies on docker (or whatever container runtime) to mount the host's hosts file. We should have kubelet handle hosts file for hostNetwork pods. This would have several benefits: control over hosts file in case the container runtime does something consistent behavior between hostNetwork and non-hostNetwork pods consistent behavior between different container runtimes -managed hosts file enables features like to be used for hostNetwork pods Implementation would require: kubelet's or its caller output different content based on hostNetwork. i. If it's not hostNetwork, use existing behavior. ii. If it's using hostNetwork, read the content from the host's hosts file. hostNetwork constraint in deciding whether to mount the file Open Questions: do we treat changes to the host's hosts file? should the file's content be static between container restarts of the same Pod? or should every container restart pick up the latest content of the hosts file? the former seems better for consistency, but letter might be more in line with other features that use host resources like host volumes. condition to manage hosts file also excludes windows even though windows also the use of hosts file and the same format. seems like this should be supported also. windows-support ships, should it have validation against windows platform? the tricky bit is the client, API, and minions' kubelet may be running on different platforms, and currently, there's no precedence to platform validation. /kind feature /sig node
Change:
return secretName, err } <del> // check whether mountOptions contain file_mode and dir_mode, if not, append default mode func appendDefaultMountOptions(mountOptions []string) []string { </del> <ins> // check whether mountOptions contain file_mode, dir_mode, vers, gid, if not, append default mode func appendDefaultMountOptions(mountOptions []string, fsGroup *int64) []string { </ins> fileModeFlag := false dirModeFlag := false versFlag := false <ins> gidFlag := false </ins> for _, mountOption := range mountOptions { if strings.HasPrefix(mountOption, fileMode) {

Discussion:
If I look at the code of azureFile plugin, it has fsGroup as an argument, but don't see its usage anywhere I also don't see anywhere explicitely stated that azureFile volume supports fsGroup.
/sig storage
For those landing here, a separate path to get the mount point to have the right permissions is to add this annotation to the PV metadata: This makes the plugin mount the volume in the Pod under those UID,GID. Obviously, this implies that one knows what those are for their workload in the container ...
If i create a PV like this, still mounted with the default root used into POD. StorageClass PV
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale cc Let's check whether works for azure file.
/sig azure
is another way to set groupid(gid) While according to this , we also need to support Here is the code about setting fsgroup from securityContext. I will enable this feature and do a test, it should be 3 lines of code. /assign
BTW, this is all for Linux(UserID, GroupID), is there an identical setting for Windows container?
No, setting user for volumes doesn't work on Windows. Only the rw/ro options are implemented.
According to my investigation, though I put the following code in azure file , it does not take effect. The reason is azure file(cifs) mount does not support gid setting after file system mount, by default would be 0(root) So in summary, set fsGroup code in azure file is useless, user could set gid by mountOptions in storage class, here is an Let me know if you hav any concern about this issue Update: Root cause is azure file(cifs) mount does not support gid setting after file system mount, while azure disk supports.
is this true, that cifs does not support guid setting?
Of course cifs support gid setting, see example: I mean cifs does not support second time gid setting, kind of differnet than azure disk.

Anyway, I am working on a PR to support if no gid setting in azure file storage class, while if both sets, only gid from storage class would be used.
while the code is quite different than just add below 3 lines of code, actually below does not work: I will show you the PR tomorrow.
Change:
ctx, cancel := getContextWithCancel() defer cancel() <ins> // Invalidate the cache right after updating defer as.cloud.vmCache.Delete(vmName) </ins> _, err = as.VirtualMachinesClient.CreateOrUpdate(ctx, nodeResourceGroup, vmName, newVM) if err != nil { klog.Errorf("azureDisk - attach disk(%s) failed, err: %v", diskName, err)

Discussion:
What happened: Azure Disks get randomly mounted in a way that makes them unusable, returning for every disk I/O operation. Affected Pods remain in until someone manually recreates them. What you expected to happen: Azure Disks are consistently usable by Pods inside which they are mounted. How to reproduce it: Create the following StatefulSet. Adjust the replicas and delete the associated Pods () until the problem occurs (i.e. some Pod ends up in ). <details</summary</details</brDefault StorageClass (as created by ACS-Engine): <details</summary</details</brAnything else we need to know?: Nodes were updated from 1.10.4 to 1.10.10, then from 1.10.10 to without a reboot. According to written by the issue is fixed, but I can still observe it quite often. Ref Azure/acs-engine Environment: Kubernetes version: v1.10.10 + Cloud provider or hardware configuration: Azure (westeurope) OS: Ubuntu 16.04.4 LTS Kernel: 4.13.0-1018-azure Install tools: ACS-Engine Others: /kind bug /sig storage /sig azure
In my current test environment: (pod uid is -f23b-11e8-bf38-) on the node Notice the mismatch between the disk referenced by lun0 () and the actual mount (). on the node
After deleting the failing Pod and waiting for its successful recreation: (pod uid is now -f247-11e8-bf38-) on the node This time disks are matching (). on the node
/assign
Change:
// diskMounter provides the interface that is used to mount the actual block device. blockDeviceMounter mount.Interface plugin             *cinderPlugin <del> volume.MetricsNil </del> <ins> volume.MetricsProvider </ins> } func (b *cinderVolumeMounter) GetAttributes() volume.Attributes {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug What happened: I am trying to get metrics working. According this there should be support after 1.8 kube. However, I am now using kube 1.10.1 and still I cannot see anything in ? Should these be there or not? What you expected to happen: I except that kubelet should expose prometheus metrics to /metrics path as well. Then it is easy to read with prometheus. How to reproduce it (as minimally and precisely as possible): Create new cinder volume, attach it to pod and try to query result from in kubelet Environment: Kubernetes version (use ): 1.10.1 Cloud provider or hardware configuration: openstack OS (e.g. from /etc/os-release): centos 7 Kernel (e.g. ): Install tools: Others:
cc
/sig storage
Prometheus metrics should be available on default port of Kubelet. Can you try ? If you are on a RBAC enabled cluster (such as openshift) you may have to use token or key to authenticate for fetching metrics.
returns many metrics but there is not things. There is one pod which have cinder volume attached running in that node. So there should be some metrics right?
It appears that Cinder volume plugin does not implement metric interface necessary for getting those stat metrics - This seems like an oversight and is fairly easy to fix. I can help getting the PR merged if you can open it.
/sig openstack
Kubernetes v1.19.16 there is no kubelet_volume* metrics in //metrics how to fix it???
Change:
func NewPersistentVolumeControllerOptions() PersistentVolumeControllerOptions { return PersistentVolumeControllerOptions{ <del> PVClaimBinderSyncPeriod: 10 * time.Minute, </del> <ins> PVClaimBinderSyncPeriod: 15 * time.Second, </ins> VolumeConfigFlags: VolumeConfigFlags{ // default values here PersistentVolumeRecyclerMaximumRetry:             3,

Discussion:
Immediately after this test was reenabled in we got huge numbers of parallel flakes in . This might be a coincidence. I'll make a PR to move it to flaky. If things haven't improved after it's moved then I'll revert, else I'll assign this issue to !
Do you have any logs? references , but that has nothing to do with NFS nor PersistentVolumes.
. It's pretty clear this test caused the flakes we were seeing.
do you have any logs?
It hasn't flaked since your fix went in, but we should keep the issue open until it's moved out of the flaky suite.
The fix Joe Finney developed was merged on 5/30. The signature for the problem in the log file referenced here is: 6 18:56:07.895: Expected PersistentVolume to be bound, but got nil ClaimRef: kind:"" apiVersion:""` It looks like from this dashboard the last instance of this error log signature for the test PersistentVolumes NFS test to the flaky suite. was on 5/30 right around the time the code was merged. I found the off the dashboard at https://k8s- Since then the error has not occurred with that signature since I am tempted to close this bug, but keep the the test suite as marked "Flaky". The merge bot should start flagging the new bugs for this test going forward.
If it's no longer flaky we should move it out of the flaky suite. While it's in the flaky suite it won't block merges if it breaks and mergebot won't open bugs for it. I'm worried that if we just close this issue it'll sit in the flaky suite and break and noone will notice for a long time.
This bug has not been reproduced for past 2 months, can we close it?
It looks like the test is still in the flaky suite, although with a different name. Once it's moved out of there then this can be closed.
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention...
Not reproduced for three months, closing.

Consider reducing the PVClaimBinderSyncPeriod from 10 minutes down to something more reasonable, so that volumes don't sit around unbound for half an hour if it fails twice. This would reduce the impact of issues like until the binder/recycler/provosioner consolidation/refactor is complete. CC
+100
do you remember what was the reason for 10 minutes?
I checked provisioner and recycler, lowering the sync period should not harm them. Still, it will impact deleter a bit. Now we try to delete a volume three times every sync-period (10 minutes), mostly because if user deletes a pod that uses a volume and deletes also the PVC bound to it, the volume is still attached to the node for some time and all deletion attempts fail. I've seen AWS detach taking around 5 minutes in some cases. So, if we lower the timer, we should also increase the number of retries. Or have a different retry timer for deletion.