Question:
I tried to use a local volume block device in minikube. Its trying to call losetup with the -j option and its failing as the losetup in minikube does not provide this option. This may effect other distro's as well. The end result is lock block devices don't work on the platform.
/sig storage
Probably caused by this code:
Did a strace on losetup -j. looks like the same info can be had by: cat /sys/block/loop0/loop/backing_file
Just had the same problem with Ceph cluster creation in minikube, the osd-prepare doesn't start because of this:
FYI: has the same problem in minikube. Replacing the /sbin/losetup busybox link with a "real" losetup helped for now, but isn't a solution of course.
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 rotten
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
/remove-lifecycle stale
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
/remove-lifecycle stale
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/help
This request has been marked as needing help from a contributor. 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 : /help </details

return "", fmt.Errorf("not attachable: %v", err) } <del> args := []string{"-j", path} out, err := exec.Command(losetupPath, args...).CombinedOutput() if err != nil { klog.V(2).Infof("Failed device discover command for path %s: %v", path, err) return "", err } return parseLosetupOutputForDevice(out) </del> <ins> return getLoopDeviceFromSysfs(path) </ins> } func makeLoopDevice(path string, exec utilexec.Interface) (string, error) { <del> args := []string{"-f", "-P", "--show", path} </del> <ins> args := []string{"-f", "-P", path} </ins> out, err := exec.Command(losetupPath, args...).CombinedOutput() if err != nil { <del> klog.V(2).Infof("Failed device create command for path %s: %v", path, err) </del> <ins> klog.V(2).Infof("Failed device create command for path %s: %v %s", path, err, out) </ins> return "", err } <del> return parseLosetupOutputForDevice(out) </del> <ins> return getLoopDeviceFromSysfs(path) </ins> } func removeLoopDevice(device string, exec utilexec.Interface) error {


Question:
I tried to use a local volume block device in minikube. Its trying to call losetup with the -j option and its failing as the losetup in minikube does not provide this option. This may effect other distro's as well. The end result is lock block devices don't work on the platform.
/sig storage
Probably caused by this code:
Did a strace on losetup -j. looks like the same info can be had by: cat /sys/block/loop0/loop/backing_file
Just had the same problem with Ceph cluster creation in minikube, the osd-prepare doesn't start because of this:
FYI: has the same problem in minikube. Replacing the /sbin/losetup busybox link with a "real" losetup helped for now, but isn't a solution of course.
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 rotten
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
/remove-lifecycle stale
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
/remove-lifecycle stale
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/help
This request has been marked as needing help from a contributor. 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 : /help </details

return strings.HasPrefix(device, "/dev/loop") } <del> func parseLosetupOutputForDevice(output []byte) (string, error) { if len(output) == 0 { </del> <ins> // getLoopDeviceFromSysfs finds the backing file for a loop // device from sysfs via "/sys/block/loop*/loop/backing_file". func getLoopDeviceFromSysfs(path string) (string, error) { // If the file is a symlink. realPath, err := filepath.EvalSymlinks(path) if err != nil { </ins> return "", errors.New(ErrDeviceNotFound) } <del> // losetup returns device in the format: // /dev/loop1: [0073]:148662 (/var/lib/storageos/volumes/308f14af-cf0a-08ff-c9c3-b48104318e05) device := strings.TrimSpace(strings.SplitN(string(output), ":", 2)[0]) if len(device) == 0 { </del> <ins> devices, err := filepath.Glob("/sys/block/loop*") if err != nil { </ins> return "", errors.New(ErrDeviceNotFound) } <del> return device, nil </del> <ins> for _, device := range devices { backingFile := fmt.Sprintf("%s/loop/backing_file", device) // The contents of this file is the absolute path of "path". data, err := ioutil.ReadFile(backingFile) if err != nil { continue } // Return the first match. backingFilePath := strings.TrimSpace(string(data)) if backingFilePath == path || backingFilePath == realPath { return fmt.Sprintf("/dev/%s", filepath.Base(device)), nil } } return "", errors.New(ErrDeviceNotFound) </ins> }


Question:
I tried to use a local volume block device in minikube. Its trying to call losetup with the -j option and its failing as the losetup in minikube does not provide this option. This may effect other distro's as well. The end result is lock block devices don't work on the platform.
/sig storage
Probably caused by this code:
Did a strace on losetup -j. looks like the same info can be had by: cat /sys/block/loop0/loop/backing_file
Just had the same problem with Ceph cluster creation in minikube, the osd-prepare doesn't start because of this:
FYI: has the same problem in minikube. Replacing the /sbin/losetup busybox link with a "real" losetup helped for now, but isn't a solution of course.
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 rotten
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
/remove-lifecycle stale
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
/remove-lifecycle stale
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/help
This request has been marked as needing help from a contributor. 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 : /help </details

package volumepathhandler import ( <del> "bufio" </del> "errors" "fmt" <ins> "io/ioutil" </ins> "os" "os/exec" "path/filepath"


Question:
I tried to use a local volume block device in minikube. Its trying to call losetup with the -j option and its failing as the losetup in minikube does not provide this option. This may effect other distro's as well. The end result is lock block devices don't work on the platform.
/sig storage
Probably caused by this code:
Did a strace on losetup -j. looks like the same info can be had by: cat /sys/block/loop0/loop/backing_file
Just had the same problem with Ceph cluster creation in minikube, the osd-prepare doesn't start because of this:
FYI: has the same problem in minikube. Replacing the /sbin/losetup busybox link with a "real" losetup helped for now, but isn't a solution of course.
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 rotten
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
/remove-lifecycle stale
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
/remove-lifecycle stale
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/help
This request has been marked as needing help from a contributor. 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 : /help </details

return "", fmt.Errorf("not attachable: %v", err) } <del> args := []string{"-j", path} cmd := exec.Command(losetupPath, args...) out, err := cmd.CombinedOutput() if err != nil { klog.V(2).Infof("Failed device discover command for path %s: %v %s", path, err, out) return "", fmt.Errorf("losetup -j %s failed: %v", path, err) } return parseLosetupOutputForDevice(out, path) </del> <ins> return getLoopDeviceFromSysfs(path) </ins> } func makeLoopDevice(path string) (string, error) { <del> args := []string{"-f", "--show", path} </del> <ins> args := []string{"-f", path} </ins> cmd := exec.Command(losetupPath, args...) out, err := cmd.CombinedOutput() if err != nil { <del> klog.V(2).Infof("Failed device create command for path: %s %v %s ", path, err, out) return "", fmt.Errorf("losetup -f --show %s failed: %v", path, err) </del> <ins> klog.V(2).Infof("Failed device create command for path: %s %v %s", path, err, out) return "", fmt.Errorf("losetup %s failed: %v", strings.Join(args, " "), err) </ins> } <del> // losetup -f --show {path} returns device in the format: // /dev/loop1 if len(out) == 0 { return "", errors.New(ErrDeviceNotFound) } return strings.TrimSpace(string(out)), nil </del> <ins> return getLoopDeviceFromSysfs(path) </ins> } // removeLoopDevice removes specified loopback device


Question:
I tried to use a local volume block device in minikube. Its trying to call losetup with the -j option and its failing as the losetup in minikube does not provide this option. This may effect other distro's as well. The end result is lock block devices don't work on the platform.
/sig storage
Probably caused by this code:
Did a strace on losetup -j. looks like the same info can be had by: cat /sys/block/loop0/loop/backing_file
Just had the same problem with Ceph cluster creation in minikube, the osd-prepare doesn't start because of this:
FYI: has the same problem in minikube. Replacing the /sbin/losetup busybox link with a "real" losetup helped for now, but isn't a solution of course.
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 rotten
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
/remove-lifecycle stale
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
/remove-lifecycle stale
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/help
This request has been marked as needing help from a contributor. 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 : /help </details

return nil } <del> func parseLosetupOutputForDevice(output []byte, path string) (string, error) { if len(output) == 0 { return "", errors.New(ErrDeviceNotFound) } </del> <ins> // getLoopDeviceFromSysfs finds the backing file for a loop // device from sysfs via "/sys/block/loop*/loop/backing_file". func getLoopDeviceFromSysfs(path string) (string, error) { // If the file is a symlink. </ins> realPath, err := filepath.EvalSymlinks(path) if err != nil { return "", fmt.Errorf("failed to evaluate path %s: %s", path, err) } <del> // losetup -j {path} returns device in the format: // /dev/loop1: [0073]:148662 ({path}) // /dev/loop2: [0073]:148662 (/dev/sdX) // // losetup -j shows all the loop device for the same device that has the same // major/minor number, by resolving symlink and matching major/minor number. // Therefore, there will be other path than {path} in output, as shown in above output. s := string(output) // Find the line that exact matches to the path, or "({path})" var matched string scanner := bufio.NewScanner(strings.NewReader(s)) for scanner.Scan() { // losetup output has symlinks expanded if strings.HasSuffix(scanner.Text(), "("+realPath+")") { matched = scanner.Text() break </del> <ins> devices, err := filepath.Glob("/sys/block/loop*") if err != nil { return "", fmt.Errorf("failed to list loop devices in sysfs: %s", err) } for _, device := range devices { backingFile := fmt.Sprintf("%s/loop/backing_file", device) // The contents of this file is the absolute path of "path". data, err := ioutil.ReadFile(backingFile) if err != nil { continue </ins> } <del> // Just in case losetup changes, check for the original path too if strings.HasSuffix(scanner.Text(), "("+path+")") { matched = scanner.Text() break </del> <ins> // Return the first match. backingFilePath := strings.TrimSpace(string(data)) if backingFilePath == path || backingFilePath == realPath { return fmt.Sprintf("/dev/%s", filepath.Base(device)), nil </ins> } } <del> if len(matched) == 0 { return "", errors.New(ErrDeviceNotFound) } s = matched // Get device name, or the 0th field of the output separated with ":". // We don't need 1st field or later to be splitted, so passing 2 to SplitN. device := strings.TrimSpace(strings.SplitN(s, ":", 2)[0]) if len(device) == 0 { return "", errors.New(ErrDeviceNotFound) } return device, nil </del> <ins> return "", errors.New(ErrDeviceNotFound) </ins> } // FindGlobalMapPathUUIDFromPod finds {pod uuid} bind mount under globalMapPath


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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 rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in

import ( "context" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> clientset "k8s.io/client-go/kubernetes" "k8s.io/kubernetes/test/e2e/framework" e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper"


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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 rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in

ginkgo.Describe("NFSv4", func() { ginkgo.It("should be mountable for NFSv4", func() { config, _, serverIP := volume.NewNFSServer(c, namespace.Name, []string{}) <del> defer volume.TestCleanup(f, config) </del> <ins> defer volume.TestServerCleanup(f, config) </ins> tests := []volume.Test{ {


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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 rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in

ginkgo.Describe("NFSv3", func() { ginkgo.It("should be mountable for NFSv3", func() { config, _, serverIP := volume.NewNFSServer(c, namespace.Name, []string{}) <del> defer volume.TestCleanup(f, config) </del> <ins> defer volume.TestServerCleanup(f, config) </ins> tests := []volume.Test{ {


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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 rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in

config, _, _ := volume.NewGlusterfsServer(c, namespace.Name) name := config.Prefix + "-server" defer func() { <del> volume.TestCleanup(f, config) </del> <ins> volume.TestServerCleanup(f, config) </ins> err := c.CoreV1().Endpoints(namespace.Name).Delete(context.TODO(), name, nil) framework.ExpectNoError(err, "defer: Gluster delete endpoints failed") }()


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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 rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in

return pod } <del> // TestCleanup cleans both server and client pods. func TestCleanup(f *framework.Framework, config TestConfig) { </del> <ins> // TestServerCleanup cleans server pod. func TestServerCleanup(f *framework.Framework, config TestConfig) { </ins> ginkgo.By(fmt.Sprint("cleaning the environment after ", config.Prefix)) defer ginkgo.GinkgoRecover() <del> cs := f.ClientSet err := e2epod.DeletePodWithWaitByName(cs, config.Prefix+"-client", config.Namespace) gomega.Expect(err).To(gomega.BeNil(), "Failed to delete pod %v in namespace %v", config.Prefix+"-client", config.Namespace) if config.ServerImage != "" { err := e2epod.DeletePodWithWaitByName(cs, config.Prefix+"-server", config.Namespace) gomega.Expect(err).To(gomega.BeNil(), "Failed to delete pod %v in namespace %v", config.Prefix+"-server", config.Namespace) </del> <ins> if config.ServerImage == "" { return </ins> } <ins> err := e2epod.DeletePodWithWaitByName(f.ClientSet, config.Prefix+"-server", config.Namespace) gomega.Expect(err).To(gomega.BeNil(), "Failed to delete pod %v in namespace %v", config.Prefix+"-server", config.Namespace) </ins> } func runVolumeTesterPod(client clientset.Interface, config TestConfig, podSuffix string, privileged bool, fsGroup *int64, tests []Test) (*v1.Pod, error) {


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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 rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in

clientPod, err := runVolumeTesterPod(f.ClientSet, config, "client", false, fsGroup, tests) if err != nil { framework.Failf("Failed to create client pod: %v", err) } <ins> defer func() { e2epod.DeletePodOrFail(f.ClientSet, clientPod.Namespace, clientPod.Name) e2epod.WaitForPodToDisappear(f.ClientSet, clientPod.Namespace, clientPod.Name, labels.Everything(), framework.Poll, framework.PodDeleteTimeout) }() </ins> framework.ExpectNoError(e2epod.WaitForPodRunningInNamespace(f.ClientSet, clientPod)) testVolumeContent(f, clientPod, fsGroup, fsType, tests) }


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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 rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in

}, } volume.TestVolumeClient(f, config, nil, "" /* fsType */, tests) <del> volume.TestCleanup(f, config) </del> } // installFlex installs the driver found at filePath on the node, and restarts


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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 rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in

init() defer func() { <del> volume.TestCleanup(f, convertTestConfig(l.config)) </del> <ins> volume.TestServerCleanup(f, convertTestConfig(l.config)) </ins> cleanup() }()


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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 rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in

import ( "context" "github.com/onsi/ginkgo" v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : In block volume tests, wait for the Pod to be deleted instead of letting it be handled by the framework's namespace deletion Why is this needed: I think the regression caused by could have been caught if the tests check for Pod deletion because the Pod object shouldn't be deleted if TearDown fails.
/assign
This issue is not specific to block tests. We should in ideally wait for pod deletion at the end of all types of tests to confirm cleanup logic is functioning
I checked the tests under test/e2e/storage/testsuites/ where DeletePodWithWait is used to wait for the deletion.
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 rotten is this still an issue? One way to check is to make a breaking change in cleanup and see if the pull job fails.
I went through all block volume usage in e2e tests: All of them but one wait for their pods to be deleted. I'm fixing the remaining test in

Namespace: namespace.Name, Prefix:    "configmap", } <del> defer volume.TestCleanup(f, config) </del> configMap := &v1.ConfigMap{ TypeMeta: metav1.TypeMeta{ Kind:       "ConfigMap",


Question: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:

imagePullTest(image, false, v1.PodPending, true, false) }) <del> ginkgo.It("should not be able to pull non-existing image from gcr.io [NodeConformance]", func() { image := imageutils.GetE2EImage(imageutils.Invalid) imagePullTest(image, false, v1.PodPending, true, false) }) ginkgo.It("should be able to pull image from gcr.io [NodeConformance]", func() { image := imageutils.GetE2EImage(imageutils.DebianBase) isWindows := false if framework.NodeOSDistroIs("windows") { image = imageutils.GetE2EImage(imageutils.WindowsNanoServer) isWindows = true } imagePullTest(image, false, v1.PodRunning, false, isWindows) }) ginkgo.It("should be able to pull image from docker hub [NodeConformance]", func() { image := imageutils.GetE2EImage(imageutils.Alpine) isWindows := false if framework.NodeOSDistroIs("windows") { // TODO(claudiub): Switch to nanoserver image manifest list. image = "e2eteam/busybox:1.29" isWindows = true } imagePullTest(image, false, v1.PodRunning, false, isWindows) </del> <ins> ginkgo.It("should be able to pull image [NodeConformance]", func() { // NOTE(claudiub): The agnhost image is supposed to work on both Linux and Windows. image := imageutils.GetE2EImage(imageutils.Agnhost) imagePullTest(image, false, v1.PodRunning, false, false) </ins> }) ginkgo.It("should not be able to pull from private registry without secret [NodeConformance]", func() {


Question: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:

const ( // Agnhost image Agnhost = iota <del> // Alpine image Alpine </del> // APIServer image APIServer // AppArmorLoader image


Question: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:

CudaVectorAdd2 // Dnsutils image Dnsutils <del> // DebianBase image DebianBase </del> // EchoServer image EchoServer // Etcd image


Question: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:

Httpd // HttpdNew image HttpdNew <del> // Invalid image Invalid </del> // InvalidRegistryImage image InvalidRegistryImage // IpcUtils image


Question: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:

VolumeGlusterServer // VolumeRBDServer image VolumeRBDServer <del> // WindowsNanoServer image WindowsNanoServer </del> ) func initImageConfigs() map[int]Config { configs := map[int]Config{} configs[Agnhost] = Config{e2eRegistry, "agnhost", "2.6"} <del> configs[Alpine] = Config{dockerLibraryRegistry, "alpine", "3.7"} </del> configs[AuthenticatedAlpine] = Config{gcAuthenticatedRegistry, "alpine", "3.7"} configs[AuthenticatedWindowsNanoServer] = Config{gcAuthenticatedRegistry, "windows-nanoserver", "v1"} configs[APIServer] = Config{e2eRegistry, "sample-apiserver", "1.10"}


Question: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:

configs[CudaVectorAdd] = Config{e2eRegistry, "cuda-vector-add", "1.0"} configs[CudaVectorAdd2] = Config{e2eRegistry, "cuda-vector-add", "2.0"} configs[Dnsutils] = Config{e2eRegistry, "dnsutils", "1.1"} <del> configs[DebianBase] = Config{googleContainerRegistry, "debian-base", "0.4.1"} </del> configs[EchoServer] = Config{e2eRegistry, "echoserver", "2.2"} configs[Etcd] = Config{gcRegistry, "etcd", "3.3.15"} configs[GBFrontend] = Config{sampleRegistry, "gb-frontend", "v6"} configs[GlusterDynamicProvisioner] = Config{dockerGluster, "glusterdynamic-provisioner", "v1.0"} configs[Httpd] = Config{dockerLibraryRegistry, "httpd", "2.4.38-alpine"} configs[HttpdNew] = Config{dockerLibraryRegistry, "httpd", "2.4.39-alpine"} <del> configs[Invalid] = Config{gcRegistry, "invalid-image", "invalid-tag"} </del> configs[InvalidRegistryImage] = Config{invalidRegistry, "alpine", "3.1"} configs[IpcUtils] = Config{e2eRegistry, "ipc-utils", "1.0"} configs[JessieDnsutils] = Config{e2eRegistry, "jessie-dnsutils", "1.0"}


Question: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:

configs[VolumeISCSIServer] = Config{e2eRegistry, "volume/iscsi", "2.0"} configs[VolumeGlusterServer] = Config{e2eRegistry, "volume/gluster", "1.0"} configs[VolumeRBDServer] = Config{e2eRegistry, "volume/rbd", "1.0.1"} <del> configs[WindowsNanoServer] = Config{e2eRegistry, "windows-nanoserver", "v1"} </del> return configs }


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track number of scheduler binding goroutines. This will be a generic metric with as the only label for now. metric name Description -- -- scheduler_goroutines Number of running binding goroutines Why is this needed: Helps us track how many binding are running and monitor issues such as goroutine leak. /sig scheduling
/assign

if priorityConfigs[i].Function != nil { wg.Add(1) go func(index int) { <del> defer wg.Done() </del> <ins> metrics.SchedulerGoroutines.WithLabelValues("prioritizing_legacy").Inc() defer func() { metrics.SchedulerGoroutines.WithLabelValues("prioritizing_legacy").Dec() wg.Done() }() </ins> var err error results[index], err = priorityConfigs[index].Function(pod, nodeNameToInfo, nodes) if err != nil {


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track number of scheduler binding goroutines. This will be a generic metric with as the only label for now. metric name Description -- -- scheduler_goroutines Number of running binding goroutines Why is this needed: Helps us track how many binding are running and monitor issues such as goroutine leak. /sig scheduling
/assign

} wg.Add(1) go func(index int) { <del> defer wg.Done() </del> <ins> metrics.SchedulerGoroutines.WithLabelValues("prioritizing_mapreduce").Inc() defer func() { metrics.SchedulerGoroutines.WithLabelValues("prioritizing_mapreduce").Dec() wg.Done() }() </ins> if err := priorityConfigs[index].Reduce(pod, meta, nodeNameToInfo, results[index]); err != nil { appendError(err) }


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track number of scheduler binding goroutines. This will be a generic metric with as the only label for now. metric name Description -- -- scheduler_goroutines Number of running binding goroutines Why is this needed: Helps us track how many binding are running and monitor issues such as goroutine leak. /sig scheduling
/assign

} wg.Add(1) go func(extIndex int) { <del> defer wg.Done() </del> <ins> metrics.SchedulerGoroutines.WithLabelValues("prioritizing_extender").Inc() defer func() { metrics.SchedulerGoroutines.WithLabelValues("prioritizing_extender").Dec() wg.Done() }() </ins> prioritizedList, weight, err := extenders[extIndex].Prioritize(pod, nodes) if err != nil { // Prioritization errors from extender can be ignored, let k8s/other extenders determine the priorities


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track number of scheduler binding goroutines. This will be a generic metric with as the only label for now. metric name Description -- -- scheduler_goroutines Number of running binding goroutines Why is this needed: Helps us track how many binding are running and monitor issues such as goroutine leak. /sig scheduling
/assign

Help:           "Total preemption attempts in the cluster till now", StabilityLevel: metrics.ALPHA, }) pendingPods = metrics.NewGaugeVec( &metrics.GaugeOpts{ Subsystem:      SchedulerSubsystem,


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track number of scheduler binding goroutines. This will be a generic metric with as the only label for now. metric name Description -- -- scheduler_goroutines Number of running binding goroutines Why is this needed: Helps us track how many binding are running and monitor issues such as goroutine leak. /sig scheduling
/assign

Help:           "Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulableQ.", StabilityLevel: metrics.ALPHA, }, []string{"queue"}) <ins> SchedulerGoroutines = metrics.NewGaugeVec( &metrics.GaugeOpts{ Subsystem:      SchedulerSubsystem, Name:           "scheduler_goroutines", Help:           "Number of running goroutines split by the work they do such as binding.", StabilityLevel: metrics.ALPHA, }, []string{"work"}) </ins> PodSchedulingDuration = metrics.NewHistogram( &metrics.HistogramOpts{


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track number of scheduler binding goroutines. This will be a generic metric with as the only label for now. metric name Description -- -- scheduler_goroutines Number of running binding goroutines Why is this needed: Helps us track how many binding are running and monitor issues such as goroutine leak. /sig scheduling
/assign

PodSchedulingAttempts, FrameworkExtensionPointDuration, SchedulerQueueIncomingPods, <ins> SchedulerGoroutines, </ins> } )


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a metric to track number of scheduler binding goroutines. This will be a generic metric with as the only label for now. metric name Description -- -- scheduler_goroutines Number of running binding goroutines Why is this needed: Helps us track how many binding are running and monitor issues such as goroutine leak. /sig scheduling
/assign

} // bind the pod to its host asynchronously (we can do this b/c of the assumption step above). go func() { <ins> metrics.SchedulerGoroutines.WithLabelValues("binding").Inc() defer metrics.SchedulerGoroutines.WithLabelValues("binding").Dec() </ins> // Bind volumes first before Pod if !allBound { err := sched.bindVolumes(assumedPod)


Question:
In order to initialize a client-go , you need an . and friends initialize a new : launches a goroutine: This goroutine is stoppable with . However, the interface returned above does not expose anything that calls that shutdown method, AFAICT. This means that that goroutine cannot ever be cleaned up. That's not great. It's fine if you're using in like k/k does and never stopping anything, but if you ever want to stop your controllers and start up new ones, it becomes an issue. Tested/tracked down against master (as of ). /sig apimachinery /kind bug
The label(s) cannot be applied. These labels are supported: <detailsIn response to : In order to initialize a client-go , you need an . and friends initialize a new : /kind bug </details
/sig api-machinery I always forget the dash

} } <ins> func (e *eventBroadcasterImpl) Shutdown() { e.Broadcaster.Shutdown() } </ins> // refreshExistingEventSeries refresh events TTL func (e *eventBroadcasterImpl) refreshExistingEventSeries() { // TODO: Investigate whether lock contention won't be a problem


Question:
In order to initialize a client-go , you need an . and friends initialize a new : launches a goroutine: This goroutine is stoppable with . However, the interface returned above does not expose anything that calls that shutdown method, AFAICT. This means that that goroutine cannot ever be cleaned up. That's not great. It's fine if you're using in like k/k does and never stopping anything, but if you ever want to stop your controllers and start up new ones, it becomes an issue. Tested/tracked down against master (as of ). /sig apimachinery /kind bug
The label(s) cannot be applied. These labels are supported: <detailsIn response to : In order to initialize a client-go , you need an . and friends initialize a new : /kind bug </details
/sig api-machinery I always forget the dash

// NOTE: events received on your eventHandler should be copied before being used. // TODO: figure out if this can be removed. StartEventWatcher(eventHandler func(event runtime.Object)) func() <ins> // Shutdown shuts down the broadcaster Shutdown() </ins> } // EventSink knows how to store events (client-go implements it.)


Question:
In order to initialize a client-go , you need an . and friends initialize a new : launches a goroutine: This goroutine is stoppable with . However, the interface returned above does not expose anything that calls that shutdown method, AFAICT. This means that that goroutine cannot ever be cleaned up. That's not great. It's fine if you're using in like k/k does and never stopping anything, but if you ever want to stop your controllers and start up new ones, it becomes an issue. Tested/tracked down against master (as of ). /sig apimachinery /kind bug
The label(s) cannot be applied. These labels are supported: <detailsIn response to : In order to initialize a client-go , you need an . and friends initialize a new : /kind bug </details
/sig api-machinery I always forget the dash

// NewRecorder returns an EventRecorder that can be used to send events to this EventBroadcaster // with the event source set to the given event source. NewRecorder(scheme *runtime.Scheme, source v1.EventSource) EventRecorder <ins> // Shutdown shuts down the broadcaster Shutdown() </ins> } // Creates a new event broadcaster.


Question:
In order to initialize a client-go , you need an . and friends initialize a new : launches a goroutine: This goroutine is stoppable with . However, the interface returned above does not expose anything that calls that shutdown method, AFAICT. This means that that goroutine cannot ever be cleaned up. That's not great. It's fine if you're using in like k/k does and never stopping anything, but if you ever want to stop your controllers and start up new ones, it becomes an issue. Tested/tracked down against master (as of ). /sig apimachinery /kind bug
The label(s) cannot be applied. These labels are supported: <detailsIn response to : In order to initialize a client-go , you need an . and friends initialize a new : /kind bug </details
/sig api-machinery I always forget the dash

}) } <ins> func (e *eventBroadcasterImpl) Shutdown() { e.Broadcaster.Shutdown() } </ins> func recordToSink(sink EventSink, event *v1.Event, eventCorrelator *EventCorrelator, sleepDuration time.Duration) { // Make a copy before modification, because there could be multiple listeners. // Events are safe to copy like this.


Question:
A significant number of the of are commented out, possibly was done by mistake in the past. I uncommented the tests to see if they pass, but one of them failed. What we need is to uncomment those tests, fix the one that is not passing and remove the redundant ones if there are any. /sig scheduling /help
/assign I will be moving some of the tests to unit tests and leave a cleaner set of integration tests.
/remove-help
would you like to take this? I can provide guidance.
/help /unassign
/assign
/remove-help

cs := context.clientSet podLabel := map[string]string{"service": "securityscan"} <del> // podLabel2 := map[string]string{"security": "S1"} </del> <ins> podLabel2 := map[string]string{"security": "S1"} </ins> tests := []struct { pod       *v1.Pod


Question:
A significant number of the of are commented out, possibly was done by mistake in the past. I uncommented the tests to see if they pass, but one of them failed. What we need is to uncomment those tests, fix the one that is not passing and remove the redundant ones if there are any. /sig scheduling /help
/assign I will be moving some of the tests to unit tests and leave a cleaner set of integration tests.
/remove-help
would you like to take this? I can provide guidance.
/help /unassign
/assign
/remove-help

errorType string test      string }{ <del> /*{ </del> <ins> { </ins> pod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:   "fakename",


Question:
A significant number of the of are commented out, possibly was done by mistake in the past. I uncommented the tests to see if they pass, but one of them failed. What we need is to uncomment those tests, fix the one that is not passing and remove the redundant ones if there are any. /sig scheduling /help
/assign I will be moving some of the tests to unit tests and leave a cleaner set of integration tests.
/remove-help
would you like to take this? I can provide guidance.
/help /unassign
/assign
/remove-help

{ Key:      "security", Operator: metav1.LabelSelectorOpDoesNotExist, <del> Values:   []string{"securityscan"}, </del> }, }, },


Question:
A significant number of the of are commented out, possibly was done by mistake in the past. I uncommented the tests to see if they pass, but one of them failed. What we need is to uncomment those tests, fix the one that is not passing and remove the redundant ones if there are any. /sig scheduling /help
/assign I will be moving some of the tests to unit tests and leave a cleaner set of integration tests.
/remove-help
would you like to take this? I can provide guidance.
/help /unassign
/assign
/remove-help

node: nodes[0], fits: false, test: "satisfies the PodAffinity but doesn't satisfies the PodAntiAffinity with the existing pod", <del> },*/ </del> <ins> }, </ins> { pod: &v1.Pod{ ObjectMeta: metav1.ObjectMeta{


Question:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: 18 Oct 13:17 PDT Testgrid link: https://k8s- Reason for failure: check
/sig network /cc /cc
/priority critical-urgent /milestone v1.17
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
I believe this is caused by this merge cc.
Most of this is caused by and should be fixed by . Is there any way to run these tests against that PR? /remove-triage unresolved
The job is still failing. Can you check?
/reopen
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
/triage unresolved
OK, fixed some of the tests, got the rest to the point where they failed differently...
Thanks for the update. In testgrid we still see the same error. We will keep observing the next runs.
- still failing. This time the error is We probably need to clean up sanityChecks a bit more - this seems to be a similar issue.
yeah, I'll temporarily un- the tests in my next PR so I can make sure they're actually fixed this time
After the last fix, it seemed to finally recover.

} // sanityCheckService performs sanity checks on the given service; in particular, ensuring <del> // that creating/updating a service allocates IPs, ports, etc, as needed. </del> <ins> // that creating/updating a service allocates IPs, ports, etc, as needed. It does not // check for ingress assignment as that happens asynchronously after the Service is created. </ins> func (j *TestJig) sanityCheckService(svc *v1.Service, svcType v1.ServiceType) (*v1.Service, error) { if svcType == "" { svcType = v1.ServiceTypeClusterIP


Question:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: 18 Oct 13:17 PDT Testgrid link: https://k8s- Reason for failure: check
/sig network /cc /cc
/priority critical-urgent /milestone v1.17
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
I believe this is caused by this merge cc.
Most of this is caused by and should be fixed by . Is there any way to run these tests against that PR? /remove-triage unresolved
The job is still failing. Can you check?
/reopen
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
/triage unresolved
OK, fixed some of the tests, got the rest to the point where they failed differently...
Thanks for the update. In testgrid we still see the same error. We will keep observing the next runs.
- still failing. This time the error is We probably need to clean up sanityChecks a bit more - this seems to be a similar issue.
yeah, I'll temporarily un- the tests in my next PR so I can make sure they're actually fixed this time
After the last fix, it seemed to finally recover.

} } } <del> expectIngress := false if svcType == v1.ServiceTypeLoadBalancer { expectIngress = true } hasIngress := len(svc.Status.LoadBalancer.Ingress) != 0 if hasIngress != expectIngress { return nil, fmt.Errorf("unexpected number of Status.LoadBalancer.Ingress (%d) for service", len(svc.Status.LoadBalancer.Ingress)) } if hasIngress { for i, ing := range svc.Status.LoadBalancer.Ingress { if ing.IP == "" && ing.Hostname == "" { return nil, fmt.Errorf("unexpected Status.LoadBalancer.Ingress[%d] for service: %#v", i, ing) } </del> <ins> if svcType != v1.ServiceTypeLoadBalancer { if len(svc.Status.LoadBalancer.Ingress) != 0 { return nil, fmt.Errorf("unexpected Status.LoadBalancer.Ingress on non-LoadBalancer service") </ins> } }


Question:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: 18 Oct 13:17 PDT Testgrid link: https://k8s- Reason for failure: check
/sig network /cc /cc
/priority critical-urgent /milestone v1.17
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
I believe this is caused by this merge cc.
Most of this is caused by and should be fixed by . Is there any way to run these tests against that PR? /remove-triage unresolved
The job is still failing. Can you check?
/reopen
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
/triage unresolved
OK, fixed some of the tests, got the rest to the point where they failed differently...
Thanks for the update. In testgrid we still see the same error. We will keep observing the next runs.
- still failing. This time the error is We probably need to clean up sanityChecks a bit more - this seems to be a similar issue.
yeah, I'll temporarily un- the tests in my next PR so I can make sure they're actually fixed this time
After the last fix, it seemed to finally recover.

if err != nil { return nil, err } <ins> for i, ing := range service.Status.LoadBalancer.Ingress { if ing.IP == "" && ing.Hostname == "" { return nil, fmt.Errorf("unexpected Status.LoadBalancer.Ingress[%d] for service: %#v", i, ing) } } </ins> return j.sanityCheckService(service, v1.ServiceTypeLoadBalancer) }


Question:
What happened: During the work for reducing invalid dependencies from the e2e core framework to subpackages of the core framework, we found a lot of particular test specific functions. That means these each function is used at a single e2e test module only. These functions are unnecessary to be shared as e2e framework function, so we've just moved these functions to the particular test module like This cleanup work will help us to maintain the e2e core framework in long term, so it is helpful to share this work in volunteers as a community. This issue is for tracking this working items. How to do that?: volunteer selects a single file which is empty (no PR, no assignee) from the following e2e core framework all functions in the file all callers of each function finding the function is called at a single e2e test package only, let's move the function to the module with a PR Implementation rules: If a function is called from 2+ test packages, don't move the function from the core package. If moving of the function requires invalid code dependencies, don't move the function. (Dependency from e2e core framework to other repository) List of files of e2e core framework: [x] ( ) [x] () [x] ( [x] () [x] [x] () [x] get-kubemark-resource- [x] ( ) [x] (Done) [x] ( ) [x] () [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] () [x] ( ) [x] () [x] () References: This working item was under discussion as
/kind cleanup /remove-kind bug /area e2e-test-framework /sig testing /priority important-longterm
Thanks for taking care of this quickly :-)
The proposed policy to follow for what methods are to be kept within the framework: What do you think ? does that sound good?
Thanks for bring it up here. As I said on the slack, I agree with his idea.
I looked through files , and , and found some of the functions are used in a single module. Then fixed them.
i will pick up
I will pick
I will pick up
/assign I will pick
i will pick and
I will pick up ,,,
The PR for is already created by . Please check what other people picked already before posting a PR.
is already picked/posted by
That is a nice point. I wrote point as one of the above Implementation Rules, and another rule comes from which adds another invalid dependency.
I didn't noticed that already picked by , sorry about that. After looking around, there is noting need to do with: ,,,,(not picked). I will pick the left: . Found that is also no need to move, is the same.
Thanks for your investigation, I've updated the above list based on your input :-)
I think is does not need to be modified, Cloud you please help me confirm it?
and
There is noting need to do with , and I have filed a PR for
Thanks for your help :-) I've updated the above list based on your input.
Thank you also, I approved the PR and updated the above list from your work.
and do not need to be modified. Could you help me confirm it? THX.
I think there is noting need to do with
Thanks for your work, I've updated the above list based on your input.
I checked but there is no func which is called from less than 2 test packages.
Thanks for your investigation, I've updated the above list based on your input.
Nice!
Yes, thank you so much everyone!! :-)

flags.DurationVar(&nodeKiller.SimulatedDowntime, "node-killer-simulated-downtime", 10*time.Minute, "A delay between node death and recreation") } <del> // RegisterNodeFlags registers flags specific to the node e2e test suite. func RegisterNodeFlags(flags *flag.FlagSet) { // Mark the test as node e2e when node flags are api.Registry. TestContext.NodeE2E = true flags.StringVar(&TestContext.NodeName, "node-name", "", "Name of the node to run tests on.") // TODO(random-liu): Move kubelet start logic out of the test. // TODO(random-liu): Move log fetch logic out of the test. // There are different ways to start kubelet (systemd, initd, docker, manually started etc.) // and manage logs (journald, upstart etc.). // For different situation we need to mount different things into the container, run different commands. // It is hard and unnecessary to deal with the complexity inside the test suite. flags.BoolVar(&TestContext.NodeConformance, "conformance", false, "If true, the test suite will not start kubelet, and fetch system log (kernel, docker, kubelet log etc.) to the report directory.") flags.BoolVar(&TestContext.PrepullImages, "prepull-images", true, "If true, prepull images so image pull failures do not cause test failures.") flags.StringVar(&TestContext.ImageDescription, "image-description", "", "The description of the image which the test will be running on.") flags.StringVar(&TestContext.SystemSpecName, "system-spec-name", "", "The name of the system spec (e.g., gke) that's used in the node e2e test. The system specs are in test/e2e_node/system/specs/. This is used by the test framework to determine which tests to run for validating the system requirements.") flags.Var(cliflag.NewMapStringString(&TestContext.ExtraEnvs), "extra-envs", "The extra environment variables needed for node e2e tests. Format: a list of key=value pairs, e.g., env1=val1,env2=val2") } </del> func createKubeConfig(clientCfg *restclient.Config) *clientcmdapi.Config { clusterNick := "cluster" userNick := "user"


Question:
What happened: During the work for reducing invalid dependencies from the e2e core framework to subpackages of the core framework, we found a lot of particular test specific functions. That means these each function is used at a single e2e test module only. These functions are unnecessary to be shared as e2e framework function, so we've just moved these functions to the particular test module like This cleanup work will help us to maintain the e2e core framework in long term, so it is helpful to share this work in volunteers as a community. This issue is for tracking this working items. How to do that?: volunteer selects a single file which is empty (no PR, no assignee) from the following e2e core framework all functions in the file all callers of each function finding the function is called at a single e2e test package only, let's move the function to the module with a PR Implementation rules: If a function is called from 2+ test packages, don't move the function from the core package. If moving of the function requires invalid code dependencies, don't move the function. (Dependency from e2e core framework to other repository) List of files of e2e core framework: [x] ( ) [x] () [x] ( [x] () [x] [x] () [x] get-kubemark-resource- [x] ( ) [x] (Done) [x] ( ) [x] () [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] () [x] ( ) [x] () [x] () References: This working item was under discussion as
/kind cleanup /remove-kind bug /area e2e-test-framework /sig testing /priority important-longterm
Thanks for taking care of this quickly :-)
The proposed policy to follow for what methods are to be kept within the framework: What do you think ? does that sound good?
Thanks for bring it up here. As I said on the slack, I agree with his idea.
I looked through files , and , and found some of the functions are used in a single module. Then fixed them.
i will pick up
I will pick
I will pick up
/assign I will pick
i will pick and
I will pick up ,,,
The PR for is already created by . Please check what other people picked already before posting a PR.
is already picked/posted by
That is a nice point. I wrote point as one of the above Implementation Rules, and another rule comes from which adds another invalid dependency.
I didn't noticed that already picked by , sorry about that. After looking around, there is noting need to do with: ,,,,(not picked). I will pick the left: . Found that is also no need to move, is the same.
Thanks for your investigation, I've updated the above list based on your input :-)
I think is does not need to be modified, Cloud you please help me confirm it?
and
There is noting need to do with , and I have filed a PR for
Thanks for your help :-) I've updated the above list based on your input.
Thank you also, I approved the PR and updated the above list from your work.
and do not need to be modified. Could you help me confirm it? THX.
I think there is noting need to do with
Thanks for your work, I've updated the above list based on your input.
I checked but there is no func which is called from less than 2 test packages.
Thanks for your investigation, I've updated the above list based on your input.
Nice!
Yes, thank you so much everyone!! :-)

"//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/yaml:go_default_library", "//staging/src/k8s.io/client-go/tools/cache:go_default_library", <ins> "//staging/src/k8s.io/component-base/cli/flag:go_default_library", </ins> "//test/e2e/framework/config:go_default_library", "//test/e2e/framework/kubelet:go_default_library", "//test/e2e/framework/perf:go_default_library",


Question:
What happened: During the work for reducing invalid dependencies from the e2e core framework to subpackages of the core framework, we found a lot of particular test specific functions. That means these each function is used at a single e2e test module only. These functions are unnecessary to be shared as e2e framework function, so we've just moved these functions to the particular test module like This cleanup work will help us to maintain the e2e core framework in long term, so it is helpful to share this work in volunteers as a community. This issue is for tracking this working items. How to do that?: volunteer selects a single file which is empty (no PR, no assignee) from the following e2e core framework all functions in the file all callers of each function finding the function is called at a single e2e test package only, let's move the function to the module with a PR Implementation rules: If a function is called from 2+ test packages, don't move the function from the core package. If moving of the function requires invalid code dependencies, don't move the function. (Dependency from e2e core framework to other repository) List of files of e2e core framework: [x] ( ) [x] () [x] ( [x] () [x] [x] () [x] get-kubemark-resource- [x] ( ) [x] (Done) [x] ( ) [x] () [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] () [x] ( ) [x] () [x] () References: This working item was under discussion as
/kind cleanup /remove-kind bug /area e2e-test-framework /sig testing /priority important-longterm
Thanks for taking care of this quickly :-)
The proposed policy to follow for what methods are to be kept within the framework: What do you think ? does that sound good?
Thanks for bring it up here. As I said on the slack, I agree with his idea.
I looked through files , and , and found some of the functions are used in a single module. Then fixed them.
i will pick up
I will pick
I will pick up
/assign I will pick
i will pick and
I will pick up ,,,
The PR for is already created by . Please check what other people picked already before posting a PR.
is already picked/posted by
That is a nice point. I wrote point as one of the above Implementation Rules, and another rule comes from which adds another invalid dependency.
I didn't noticed that already picked by , sorry about that. After looking around, there is noting need to do with: ,,,,(not picked). I will pick the left: . Found that is also no need to move, is the same.
Thanks for your investigation, I've updated the above list based on your input :-)
I think is does not need to be modified, Cloud you please help me confirm it?
and
There is noting need to do with , and I have filed a PR for
Thanks for your help :-) I've updated the above list based on your input.
Thank you also, I approved the PR and updated the above list from your work.
and do not need to be modified. Could you help me confirm it? THX.
I think there is noting need to do with
Thanks for your work, I've updated the above list based on your input.
I checked but there is no func which is called from less than 2 test packages.
Thanks for your investigation, I've updated the above list based on your input.
Nice!
Yes, thank you so much everyone!! :-)

metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" utilyaml "k8s.io/apimachinery/pkg/util/yaml" clientset "k8s.io/client-go/kubernetes" <ins> cliflag "k8s.io/component-base/cli/flag" </ins> commontest "k8s.io/kubernetes/test/e2e/common" "k8s.io/kubernetes/test/e2e/framework" e2econfig "k8s.io/kubernetes/test/e2e/framework/config"


Question:
What happened: During the work for reducing invalid dependencies from the e2e core framework to subpackages of the core framework, we found a lot of particular test specific functions. That means these each function is used at a single e2e test module only. These functions are unnecessary to be shared as e2e framework function, so we've just moved these functions to the particular test module like This cleanup work will help us to maintain the e2e core framework in long term, so it is helpful to share this work in volunteers as a community. This issue is for tracking this working items. How to do that?: volunteer selects a single file which is empty (no PR, no assignee) from the following e2e core framework all functions in the file all callers of each function finding the function is called at a single e2e test package only, let's move the function to the module with a PR Implementation rules: If a function is called from 2+ test packages, don't move the function from the core package. If moving of the function requires invalid code dependencies, don't move the function. (Dependency from e2e core framework to other repository) List of files of e2e core framework: [x] ( ) [x] () [x] ( [x] () [x] [x] () [x] get-kubemark-resource- [x] ( ) [x] (Done) [x] ( ) [x] () [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] () [x] ( ) [x] () [x] () References: This working item was under discussion as
/kind cleanup /remove-kind bug /area e2e-test-framework /sig testing /priority important-longterm
Thanks for taking care of this quickly :-)
The proposed policy to follow for what methods are to be kept within the framework: What do you think ? does that sound good?
Thanks for bring it up here. As I said on the slack, I agree with his idea.
I looked through files , and , and found some of the functions are used in a single module. Then fixed them.
i will pick up
I will pick
I will pick up
/assign I will pick
i will pick and
I will pick up ,,,
The PR for is already created by . Please check what other people picked already before posting a PR.
is already picked/posted by
That is a nice point. I wrote point as one of the above Implementation Rules, and another rule comes from which adds another invalid dependency.
I didn't noticed that already picked by , sorry about that. After looking around, there is noting need to do with: ,,,,(not picked). I will pick the left: . Found that is also no need to move, is the same.
Thanks for your investigation, I've updated the above list based on your input :-)
I think is does not need to be modified, Cloud you please help me confirm it?
and
There is noting need to do with , and I have filed a PR for
Thanks for your help :-) I've updated the above list based on your input.
Thank you also, I approved the PR and updated the above list from your work.
and do not need to be modified. Could you help me confirm it? THX.
I think there is noting need to do with
Thanks for your work, I've updated the above list based on your input.
I checked but there is no func which is called from less than 2 test packages.
Thanks for your investigation, I've updated the above list based on your input.
Nice!
Yes, thank you so much everyone!! :-)

var systemValidateMode = flag.Bool("system-validate-mode", false, "If true, only run system validation in current process, and not run test.") var systemSpecFile = flag.String("system-spec-file", "", "The name of the system spec file that will be used for node conformance test. If it's unspecified or empty, the default system spec (system.DefaultSysSpec) will be used.") <ins> // registerNodeFlags registers flags specific to the node e2e test suite. func registerNodeFlags(flags *flag.FlagSet) { // Mark the test as node e2e when node flags are api.Registry. framework.TestContext.NodeE2E = true flags.StringVar(&framework.TestContext.NodeName, "node-name", "", "Name of the node to run tests on.") // TODO(random-liu): Move kubelet start logic out of the test. // TODO(random-liu): Move log fetch logic out of the test. // There are different ways to start kubelet (systemd, initd, docker, manually started etc.) // and manage logs (journald, upstart etc.). // For different situation we need to mount different things into the container, run different commands. // It is hard and unnecessary to deal with the complexity inside the test suite. flags.BoolVar(&framework.TestContext.NodeConformance, "conformance", false, "If true, the test suite will not start kubelet, and fetch system log (kernel, docker, kubelet log etc.) to the report directory.") flags.BoolVar(&framework.TestContext.PrepullImages, "prepull-images", true, "If true, prepull images so image pull failures do not cause test failures.") flags.StringVar(&framework.TestContext.ImageDescription, "image-description", "", "The description of the image which the test will be running on.") flags.StringVar(&framework.TestContext.SystemSpecName, "system-spec-name", "", "The name of the system spec (e.g., gke) that's used in the node e2e test. The system specs are in test/e2e_node/system/specs/. This is used by the test framework to determine which tests to run for validating the system requirements.") flags.Var(cliflag.NewMapStringString(&framework.TestContext.ExtraEnvs), "extra-envs", "The extra environment variables needed for node e2e tests. Format: a list of key=value pairs, e.g., env1=val1,env2=val2") } </ins> func init() { // Enable bindata file lookup as fallback. testfiles.AddFileSource(testfiles.BindataFileSource{


Question:
What happened: During the work for reducing invalid dependencies from the e2e core framework to subpackages of the core framework, we found a lot of particular test specific functions. That means these each function is used at a single e2e test module only. These functions are unnecessary to be shared as e2e framework function, so we've just moved these functions to the particular test module like This cleanup work will help us to maintain the e2e core framework in long term, so it is helpful to share this work in volunteers as a community. This issue is for tracking this working items. How to do that?: volunteer selects a single file which is empty (no PR, no assignee) from the following e2e core framework all functions in the file all callers of each function finding the function is called at a single e2e test package only, let's move the function to the module with a PR Implementation rules: If a function is called from 2+ test packages, don't move the function from the core package. If moving of the function requires invalid code dependencies, don't move the function. (Dependency from e2e core framework to other repository) List of files of e2e core framework: [x] ( ) [x] () [x] ( [x] () [x] [x] () [x] get-kubemark-resource- [x] ( ) [x] (Done) [x] ( ) [x] () [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] ( ) [x] () [x] ( ) [x] () [x] () References: This working item was under discussion as
/kind cleanup /remove-kind bug /area e2e-test-framework /sig testing /priority important-longterm
Thanks for taking care of this quickly :-)
The proposed policy to follow for what methods are to be kept within the framework: What do you think ? does that sound good?
Thanks for bring it up here. As I said on the slack, I agree with his idea.
I looked through files , and , and found some of the functions are used in a single module. Then fixed them.
i will pick up
I will pick
I will pick up
/assign I will pick
i will pick and
I will pick up ,,,
The PR for is already created by . Please check what other people picked already before posting a PR.
is already picked/posted by
That is a nice point. I wrote point as one of the above Implementation Rules, and another rule comes from which adds another invalid dependency.
I didn't noticed that already picked by , sorry about that. After looking around, there is noting need to do with: ,,,,(not picked). I will pick the left: . Found that is also no need to move, is the same.
Thanks for your investigation, I've updated the above list based on your input :-)
I think is does not need to be modified, Cloud you please help me confirm it?
and
There is noting need to do with , and I have filed a PR for
Thanks for your help :-) I've updated the above list based on your input.
Thank you also, I approved the PR and updated the above list from your work.
and do not need to be modified. Could you help me confirm it? THX.
I think there is noting need to do with
Thanks for your work, I've updated the above list based on your input.
I checked but there is no func which is called from less than 2 test packages.
Thanks for your investigation, I've updated the above list based on your input.
Nice!
Yes, thank you so much everyone!! :-)

// Copy go flags in TestMain, to ensure go test flags are registered (no longer available in init() as of go1.13) e2econfig.CopyFlags(e2econfig.Flags, flag.CommandLine) framework.RegisterCommonFlags(flag.CommandLine) <del> framework.RegisterNodeFlags(flag.CommandLine) </del> <ins> registerNodeFlags(flag.CommandLine) </ins> pflag.CommandLine.AddGoFlagSet(flag.CommandLine) // Mark the run-services-mode flag as hidden to prevent user from using it. pflag.CommandLine.MarkHidden("run-services-mode")


Question:
Minimal Repro: Create 2 different disks Create 2 Pods each using one of the disks Start both pods on the same node You will notice one of the disks gets ed to a path: , then both disks are ed from to a target path: which is similar but at least uses the pod . Both of these volumes are being treated as the same volume in the Kubelet even though they are definitely not the same volume. Note: it may not be "treated" as the same volume - it may just be that since the paths are the same the following volumes see that the path is already a mountpoint and skip the step. This is the more likely scenario based on observations. The value is the "name" of the inline-volume. These can obviously be the same across different pods - we should actually be placing it in a more unique directory (based off the translated maybe?). /cc
/sig storage
The inline volume example I'm using (ignore the fact that is a complete misnomer): I've confirmed that changing the "name" makes inline volumes work well since there is no longer a collision on the paths
/assign
Alright, problem is sort of twofold: The referred to above for inline-volumes is set here: As we can see from the comment: it is set to the because the in-tree CSI Plugin makes a lot of naming assumptions based on the which for PVC/PVs is the PV name (unique in a cluster). Primarily, during unmount the CSI Plugin tries to from a "well known ": which happens to be some path based on the which for the inline volume is just the ( above). So we run into the problem that if we use the directory is not sufficiently unique for different disks. And if we use something else like then the unmount pathway is unable to find the . I think using is a no-go. So we need to use something sufficiently unique (like ) for the ( above) and fix up some of the other codepaths to either use different "well-known paths" to write to, or to fix up path generation code so they give us the correct locations. I'm also going to check to see whether 's refactor fixes this issue (because it might since it translates things earlier)
OK. Really good news. your refactor in its current state actually fixes this issue if we set the to something unique here: Looks like the early translation is also making the pathway from the "correct" dir for inline migration. So I will create a PR that fixes this issue that should merge after

deps = [ "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/uuid:go_default_library", </ins> "//staging/src/k8s.io/csi-translation-lib/plugins:go_default_library", ], )


Question:
Minimal Repro: Create 2 different disks Create 2 Pods each using one of the disks Start both pods on the same node You will notice one of the disks gets ed to a path: , then both disks are ed from to a target path: which is similar but at least uses the pod . Both of these volumes are being treated as the same volume in the Kubelet even though they are definitely not the same volume. Note: it may not be "treated" as the same volume - it may just be that since the paths are the same the following volumes see that the path is already a mountpoint and skip the step. This is the more likely scenario based on observations. The value is the "name" of the inline-volume. These can obviously be the same across different pods - we should actually be placing it in a more unique directory (based off the translated maybe?). /cc
/sig storage
The inline volume example I'm using (ignore the fact that is a complete misnomer): I've confirmed that changing the "name" makes inline volumes work well since there is no longer a collision on the paths
/assign
Alright, problem is sort of twofold: The referred to above for inline-volumes is set here: As we can see from the comment: it is set to the because the in-tree CSI Plugin makes a lot of naming assumptions based on the which for PVC/PVs is the PV name (unique in a cluster). Primarily, during unmount the CSI Plugin tries to from a "well known ": which happens to be some path based on the which for the inline volume is just the ( above). So we run into the problem that if we use the directory is not sufficiently unique for different disks. And if we use something else like then the unmount pathway is unable to find the . I think using is a no-go. So we need to use something sufficiently unique (like ) for the ( above) and fix up some of the other codepaths to either use different "well-known paths" to write to, or to fix up path generation code so they give us the correct locations. I'm also going to check to see whether 's refactor fixes this issue (because it might since it translates things earlier)
OK. Really good news. your refactor in its current state actually fixes this issue if we set the to something unique here: Looks like the early translation is also making the pathway from the "correct" dir for inline migration. So I will create a PR that fixes this issue that should merge after

github.com/google/gofuzz v1.0.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg= github.com/google/martian v2.1.0+incompatible/go.mod h1:9I4somxYTbIHy5NJKHRl3wXiIaQGbYVAs8BPL6v8lEs= github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc= <ins> github.com/google/uuid v1.1.1 h1:Gkbcsh/GbpXz7lPftLA3P6TYMwjCLYm83jiFQZF/3gY= </ins> github.com/google/uuid v1.1.1/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= github.com/googleapis/gax-go/v2 v2.0.4/go.mod h1:0Wqv26UfaUD9n4G6kQubkQ+KchISgw+vpHVxEJEs9eg= github.com/googleapis/gnostic v0.0.0-20170729233727-0c5108395e2d/go.mod h1:sJBsCZ4ayReDTBIg8b9dl28c5xFWyhBTVRp3pOg5EKY=


Question:
Minimal Repro: Create 2 different disks Create 2 Pods each using one of the disks Start both pods on the same node You will notice one of the disks gets ed to a path: , then both disks are ed from to a target path: which is similar but at least uses the pod . Both of these volumes are being treated as the same volume in the Kubelet even though they are definitely not the same volume. Note: it may not be "treated" as the same volume - it may just be that since the paths are the same the following volumes see that the path is already a mountpoint and skip the step. This is the more likely scenario based on observations. The value is the "name" of the inline-volume. These can obviously be the same across different pods - we should actually be placing it in a more unique directory (based off the translated maybe?). /cc
/sig storage
The inline volume example I'm using (ignore the fact that is a complete misnomer): I've confirmed that changing the "name" makes inline volumes work well since there is no longer a collision on the paths
/assign
Alright, problem is sort of twofold: The referred to above for inline-volumes is set here: As we can see from the comment: it is set to the because the in-tree CSI Plugin makes a lot of naming assumptions based on the which for PVC/PVs is the PV name (unique in a cluster). Primarily, during unmount the CSI Plugin tries to from a "well known ": which happens to be some path based on the which for the inline volume is just the ( above). So we run into the problem that if we use the directory is not sufficiently unique for different disks. And if we use something else like then the unmount pathway is unable to find the . I think using is a no-go. So we need to use something sufficiently unique (like ) for the ( above) and fix up some of the other codepaths to either use different "well-known paths" to write to, or to fix up path generation code so they give us the correct locations. I'm also going to check to see whether 's refactor fixes this issue (because it might since it translates things earlier)
OK. Really good news. your refactor in its current state actually fixes this issue if we set the to something unique here: Looks like the early translation is also making the pathway from the "correct" dir for inline migration. So I will create a PR that fixes this issue that should merge after

} pv := &v1.PersistentVolume{ ObjectMeta: metav1.ObjectMeta{ <del> // A.K.A InnerVolumeSpecName required to match for Unmount Name: volume.Name, </del> <ins> // Must be unique per disk as it is used as the unique part of the // staging path Name: fmt.Sprintf("%s-%s", AWSEBSDriverName, ebsSource.VolumeID), </ins> }, Spec: v1.PersistentVolumeSpec{ PersistentVolumeSource: v1.PersistentVolumeSource{


Question:
Minimal Repro: Create 2 different disks Create 2 Pods each using one of the disks Start both pods on the same node You will notice one of the disks gets ed to a path: , then both disks are ed from to a target path: which is similar but at least uses the pod . Both of these volumes are being treated as the same volume in the Kubelet even though they are definitely not the same volume. Note: it may not be "treated" as the same volume - it may just be that since the paths are the same the following volumes see that the path is already a mountpoint and skip the step. This is the more likely scenario based on observations. The value is the "name" of the inline-volume. These can obviously be the same across different pods - we should actually be placing it in a more unique directory (based off the translated maybe?). /cc
/sig storage
The inline volume example I'm using (ignore the fact that is a complete misnomer): I've confirmed that changing the "name" makes inline volumes work well since there is no longer a collision on the paths
/assign
Alright, problem is sort of twofold: The referred to above for inline-volumes is set here: As we can see from the comment: it is set to the because the in-tree CSI Plugin makes a lot of naming assumptions based on the which for PVC/PVs is the PV name (unique in a cluster). Primarily, during unmount the CSI Plugin tries to from a "well known ": which happens to be some path based on the which for the inline volume is just the ( above). So we run into the problem that if we use the directory is not sufficiently unique for different disks. And if we use something else like then the unmount pathway is unable to find the . I think using is a no-go. So we need to use something sufficiently unique (like ) for the ( above) and fix up some of the other codepaths to either use different "well-known paths" to write to, or to fix up path generation code so they give us the correct locations. I'm also going to check to see whether 's refactor fixes this issue (because it might since it translates things earlier)
OK. Really good news. your refactor in its current state actually fixes this issue if we set the to something unique here: Looks like the early translation is also making the pathway from the "correct" dir for inline migration. So I will create a PR that fixes this issue that should merge after

azureSource := volume.AzureDisk pv := &v1.PersistentVolume{ ObjectMeta: metav1.ObjectMeta{ <del> // A.K.A InnerVolumeSpecName required to match for Unmount Name: volume.Name, </del> <ins> // Must be unique per disk as it is used as the unique part of the // staging path Name: fmt.Sprintf("%s-%s", AzureDiskDriverName, azureSource.DiskName), </ins> }, Spec: v1.PersistentVolumeSpec{ PersistentVolumeSource: v1.PersistentVolumeSource{


Question:
Minimal Repro: Create 2 different disks Create 2 Pods each using one of the disks Start both pods on the same node You will notice one of the disks gets ed to a path: , then both disks are ed from to a target path: which is similar but at least uses the pod . Both of these volumes are being treated as the same volume in the Kubelet even though they are definitely not the same volume. Note: it may not be "treated" as the same volume - it may just be that since the paths are the same the following volumes see that the path is already a mountpoint and skip the step. This is the more likely scenario based on observations. The value is the "name" of the inline-volume. These can obviously be the same across different pods - we should actually be placing it in a more unique directory (based off the translated maybe?). /cc
/sig storage
The inline volume example I'm using (ignore the fact that is a complete misnomer): I've confirmed that changing the "name" makes inline volumes work well since there is no longer a collision on the paths
/assign
Alright, problem is sort of twofold: The referred to above for inline-volumes is set here: As we can see from the comment: it is set to the because the in-tree CSI Plugin makes a lot of naming assumptions based on the which for PVC/PVs is the PV name (unique in a cluster). Primarily, during unmount the CSI Plugin tries to from a "well known ": which happens to be some path based on the which for the inline volume is just the ( above). So we run into the problem that if we use the directory is not sufficiently unique for different disks. And if we use something else like then the unmount pathway is unable to find the . I think using is a no-go. So we need to use something sufficiently unique (like ) for the ( above) and fix up some of the other codepaths to either use different "well-known paths" to write to, or to fix up path generation code so they give us the correct locations. I'm also going to check to see whether 's refactor fixes this issue (because it might since it translates things earlier)
OK. Really good news. your refactor in its current state actually fixes this issue if we set the to something unique here: Looks like the early translation is also making the pathway from the "correct" dir for inline migration. So I will create a PR that fixes this issue that should merge after

pv := &v1.PersistentVolume{ ObjectMeta: metav1.ObjectMeta{ <del> // A.K.A InnerVolumeSpecName required to match for Unmount Name: volume.Name, </del> <ins> // Must be unique per disk as it is used as the unique part of the // staging path Name: fmt.Sprintf("%s-%s", AzureFileDriverName, azureSource.ShareName), </ins> }, Spec: v1.PersistentVolumeSpec{ PersistentVolumeSource: v1.PersistentVolumeSource{