jiebi/CodeConvo huggingface dataset:
Code change:
sanitizedSpecVolID := kstrings.EscapeQualifiedNameForDisk(specVolID) return path.Join(host.GetVolumeDevicePluginDir(csiPluginName), sanitizedSpecVolID, "data") } <ins> // hasReadWriteOnce returns true if modes contains v1.ReadWriteOnce func hasReadWriteOnce(modes []api.PersistentVolumeAccessMode) bool { if modes == nil { return false } for _, mode := range modes { if mode == api.ReadWriteOnce { return true } } return false } </ins>

Related discussion:
text: It would be a 1.12.
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Approved for 1.12
Based on previous post, this is a summary: If then is not applied (because it could be an indication of a nonblock fs, or error) Done is provided if fstype is invalid Done if fstype is valid and then apply fsgroup logic else ignore fsGroup Done
- any updates on ?
Waiting for a review and approval.
you have a outstanding comment on the PR. Can you please answer that?
How does this approach relate to inline CSI volumes? There's no PersistentVolume involved, and hence no way to specify an access mode. , but my driver ignores it (always using tmpfs). I considered having my CSI driver read the mounting pod's spec to see if it has a security context with "fsGroup" set, since that detail is not supplied to the driver, as . My goal is to have the volume mounted with the files on it readable by the container's user, but there's no way for my driver to know who that user will be. Am I supposed to just use 0444 for the ownership bits, to allow everyone to read the files?
Code change:
new_storage_version=${test_data[5]} kube::log::status "Verifying ${resource}/${namespace}/${name} has updated storage version ${new_storage_version} in etcd" <del> curl -s http://${ETCD_HOST}:${ETCD_PORT}/v2/keys/registry/${resource}/${namespace}/${name} | grep ${new_storage_version} </del> <ins> curl -s http://${ETCD_HOST}:${ETCD_PORT}/v2/keys/${ETCD_PREFIX}/${resource}/${namespace}/${name} | grep ${new_storage_version} </ins> done killApiServer

Related discussion:
text: removed this test. We need to continue testing this. This wasn't about testing upgrades, the prefix has nothing to do with upgrades. It's just there so people can share etcd. We maybe don't need to double everything but we do need to make sure that keeps working.
To be honest - I think that what we was testing before didn't give us completely any information. We didn't testing what information we are storing in etcd and where. That said, if we had a hardcoded prefix somewhere in our code, we wouldn't discover it at all, and those tests would still be passing. We should have a test that is directly checking etcd contents. I think it should be possible to write a simple unit test for it. Will try to put something together next week.
Code change:
dockertypes "github.com/docker/engine-api/types" ) <ins> // These two functions are OS specific (for now at least) func updateHostConfig(config *dockercontainer.HostConfig) { } func DefaultMemorySwap() int64 { return -1 } </ins> func getContainerIP(container *dockertypes.ContainerJSON) string { return "" }

Related discussion:
text: What happened: Latest kubelet + Windows Docker version 1.14.0-dev refused to start any containers, error output: "invalid option: Windows does not support MemorySwap" How to reproduce it (as minimally and precisely as possible): It's always reproducible with Windows Docker 1.14.0-dev + latest kubelet code base. Anything else do we need to know: It didn't happen for Windows Docker 1.12.2-cs2-ws-beta. The reason behind the issue was because new code was for Windows Docker to check Resources parameters, it doesn't accept a non-zero value for MemorySwap: But kubelet was default to set an unlimited (-1) value. The issue was gone in my setup after applied a private fix to disable MemorySwap by set it to zero for Windows.
Code change:
} base := host hostURL, err := url.Parse(base) <del> if err != nil { return nil, "", err } if hostURL.Scheme == "" || hostURL.Host == "" { </del> <ins> if err != nil || hostURL.Scheme == "" || hostURL.Host == "" { </ins> scheme := "http://" if defaultTLS { scheme = "https://"

Related discussion:
text: Hi, I have been trying to run api-server as an standalone service along with etcd. I am passing etcd-servers and cluster-ip-range as arguments, here is the error I am getting: etcd servers are up and running on that address. Any leads as to how to resolve this? TIA.
This is only happening with go1.8 version, not really sure what is causing issue while parsing the URI.
Caused by this change i believe - CC as 1.8beta1 is being worked on here -
Thanks
I'm getting this exact issue using Kubernetes 1.5.7 and Go 1.8.3. Reverting to Go 1.7 seems to resolve it. This happened after updating a Go 1.7-compiled 1.4.8 Kubernetes cluster to 1.5.7, not sure if that's a corner case. For reference, my stack trace:
Code change:
package main import ( <ins> goflag "flag" </ins> "fmt" "math/rand" "os" "time" <ins> "github.com/spf13/pflag" </ins> utilflag "k8s.io/apiserver/pkg/util/flag" "k8s.io/apiserver/pkg/util/logs" "k8s.io/kubernetes/cmd/kube-proxy/app"

Related discussion:
text: 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
probably caused by
Could be a clash between these two?
cc
I still see the issue with local-cluster on the latest master: F0225 17:06:49. ] error: v1alpha1.KubeProxyConfiguration: FeatureGates: ReadMapCB: expect { or n, but found ", error found in byte of ......
looks like that's another issue, can you please file a new bug? with more logs? this one was about none of the hyperkube based processes starting up.
will do as it is also broke container kube-proxy as well. Same type of error.
Code change:
}) It("should write files of various sizes, verify size, validate content", func() { <del> fileSizes := []int64{1 * framework.MiB, 100 * framework.MiB, 1 * framework.GiB} </del> <ins> fileSizes := []int64{fileSizeSmall, fileSizeMedium, fileSizeLarge} </ins> err := testVolumeIO(f, cs, config, volSource, &podSec, testFile, fileSizes) Expect(err).NotTo(HaveOccurred()) })

Related discussion:
text: The "Volume plugin streaming [Slow] NFS should write files of various sizes, verify size, validate content" e2e test is failing on our 2k-node gce clusters (https://k8s-) with the following error: cc
Could you take a look into it or reassign as apt? This is part of the correctness suite and large cluster tests are release-blocking.
/assign
is this run using the kubemark environment? I'll also take a look. It could be that the commands this test needs to execute may not work with kubemark. /assign
cc
No, this is not kubemark. This is on a real 2000-node cluster.
Also all other volume-related e2e tests are passing, except this one.
Looking at the log I see that the nfs test fails trying to verify the test file's content. The test exec's into the nfs client pod and executes: The return code from above is 127. The test then deletes the nfs client pod calling which works. The nfs-server pod is deleted in the AfterEach. For some reason the reported error is 137 but the returned err 127. The same command is exec'd for all of the tested storage plugins so not sure why it's failing just for nfs. Error 127 might be "command not found".
The other strange thing is that it's only failing in this suite and not the others.
When I look at the kubelet log, I see the exec command coming through: I also see these suspicious kubelet soon afterwards: So I think the grep command is causing the node to run out of memory and get evicted. I think we can fix this either by: Making the grep command more memory efficient. I'm guessing it's reading the whole file into memory or, Make this test Serial so that it doesn't run in parallel with other pods, since it consumes a lot of memory.
An unrelated issue, is that the node allocatable feature didn't actually evict the pod. Instead this pod got a system OOM kill. /cc
related to the memcg notifications, not node allocatable. Thanks!
any theories why we see this only for the nfs-io tests, and not the glusterfs-io test for instance?
the gluster test didn't run on this in this suite.
Code change:
}) It("should write files of various sizes, verify size, validate content", func() { <del> fileSizes := []int64{1 * framework.MiB, 100 * framework.MiB, 1 * framework.GiB} </del> <ins> fileSizes := []int64{fileSizeSmall, fileSizeMedium, fileSizeLarge} </ins> err := testVolumeIO(f, cs, config, volSource, &podSec, testFile, fileSizes) Expect(err).NotTo(HaveOccurred()) })

Related discussion:
text: I'm suspecting that the reason why we didn't see a problem with this test on other suites is that the load could be higher here. I've asked to see if we can reduce the memory usage of the grep call.
pointed out that there are no newlines in the generated file, so when grep is called it could buffer the entire file in memory. Adding a newline at the end of the dd input file should do it.
/priority critical-urgent
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/scalability sig/storage: 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
It seems like even if the generated file is broken up by newlines, grep could still use on the order of hundreds of MB of memory for a 100MiB file (even with the -m1 and -F options). We could check the file line by line, but it would take a long time. A better solution would be to check the MD5 file hash. It's fast and uses little memory. The expected hashes will be hard-coded into the test, and if different file sizes are in the future, a hash needs to be computed and as well.
Thanks a lot for fixing this!
Ref
Code change:
import ( "fmt" <ins> "os" </ins> "strings" "syscall" "unsafe"

Related discussion:
text: When a --resolv-conf (DNS resolver config) is passed to kubelet on a Windows node, the config content is used as part of sandbox initialization (through getHostDNSConfig()). Now with the recent changes (), it seems now to fail with an error like: E0315 10:22:16. 4764 ] "Error syncing pod, skipping" err="failed to "CreatePodSandbox" for "img-pull-(-b40a-459d-9033-)" with CreatePodSandboxError: "Failed to generate sandbox config for pod "img-pull-(-b40a-459d-9033-)": Unexpected resolver config value: "C:etckubernetescni". Expected "" or "Host"."" pod="img-puller-3842/img-pull-" podUID=-b40a-459d-9033- This is showing on all the runs of GCE testgrid (latest): Reading/using the passed resolv config on Windows Run a Windows pool with DNS resolv config being set as part of kubelet params. No response_ 27 alpha.3 1.27 beta.0 master <detailsGCE </details<details</details<details</details<details</details<details</details
/triage accepted /milestone v1.27 /sig node /sig network
/sig windows /cc
/priority criticial-urgent as this is likely a release blocking
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority criticial-urgent 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
/priority critical-urgent
Hmm, so you're setting the [1]. This PR introduced the capability to read the DNS config options from the Windows host registries while removing the capability to read from a file, introducing a regression. I've sent a PR addressing this issue: [1]
Is the file you are pointing to a UNIX-style or something else?
Was the file changing the behavior of the node?
Code change:
import ( "fmt" <ins> "os" </ins> "strings" "syscall" "unsafe"

Related discussion:
text: Yeah, what used on GCE/GKE, seems to be a Linux-like conf, eg: nameserver 10.128.0.1 search c.<project_name.internal google.internal ` We haven't tried to remove from kubelet to see the behavior.
This Issue/PR has been marked as release blocker. Please have the fix merged by eod today otherwise the feature has to be reverted. For the Issue/PR owner: please have a revert/feature disable PR open today in case the fix failed to get in. Thank you! See the -- Kubernetes 1.27 release manager
I opened up a revert PR in case this PR does not merge by code freeze.
Thanks for the resolution! both 2019 and 2022 grids seems to be back to green now!
Thanks for confirming! I opened to ensure gets updated too
Code change:
t.Fatal(err) } j = convertNullTypeToNullable(j) <ins> j = stripIntOrStringType(j) </ins> openAPIJSON, err = json.Marshal(j) if err != nil { t.Fatal(err)

Related discussion:
text: The server-side validation does not check the type of values with . Create a CRD like: Then create a CR: It is not rejected, but should because must not be a boolean.
Code change:
// GetZoneByNodeName gets cloudprovider.Zone by node name. func (ss *scaleSet) GetZoneByNodeName(name string) (cloudprovider.Zone, error) { <del> _, _, vm, err := ss.getVmssVM(name) </del> <ins> managedByAS, err := ss.isNodeManagedByAvailabilitySet(name) </ins> if err != nil { <del> if err == ErrorNotVmssInstance { glog.V(4).Infof("GetZoneByNodeName: node %q is managed by availability set", name) // Retry with standard type because nodes are not managed by vmss. return ss.availabilitySet.GetZoneByNodeName(name) } </del> <ins> glog.Errorf("Failed to check isNodeManagedByAvailabilitySet: %v", err) return cloudprovider.Zone{}, err } if managedByAS { // vm is managed by availability set. return ss.availabilitySet.GetZoneByNodeName(name) } _, _, vm, err := ss.getVmssVM(name) if err != nil { </ins> return cloudprovider.Zone{}, err }

Related discussion:
text: <!-- 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?: What happened: VMAS nodes are reporting error in vmss cluster (vmType set to vmss). What you expected to happen: Node should register correctly in the kubernetes cluster. How to reproduce it (as minimally and precisely as possible): Create a VMAS nodes inside vmss cluster. Anything else we need to know?: Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: azure OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig azure
Code change:
# CNI storage path for Windows nodes export WINDOWS_CNI_STORAGE_PATH="https://storage.googleapis.com/k8s-artifacts-cni/release" # CNI version for Windows nodes <del> export WINDOWS_CNI_VERSION="v0.8.7" </del> <ins> export WINDOWS_CNI_VERSION="v0.9.1" </ins> # Pod manifests directory for Windows nodes on Windows nodes. export WINDOWS_MANIFESTS_DIR="${WINDOWS_K8S_DIR}manifests" # Directory where cert/key files will be stores on Windows nodes.

Related discussion:
text: The latest release of CNI plugins is , but we still have . I'll attempt to create a PR for this based on the .
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 network
- assigning to you :)
Code change:
// The name of this port. All ports in an EndpointSlice must have a unique // name. If the EndpointSlice is dervied from a Kubernetes service, this // corresponds to the Service.ports[].name. <del> // Name must either be an empty string or pass IANA_SVC_NAME validation: // * must be no more than 15 characters long // * may contain only [-a-z0-9] // * must contain at least one letter [a-z] // * it must not start or end with a hyphen, nor contain adjacent hyphens </del> <ins> // Name must either be an empty string or pass DNS_LABEL validation: // * must be no more than 63 characters long. // * must consist of lower case alphanumeric characters or '-'. // * must start and end with an alphanumeric character. </ins> // Default is empty string. Name *string `json:"name,omitempty" protobuf:"bytes,1,name=name"` // The IP protocol for this port.

Related discussion:
text: What happened: No endpoints created in the EndpointSlice for my service due to the port on the service being too long. Logs show: EndpointSlice created has no endpoint: What you expected to happen: Service that works with Endpoints should work with EndpointSlice. If this is intentional, it should be clearly documented How to reproduce it (as minimally and precisely as possible): Create a service with a long port name Environment: Kubernetes version (use ): 1.16 Cloud provider or hardware configuration: kind
/sig networking
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /sig networking 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 network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
For a rough measure of impact, Istio had 5 ports that were over this limit (and many more that were right at 15 characters), so I suspect it may not be terribly rare.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This needs to be resolved before endpointslices graduate from alpha
/assign
/remove-triage unresolved
Code change:
} glog.V(5).Infof("namespace controller - deleteAllContentForGroupVersionResource - items remaining - namespace: %s, gvr: %v, items: %v", namespace, gvr, len(unstructuredList.Items)) if len(unstructuredList.Items) != 0 && estimate == int64(0) { <ins> // if any item has a finalizer, we treat that as a normal condition, and use a default estimation to allow for GC to complete. for _, item := range unstructuredList.Items { if len(item.GetFinalizers()) > 0 { glog.V(5).Infof("namespace controller - deleteAllContentForGroupVersionResource - items remaining with finalizers - namespace: %s, gvr: %v, finalizers: %v", namespace, gvr, item.GetFinalizers()) return finalizerEstimateSeconds, nil } } // nothing reported a finalizer, so something was unexpected as it should have been deleted. </ins> return estimate, fmt.Errorf("unexpected items still remain in namespace: %s for gvr: %v", namespace, gvr) } return estimate, nil

Related discussion:
text: Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "LRUExpireCache" Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT What happened: requires write lock since needs to manipulate its list to track recently used item. Currently it uses read lock so it may introduce race condition. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else do we need to know:
This was fixed in
Code change:
// the test so we can ensure that we clean up after // ourselves defer podClient.Delete(pod.Name, api.NewDeleteOptions(0)) <del> _, err = podClient.Create(pod) </del> <ins> pod, err = podClient.Create(pod) </ins> if err != nil { Failf("Failed to create pod: %v", err) } By("verifying the pod is in kubernetes") <ins> selector = labels.SelectorFromSet(labels.Set(map[string]string{"time": value})) options = api.ListOptions{ LabelSelector:   selector, ResourceVersion: pod.ResourceVersion, } </ins> pods, err = podClient.List(options) if err != nil { Failf("Failed to query for pods: %v", err)

Related discussion:
text: cc
Yet another failure
There is already fix in flight
Ok. I see
This was closed 5 days ago but appears to not be fixed. Many PRs have referenced it as a flake since the fix went in.
- I referenced to it 2 after it was closed, but all of those failures were from runs before this was merged. So it's possible that it's already fixed.
When was the fix merged? I saw this a couple hours ago:
Oops, same test but the error is slightly different... Maybe this is a seperate flake
Yeah - it seems to be something different.
Also - I'm not claiming it's definitely fixed - I just said that we need to double check, because the two that I linked was from before merge.
I'll close this one for now. Please reopen the issue and cc us if the flake occurs again.
Code change:
return true }) if err != nil { <ins> if apiErr, ok := err.(awserr.Error); ok && apiErr.Code() == "DelegationSetNotReusable" || apiErr.Code() == "NoSuchDelegationSet" || apiErr.Code() == "InvalidInput" { return []dnsprovider.Zone{}, nil } </ins> return []dnsprovider.Zone{}, err } return zoneList, nil

Related discussion:
text: /kind bug What happened: walteraa [6:55 AM] Hi, The controller manager of the federation using Google cloud DNS is crashing, the log showed is that: the hyperkube command is that: I have created this in the Google DNS Someone knows why the DNS zone query is getting the 404 error?? :disappointed: What you expected to happen: It should have created the missing domain. How to reproduce it (as minimally and precisely as possible): As per above. Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.4 Cloud provider or hardware configuration**: OpenStack (irrelevant) OS (e.g. from /etc/os-release): irrelevant Kernel (e.g. ): irrelevant Install tools: irrelevant Others: irrelevant
The bug is related to this: The above code assumes that the provider code returns no error but an empty list if the domain does not exist, but instead the provider returns a 404. Need to fix the provider and/or the above code.
/sig federation
I am unlikely to have time to work on this soon, so if anyone else wants to, go right ahead.
/assign
An additional information: I have created a which is based on the credential JSON file created through instruction. After that, I have configured the Federation controller manager to mount this secret as a volume in the container and set the environment variable to the JSON file inside this volume. Before doing that, I was getting an authentication error so the google DNS provider couldn't be instantiated, and after doing the instructions that I mentioned before, this authentication error was solved but now I'm getting 404 error when Google DNS provider tries access the specified managed zone. The file that I have generated follow this structure: