jiebi/CodeConvo huggingface dataset:
Code change:
(disk.ManagedDisk != nil && diskURI != "" && strings.EqualFold(*disk.ManagedDisk.ID, diskURI)) { // found the disk klog.V(2).Infof("azureDisk - detach disk: name %q uri %q", diskName, diskURI) <del> disks[i].ToBeDetached = to.BoolPtr(true) </del> <ins> if strings.EqualFold(as.cloud.Environment.Name, "AZURESTACKCLOUD") { disks = append(disks[:i], disks[i+1:]...) } else { disks[i].ToBeDetached = to.BoolPtr(true) } </ins> bFoundDisk = true break }

Related discussion:
text: <!-- 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: flag is not supported on Azure Stack, should switch to use original way to remove a disk from data disk list, refer to for more details 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 ): 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Code change:
klog.Errorf("cannot convert to *v1.Node: %v", t) return } <ins> klog.V(3).Infof("delete event for node %q", node.Name) </ins> // NOTE: Updates must be written to scheduler cache before invalidating // equivalence cache, because we could snapshot equivalence cache after the // invalidation and then snapshot the cache itself. If the cache is

Related discussion:
text: This helps debugging scheduler's behavior, currently we don't have logs that indicate when the scheduler first saw a pod or a node. The log level should be v=3. /sig scheduling /cc
Do you mean add logging for callbacks in ?
yes, at least for add and delete events
Sure, I can also give this pr, before tomorrow
/assign
We actually have one v=2 log line for a Node being to the cache's tree: But it's probably good to keep this one.
Code change:
package fake <ins> import ( "fmt" "k8s.io/apimachinery/pkg/util/rand" ) </ins> const ( <del> defaultUnixEndpoint = "unix:///tmp/kubelet_remote.sock" </del> <ins> defaultUnixEndpoint = "unix:///tmp/kubelet_remote_%v.sock" </ins> ) // GenerateEndpoint generates a new unix socket server of grpc server. func GenerateEndpoint() (string, error) { <del> return defaultUnixEndpoint, nil </del> <ins> // use random int be a part fo file name return fmt.Sprintf(defaultUnixEndpoint, rand.Int()), nil </ins> }

Related discussion:
text: Which jobs are flaking: periodics-kubernetes-bazel-test Which test(s) are flaking: //pkg/kubelet/cri/remote TestVersion Testgrid link: Reason for failure: Error: Received unexpected error: rpc error: code = Unavailable desc = transport is closing panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference Anything else we need to know: To reproduce with stress: go test -race -c ./pkg/kubelet/cri/remote stress - TestVersion Detailed logs
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 testing
I 'll give it a see and fix it :)
/assign
/remove-sig testing SIG node owns their unit tests. SIG testing owns the framework, infrastructure, etc.
/sig node
Code change:
return true, errors.New("not implemented") } <ins> func (m *execMounter) EvalHostSymlinks(pathname string) (string, error) { return "", errors.New("not implemented") } </ins> func (mounter *execMounter) PrepareSafeSubpath(subPath Subpath) (newHostPath string, cleanupAction func(), err error) { return subPath.Path, nil, nil }

Related discussion:
text: /kind bug Using , if a block device is symlinked to the discovery directory e.g. , then MapVolume will fail with since the containerized kubelet cannot see the path on host. is mounted by containerized kubelet, so if before we try to map the device we set devicePath to the evaluation of symlink and end up with a devicePath of , containerized kubelet will see the device and successfully map the device. Are there any issues with this solution? This is on Kubernetes 1.10
/sig storage
ah yes containerized kubelet has many issues when dealing with symlinks. Check out Mounter.GetMode(), it calls a nsenter EvalSymlinks which should be able to do what you need. But actually, one thing to consider, is do you need to do the losetup on the host, or does inside the container work?
Yes it appears to work from inside the container, on the host I run which disappears after I delete the pod using the device. My understanding of running losetup in MapVolume is not that great but I suppose that as long as that /dev/loop0 is created we are fine. Thanks for the quick response, I'll create a PR using that function and tag you
Does it create it on the host or in the containerized kubelet? What happens when containerized kubelet is restarted? The purpose of losetup is to do "refcounting" on the block device to prevent possible naming collisions when devices are attached/detached under unhealthy conditions. Ie, if a device showed up as /dev/sdb and you gave that to a pod, and then for some reason it become unhealthy and disappeared (while the pod is still running), another device (maybe even another volume type) could get attached to the node and reuse /dev/sdb. Now the pod has access to a device it's not supposed to. With filesystem volumes, the refcounting is done with mount points, but for block device, loopback is the equivalent.
It is created on the host (and also visible in the container), and stays around through restart. I understand now, thank you.
Actually after I restart it becomes /vdb instead of /dev/vdb in the losetup output, idk what that is about.
Code change:
return true, errors.New("not implemented") } <ins> func (m *execMounter) EvalHostSymlinks(pathname string) (string, error) { return "", errors.New("not implemented") } </ins> func (mounter *execMounter) PrepareSafeSubpath(subPath Subpath) (newHostPath string, cleanupAction func(), err error) { return subPath.Path, nil, nil }

Related discussion:
text: There is no such thing as /vdb and /dev/vdb is still intact of course. Seems inconsequential since it is disappearing after all pods using the device are deleted, i.e. it's still serving as a refcounter
Code change:
Description: The command 'kubectl version' MUST return the major, minor versions,  GitCommit, etc of the Client and the Server that the kubectl is configured to connect to. */ framework.ConformanceIt("should check is all data is printed ", func() { <del> version := framework.RunKubectlOrDie(ns, "version") requiredItems := []string{"Client Version:", "Server Version:", "Major:", "Minor:", "GitCommit:"} </del> <ins> versionString := framework.RunKubectlOrDie(ns, "version") // we expect following values for: Major -> digit, Minor -> numeric followed by an optional '+',  GitCommit -> alphanumeric requiredItems := []string{"Client Version: ", "Server Version: "} </ins> for _, item := range requiredItems { <del> if !strings.Contains(version, item) { framework.Failf("Required item %s not found in %s", item, version) </del> <ins> if matched, _ := regexp.MatchString(item+`version.Info{Major:"d", Minor:"d++?", GitVersion:"vd.d+.[dw-.+]+", GitCommit:"[0-9a-f]+"`, versionString); !matched { framework.Failf("Item %s value is not valid in %sn", item, versionString) </ins> } } })

Related discussion:
text: only check that the output includes the correct keys - they don't confirm that it has appropriate values. Doing full validation on the version data, or at least enough to catch null-string values, would guard against failures like the bad functionality seen in OpenSUSE's binaries, which have been shipping with many of the fields left completely blank (as I discovered ).
/sig testing
/remove-sig testing /sig cli Edit: testing owns the framework, binaries, infrastructure etc. for testing. SIG CLI is nominally responsible for their test cases.
If SIGs are responsible for their own testcases, then this touches test cases for api-machinery as well (I'm not sure what the non-CLI version of this is, but there's definitely a schema adherence test that should fail at the API level). /sig api-machinery
/triage accepted /assign
GitHub didn't allow me to assign the following users: SaiHarshaK. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /triage accepted /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
/assign
Code change:
// The first detach will be triggered after at least 50ms (maxWaitForUnmountDuration in test). // Right before detach operation is performed, the volume will be first removed from being reported // as attached on node status (RemoveVolumeFromReportAsAttached). After detach operation which is expected to fail, <del> // controller then added the volume back as attached. </del> <ins> // controller then treats the attachment as Uncertain. </ins> // Here it sleeps 100ms so that detach should be triggered already at this point. <del> // verifyVolumeReportedAsAttachedToNode will check volume is in the list of volume attached that needs to be updated // in node status. By calling this function (GetVolumesToReportAttached), node status should be updated, and the volume // will not need to be updated until new changes are applied (detach is triggered again) </del> time.Sleep(100 * time.Millisecond) <del> verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw, volumeAttachedCheckTimeout) </del> <ins> verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateUncertain, asw) verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, false, asw, volumeAttachedCheckTimeout) </ins> // Add a second pod which tries to attach the volume to the same node. <del> // After adding pod to the same node, detach will not be triggered any more. </del> <ins> // After adding pod to the same node, detach will not be triggered any more, // the volume gets attached and reported as attached to the node. </ins> generatedVolumeName, podAddErr = dsw.AddPod(types.UniquePodName(podName2), controllervolumetesting.NewPod(podName2, podName2), volumeSpec, nodeName1) if podAddErr != nil { t.Fatalf("AddPod failed. Expected: <no error> Actual: <%v>", podAddErr)

Related discussion:
text: KCM starts, all VolumeAttachments that don't have a Pod (that's good), but also (that's probably bad). When the newly started KCM re-tries to detach the volume and gets an error again, it marks the volume as fully attached (same as the previous point) and adds it to . Now the volume is both mounted + attached in ASW and A/D controller actually stops here and waits forever for kubelet to unmount the volume. <detailsToday's k/k master, </details<detailsNone </details<detailsN/A, it's KCM issue. </details<details, but seen in a downstream Kubernetes distro too. </details<details</details<details</details
/sig storage
/assign
/triage accepted
I have the same problem: Seems restart of Kubelet solves this problem. Kubernetes v1.25.13
Code change:
eventRecorder := record.NewFakeRecorder(100) eventRecorder.IncludeObject = true <del> metadataClient := fakemetadata.NewSimpleMetadataClient(legacyscheme.Scheme) </del> <ins> metadataClient := fakemetadata.NewSimpleMetadataClient(fakemetadata.NewTestScheme()) </ins> tweakableRM := meta.NewDefaultRESTMapper(nil) tweakableRM.AddSpecific(

Related discussion:
text: Because of this scheme mutation, this leads to concurrent use of the same scheme to cause the program to panic. It would be ideal to do this in some concurrent safe manner or add a warning or similar
/sig api-machinery
/assign
/assign /triage accepted
Code change:
} labels["e2e-run"] = string(RunId) <ins> // We don't use ObjectMeta.GenerateName feature, as in case of API call // failure we don't know whether the namespace was created and what is its // name. name, err := findAvailableNamespaceName(baseName, c) if err != nil { return nil, err } </ins> namespaceObj := &v1.Namespace{ ObjectMeta: metav1.ObjectMeta{ <del> GenerateName: fmt.Sprintf("e2e-tests-%v-", baseName), Namespace:    "", Labels:       labels, </del> <ins> Name:      name, Namespace: "", Labels:    labels, </ins> }, Status: v1.NamespaceStatus{}, }

Related discussion:
text: <!-- 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: In the test failed due to namespace leakage: we created e2e-tests-load-30-nodepods-1-pfn9m, but never got response from api server (got 0-length response instead) we retried and created e2e-tests-load-30-nodepods-1-m9tq5 e2e-tests-load-30-nodepods-1-m9tq5 to f.namespacesToDelete and leaked -pfn9m next test case failed because e2e-tests-load-30-nodepods-1-pfn9m wasn't deleted. What you expected to happen: While it's unclear why we got 0-length response instead ( investigates that), we always can get error while the namespace was created (e.g. connection reset, timeout, io error). We should handle this case in retrying correctly. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.14.0-alpha.0.793+ Cloud provider or hardware configuration: gce OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
There are no sig labels on this issue. Please add a sig label 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. <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
/cc
Code change:
if err := os.WriteFile(certFixturePath, certBuffer.Bytes(), 0644); err != nil { return nil, nil, fmt.Errorf("failed to write cert fixture to %s: %v", certFixturePath, err) } <del> if err := os.WriteFile(keyFixturePath, keyBuffer.Bytes(), 0644); err != nil { </del> <ins> if err := os.WriteFile(keyFixturePath, keyBuffer.Bytes(), 0600); err != nil { </ins> return nil, nil, fmt.Errorf("failed to write key fixture to %s: %v", certFixturePath, err) } }

Related discussion:
text: Hello, the SRC folks asked that I file this publicly: In the client-go repo, , function creates a private key and stores it into a file with mode : Typically keys are created with more restrictive modes to prevent other users or services on the system from being able to copy them before the user fixes the permissions. Of course, if a more restrictive umask is in place, this may not be a big deal, but it's an extremely fickle piece of the environment to rely upon for security. It's better to be explicit. Thanks
/kind bug Not sure if this is /sig api-machinery or /sig auth
is this related to us?
Hi IMO, mode make sense for the key file. I would like to work on this, waiting for Thanks!!
/triage accepted
/assign
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]:
/remove-lifecycle stale
/lifecycle frozen /good-first-issue I think changing the code to use should be fine. Anyone is free to pick this up. Would be good to include a unit test.
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /lifecycle frozen /good-first-issue Instructions for interacting with me using PR comments are available .
Code change:
if err := os.WriteFile(certFixturePath, certBuffer.Bytes(), 0644); err != nil { return nil, nil, fmt.Errorf("failed to write cert fixture to %s: %v", certFixturePath, err) } <del> if err := os.WriteFile(keyFixturePath, keyBuffer.Bytes(), 0644); err != nil { </del> <ins> if err := os.WriteFile(keyFixturePath, keyBuffer.Bytes(), 0600); err != nil { </ins> return nil, nil, fmt.Errorf("failed to write key fixture to %s: %v", certFixturePath, err) } }

Related discussion:
text: If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
Hello, this is my first ever open source contribution. I am trying to understand and get this fixed. Any suggestions would be helpful!
/assign
/assign
Code change:
"//staging/src/k8s.io/cri-api/pkg/apis/testing:go_default_library", "//vendor/google.golang.org/grpc:go_default_library", "//vendor/k8s.io/utils/exec:go_default_library", <del> ], </del> <ins> ] + select({ "@io_bazel_rules_go//go/platform:aix": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:android": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:darwin": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:dragonfly": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:freebsd": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:illumos": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:ios": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:js": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:linux": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:nacl": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:netbsd": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:openbsd": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:plan9": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "@io_bazel_rules_go//go/platform:solaris": [ "//staging/src/k8s.io/apimachinery/pkg/util/rand:go_default_library", ], "//conditions:default": [], }), </ins> ) filegroup(

Related discussion:
text: Which jobs are flaking: periodics-kubernetes-bazel-test Which test(s) are flaking: //pkg/kubelet/cri/remote TestVersion Testgrid link: Reason for failure: Error: Received unexpected error: rpc error: code = Unavailable desc = transport is closing panic: runtime error: invalid memory address or nil pointer dereference [recovered] panic: runtime error: invalid memory address or nil pointer dereference Anything else we need to know: To reproduce with stress: go test -race -c ./pkg/kubelet/cri/remote stress - TestVersion Detailed logs
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 testing
I 'll give it a see and fix it :)
/assign
/remove-sig testing SIG node owns their unit tests. SIG testing owns the framework, infrastructure, etc.
/sig node
Code change:
gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM= honnef.co/go/tools v0.0.0-20190102054323-c2f93a96b099/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4= honnef.co/go/tools v0.0.0-20190523083050-ea95bdfd59fc/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4= <ins> k8s.io/klog/v2 v2.80.1 h1:atnLQ121W371wYYFawwYx1aEY2eUfs4l3J72wtgAwV4= k8s.io/klog/v2 v2.80.1/go.mod h1:y1WjHnz7Dj687irZUWR/WLkLc5N1YHtjLdmgWjndZn0= </ins>

Related discussion:
text: generation for local KEK based on counter; also rotate once a week even if the counter does not hit 2 million? using AES-GCM encryption of local KEK ref: The implementation would be to the directory.
/sig auth /triage accepted
/assign
GitHub didn't allow me to assign the following users: ibihim. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, 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
/assign
thank you !
/milestone v1.26
Hi bug-triage shadow team member for 1.26 here. Looks like this issue is in the 1.26 milestone, but has been moved to 1.27. Is there something else or should this issue go to 1.27 as well? Thank you!
I just forgot to move this issue /milestone v1.27
/reopen is the partial implementation.
Reopened this issue. <detailsIn response to : /reopen 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
My suggestion on the reference implementation, after reading 's comments is like so... The GRPC server, which implements the expects an implementation that satisfies . The local key logic can be a middleware. So it expects a it can fallback to, if it doesn't know a key or needs to encrypt its own local KEK. So the local implementation would be need to: have a storage of s have a reference to the current in use (if we put it into the cache, it might vanish) have a reference to another , which should be the remote KMS. So the sub-stories could look like: write Middleware write Transformers that can get exhausted (by time, by usage) write 's storage write some dummy for remote KMS? I have some sketches of what I am talking about .