jiebi/CodeConvo huggingface dataset:
Change:
if strings.HasPrefix(mountOption, vers) { versFlag = true } <ins> if strings.HasPrefix(mountOption, gid) { gidFlag = true } </ins> } allMountOptions := mountOptions

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:
// Fix liveness probe By("Rewriting the file") <del> out, err = framework.RunKubectl("exec", fmt.Sprintf("--namespace=%s", pod.Namespace), pod.Name, "--container", pod.Spec.Containers[0].Name, "--", "/bin/sh", "-c", fmt.Sprintf("echo test-after > %v", volumeMount)) framework.Logf("Pod exec output: %v", out) </del> <ins> stdout, _, err = f.ExecShellInPodWithFullOutput(pod.Name, fmt.Sprintf("echo test-after > %v", volumeMount)) framework.Logf("Pod exec output: %v", stdout) </ins> Expect(err).ToNot(HaveOccurred(), "while rewriting the probe file") // Wait for container restarts to stabilize

Discussion:
Which jobs are failing: Tests which exec into containers and alter lifecycles Which test(s) are failing: All new tests introduced for api change which exec into containers New alpha subpathExpr tests [Feature:VolumeSubpathEnvExpansion][NodeAlphaFeature:VolumeSubpathEnvExpansion] Since when has it been failing: 27/February/2019 Testgrid link: https://k8s- Reason for failure: is only set in e2e tests and the binary is not available in node e2e tests Need to restructure and call the API rather than through the framework convenience function Anything else we need to know:
/sig node /sig storage /assign /cc
Change:
"cluster-signing-key-file":         filepath.Join(cfg.CertificatesDir, kubeadmconstants.CAKeyName), "use-service-account-credentials":  "true", "controllers":                      "*,bootstrapsigner,tokencleaner", <del> "authentication-kubeconfig":        filepath.Join(kubeadmconstants.KubernetesDir, kubeadmconstants.ControllerManagerKubeConfigFileName), "authorization-kubeconfig":         filepath.Join(kubeadmconstants.KubernetesDir, kubeadmconstants.ControllerManagerKubeConfigFileName), "client-ca-file":                   filepath.Join(cfg.CertificatesDir, kubeadmconstants.CACertName), "requestheader-client-ca-file":     filepath.Join(cfg.CertificatesDir, kubeadmconstants.FrontProxyCACertName), </del> <ins> } //add the extra arguments for v1.12+ if k8sVersion.Major() >= 1 && k8sVersion.Minor() >= 12 { defaultArguments["authentication-kubeconfig"] = filepath.Join(kubeadmconstants.KubernetesDir, kubeadmconstants.ControllerManagerKubeConfigFileName) defaultArguments["authorization-kubeconfig"] = filepath.Join(kubeadmconstants.KubernetesDir, kubeadmconstants.ControllerManagerKubeConfigFileName) defaultArguments["client-ca-file"] = filepath.Join(cfg.CertificatesDir, kubeadmconstants.CACertName) defaultArguments["requestheader-client-ca-file"] = filepath.Join(cfg.CertificatesDir, kubeadmconstants.FrontProxyCACertName) </ins> } // If using external CA, pass empty string to controller manager instead of ca.key/ca.crt path,

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When I use kubeadm to create an old version k8s cluster, the controller manager pod can not work well. The command like this : "kubeadm init --kubernetes-version=v1.11.2" The error of kube controller manager pod like this : What you expected to happen: The controller manager pod can work well. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.12.0 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): Install tools: kubeadm Others:
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
/remove-sig contributor-experience /area kubeadm
Please, use when filing kubeadm issues. /sig cluster-lifecycle
OK, thank you for reminding me.
Change:
function usage() { echo "!!! EXPERIMENTAL !!!" <ins> echo "!!! This upgrade script is not meant to be run in production !!!" </ins> echo "" echo "${0} [-M | -N | -P] [-o] (-l | <version number or publication>)" echo "  Upgrades master and nodes by default"

Discussion:
Which jobs are failing: Multiple jobs on . Which test(s) are failing: on the following jobs: Since when has it been failing: Since 5/17. Testgrid links: See above. Reason for failure: All the failures mentioned above seem to have to have the same root cause, namely failure while waiting for CoreDNS to be ready. Example: /sig testing /priority critical-urgent /kind failing test /milestone v1.15 /cc
Some of this (possible all of it) is due to , which is dependent on being merged.
/sig cluster-lifecycle
Not the gce jobs thoght. Only the kinder job. So the gce jobs are failing with a problem outside of kubeadm/kinder but possibly still related to the corefile plugin change
/assign (At kubecon this week)
The gce failures appear to show the same behavior, but with kube-up instead of kubeadm. I.e. it appears that kube-up may also be retaining old configs when upgrading/downgrading. If thats true, then we may need to integrate the migration tools into kube-up as well.
I have opened which aims to fix all the failing tests except , which will be fixed via
Great job so far and Would it be possible to ask for the open PRs to be merged and/or a solution found soon? We have these tests failing for quite some time and code freeze coming up in the next days. Thank you in advance for your efforts!
thanks for the heads up. let me know if you don't have the time for the refactor that i requested and i can try to take over there. the alternative is to rollback the coredns version which i assume is not ideal, due to a variety of fixes in the new version.
is there any more work planned for this issue? I see that some of the kinder jobs are still failing after merged:
merging and will resolve and close this issue.
Thank you for the update !
updates: kinder tests were fixed via
/unassign i was here for: it's a bit flaky (which is due to the tooling), but green.
Since and we're moved to 1.16, and we're waiting for to merge, can we move this issue to 1.16?
? is that the right PR?

Good catch, I meant
The GCE test failures were fixed by and /close
Closing this issue. <detailsIn response to : The GCE test failures were fixed by and /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
UID:       types.UID(fmt.Sprintf("test-puid%v", i)), }, Spec: v1.PodSpec{ <del> NodeName: fmt.Sprintf("test-node%v", i), </del> <ins> NodeName: fmt.Sprintf("test-node%v", i%10), </ins> }, } pods = append(pods, pod)

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: If we delete node first, then remove pods on this node, the scheduler will crash in function What you expected to happen: Not crashed How to reproduce it (as minimally and precisely as possible): some pods on node A delete node A delete pods on node A Anything else we need to know?: Environment: Kubernetes version (use ): 1.16-1.18, even master Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig scheduling
can you show the core dump please of this crash?
/assign
I patched the unit test shown in into the , and branches. None crashed. I'll await for the crash dump.
Here is the fresh dump.
and which version was this?
This is master branch. And I've tested it from 1.16-1.18, it can be reproduced easily.
Thanks a lot. I was able to finally reproduce in unit tests. The scenario is: a node with at least 2 pods. node. pod1. In unit test, this is first an update to set the termination timestamp. No issues up to this point. pod2. Again, first an update to set the termination timestamp. Here it crashes. I'm working on a fix.
It looks like this is not an issue in 1.17 and below, because we preserved a placeholder node where the operations occur. do you have stacktraces for 1.17 and 1.16?
Yes, it seems only be found at 1.18. :smile:
Change:
f := framework.NewDefaultFramework("multi-az") var zoneCount int var err error <del> image := framework.ServeHostnameImage </del> ginkgo.BeforeEach(func() { e2eskipper.SkipUnlessProviderIs("gce", "gke", "aws") if zoneCount <= 0 {

Discussion:
It's not being used. Alternatively, pass the right image name to start with. /assign /sig scheduling /sig testing
/kind cleanup
Change:
<ins> // +build !linux /* 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. */ package mount import ( "errors" ) type execMounter struct{} // ExecMounter is a mounter that uses provided Exec interface to mount and // unmount a filesystem. For all other calls it uses a wrapped mounter. func NewExecMounter(exec Exec, wrapped Interface) Interface { return &execMounter{} } func (mounter *execMounter) Mount(source string, target string, fstype string, options []string) error { return nil } func (mounter *execMounter) Unmount(target string) error { return nil } func (mounter *execMounter) List() ([]MountPoint, error) { return []MountPoint{}, nil } func (mounter *execMounter) IsMountPointMatch(mp MountPoint, dir string) bool { return (mp.Path == dir) } func (mounter *execMounter) IsNotMountPoint(dir string) (bool, error) { return IsNotMountPoint(mounter, dir) } func (mounter *execMounter) IsLikelyNotMountPoint(file string) (bool, error) { return true, nil } func (mounter *execMounter) GetDeviceNameFromMount(mountPath, pluginDir string) (string, error) { return "", nil } func (mounter *execMounter) DeviceOpened(pathname string) (bool, error) { return false, nil } func (mounter *execMounter) PathIsDevice(pathname string) (bool, error) { return true, nil } func (mounter *execMounter) MakeRShared(path string) error { return nil } func (mounter *execMounter) GetFileType(pathname string) (FileType, error) { return FileType("fake"), errors.New("not implemented") } func (mounter *execMounter) MakeDir(pathname string) error { return nil } func (mounter *execMounter) MakeFile(pathname string) error { return nil } func (mounter *execMounter) ExistsPath(pathname string) bool { return true } </ins>

Discussion:
/kind bug What happened: pull-kubernetes-cross complains: https://k8s-
/sig storage
For reference, root cause
Change:
"admissionregistration.k8s.io/v1/mutatingwebhookconfigurations":    "Sqi0GUgDaX0=", "admissionregistration.k8s.io/v1/validatingwebhookconfigurations":  "B0wHjQmsGNk=", "events.k8s.io/v1/events":                                          "r2yiGXH7wu8=", <del> "flowcontrol.apiserver.k8s.io/v1beta3/flowschemas":                 "G+8IkrqFuJw=", "flowcontrol.apiserver.k8s.io/v1beta3/prioritylevelconfigurations": "wltM4WMeeXs=", "flowcontrol.apiserver.k8s.io/v1beta2/flowschemas":                 "G+8IkrqFuJw=", "flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations": "wltM4WMeeXs=", </del> <ins> "flowcontrol.apiserver.k8s.io/v1beta3/flowschemas":                 "9NnFrw7ZEmA=", "flowcontrol.apiserver.k8s.io/v1beta3/prioritylevelconfigurations": "+CwSrEWTDhc=", "flowcontrol.apiserver.k8s.io/v1beta2/flowschemas":                 "9NnFrw7ZEmA=", "flowcontrol.apiserver.k8s.io/v1beta2/prioritylevelconfigurations": "+CwSrEWTDhc=", </ins> }

Discussion:
adds new version for in 1.26. For 1.26, we are setting the storage version to because vN-1 understands that level. In 1.27, we should change the storage version from to .
/sig api-machinery
/cc
/cc
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Change:
t.Fatal(err) } <del> if e, a := "/apis/mygroup.example.com/v1beta1/foo", createdCurletInstance.GetSelfLink(); e != a { </del> <ins> if e, a := "/apis/mygroup.example.com/v1beta1/curlets/foo", createdCurletInstance.GetSelfLink(); e != a { </ins> t.Errorf("expected %v, got %v", e, a) } }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: I created a custom resource definition with -this is important - scope "Cluster". Then I created an element of that kind. Then I fetched the element and saw that the "metadata.selfLink" attribute had an incorrect value. The path did not contain the custom resource name. Trying to fetch the element using API results in 404 response. What you expected to happen: The "metadata.selfLink" of an instance of a custom resource should be correct. How to reproduce it (as minimally and precisely as possible): Prepare a custom resource definition with scope: Cluster (important! with scope Namespaced the selfLink is correct) in a file (slightly modified standard example from here: ) Create it: Now prepare a custom object in a file my- with this content: And create it: Now get the custom object list: The result is: As you can see the selfLink is . This is wrong, it should be . Using the selfLink as it is causes 404 when fetching the resource via API. Anything else we need to know?: This only happens when the custom resource definition has scope: Cluster. Environment: Kubernetes version (use ): v1.9.2 Cloud provider or hardware configuration: 2017 Macbook Pro OS (e.g. from /etc/os-release): macOS High Sierra 10.13.3 Kernel (e.g. ): Darwin Kernel Version 17.4.0 Install tools: minikube 0.24.1
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
Reiterating the mentions to trigger a notification: <detailsIn response to : </details
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
/assign
Created the PR:
/cc
Change:
running++ } else if containerStatus.State.Termination != nil { stopped++ <ins> if containerStatus.State.Termination.ExitCode == 0 { succeeded++ } else { failed++ } } else if containerStatus.State.Waiting != nil { waiting++ </ins> } else { unknown++ }

Discussion:
I'm actually not sure if it's by design. But certainly replication controller doesn't behave like it expects this.
If restart policy is to restart always, they should be restarted, but in that case they shouldn't be reported as failed.
This is a known issue, and by design based on upper-level will observe the status reported from kubelet, but not check with RestartPolicy and generate PodCondition / PodStatus. When RestartPolicy is Always, even Kubelet reports all containers are at failed state, apiserver shouldn't mark Pod as failed state. This is why initially I want kubelet report Pod state / status / condiction.
As a quick fix, we could let apiserver populate the right state / status based on containerStatus and RestartPolicy for now. In a long term, I still think we should make kubelet smarter and atomic and self-contained component, not just a wrapper around docker.
Short term fix should be P1 then we can de-prio for a "realer" fix.
Yes, I am working on the short term fix, and should have it included in 0.6 cut.
are you still working on this?
Yes, I am working on this. Should finish it today.
Change:
// waitForEvents waits for adds, updates, and deletes to be populated with at least one event. func (is *informerSpy) waitForEvents(t *testing.T, wantEvents bool) { t.Helper() <ins> // wait for create/update/delete 3 events for 30 seconds waitTimeout := time.Second * 30 if !wantEvents { // wait just 15 seconds for no events waitTimeout = time.Second * 15 } </ins> <del> err := wait.PollImmediate(time.Second, time.Second*30, func() (bool, error) { </del> <ins> err := wait.PollImmediate(time.Second, waitTimeout, func() (bool, error) { </ins> is.mu.Lock() defer is.mu.Unlock() return len(is.adds) > 0 && len(is.updates) > 0 && len(is.deletes) > 0, nil

Discussion:
wanted sync true, got sync false wanted sync true, got sync false wanted sync true, got sync false informer never changed resource versions from "": timed out waiting for the condition /kind failing-test /kind flake as it is in /sig auth Open it as it is the top flake of pull-kubernetes-integration:
Commented on PR.
/triage accepted
I've seen this test fail 2 times today on my PR Going to hope that I close my eyes and and never see it if it happens again I'll reopen this...
!
Opened to track flakes once again
Change:
"//pkg/api:go_default_library", "//pkg/api/install:go_default_library", "//pkg/capabilities:go_default_library", <ins> "//pkg/cloudprovider/providers/fake:go_default_library", </ins> "//pkg/kubelet/apis:go_default_library", "//pkg/kubelet/apis/kubeletconfig:go_default_library", "//pkg/kubelet/cadvisor/testing:go_default_library",

Discussion:
BUG REPORT: /kind bug What happened: After upgrading the kubernetes cluster from 1.6.4 with the VSphere Cloud Provider enabled to 1.6.5/1.6.6 or 1.6.7, the cluster nodes don't have anymore InternalIPs Several issues occur at this step. For example, it breaks heapster with such an error : What you expected to happen: The node should have an InternalIP. How to reproduce it (as minimally and precisely as possible): Deploy a 1 node kubernetes cluster in a VM, and enable the vsphere cloud provider. Anything else we need to know?: with kubernetes 1.6.4 we get : Downgrading to 1.6.4 fixes the issue. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: vsphere OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others: It may be related to some changes around PR kubernetes /area platform/vsphere cloudprovider
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig cluster-ops /sig network /area platform/vsphere /area cloudprovider
Performing some more tests on a mini instance outside of the production cluster, I think I've identified the issue. The configuration required to start kubelet with the option (otherwise the wrong IP/interface is used to communicate between nodes). The issue is triggered when this option is set. The cloud provider looks OK. But the issue is located here : When the is not , the loop iterates on the node addresses and returns only the first one found. Since PR kubernetes, the list always returns an ExternalIP first. I think the loop in should iterate on all the addresses to rebuild the list, so that it will include the ExternalIP and the InternalIP. Can someone confirm the analysis ?
/sig node
ping
Modifying the code like this solved the issue : which returns : I guess it can be done in a cleaner way, but it was to quickly test the fix.

CC:
Thanks for filing this issue related to vSphere cloud provider. I agree with your analysis. It seems the current function assumes that the IP address specified by user can only be InternalIP. Your fix to is a better solution than work-around in cloud provider.
Hi, what are the next steps to discuss about the PR ? Are you able to make some tests ?