jiebi/CodeConvo huggingface dataset:
Code change:
What would you like to be : Scheduler VolumeBinding plugin reports error when a PVC doesn't exist for example: We need to take a second look at the VolumeBinding plugin and make sure that errors are returned only when there is a system error, not a user error. Why is this needed: To fix the scheduler's error reporting metrics. /sig scheduling /sig storage /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign I'll take a look.
If the PVC object does not exist, the plugin will return status. I guess you mean the plugin will return an error when a referenced PV does not exist? I've created a PR for this:
Thanks! The errors I am seeing are on 1.18 clusters, can we look at 1.18 and try to patch? This is still throwing the scheduler's error metrics off.
sure
I've submitted a patch for the 1.18 release branch:
I guess on the master branch should be reviewed and merged too? cc
hello! the fix you made only apply for 1.18? how about 1.19 and 1.17? thanks!
after the fix on the master branch () is merged, I'll cherry-pick it into the 1.19 branch (the code are almost the same). I'm not sure if it's necessary to fix the 1.17 branch. It's 3 versions behind 1.20.
hi, This is because of this patch: Do you think this fix needs to be cherry-picked into 1.19 and 1.18 branch too?
can you send a patch for 1.19?
ah, here it is
to sum up: master: 1.19: 1.18: and I think this change should be backported to 1.19/1.18 too: I'll send PRs soon.
summary of the issue that an error will be reported instead of UnschedulableAndUnresolvable when PVC not found: master: already implemented, see 1.19: 1.18: can't backport as it does not implement the PreFilter extension point

Related discussion:
text: claimsToBind:     []*v1.PersistentVolumeClaim{}, podVolumesByNode: map[string]*scheduling.PodVolumes{}, }, <del> wantFilterStatus: framework.NewStatus(framework.Error, `could not find v1.PersistentVolume "pv-a"`), </del> <ins> wantFilterStatus: framework.NewStatus(framework.UnschedulableAndUnresolvable, `pvc(s) bound to non-existent pv(s)`), </ins> }, }
Code change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:

Related discussion:
text: deps = [ "//pkg/api/pod:go_default_library", "//pkg/apis/core:go_default_library", <ins> "//staging/src/k8s.io/api/core/v1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/validation/field:go_default_library", ], )
Code change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:

Related discussion:
text: "fmt" "strings" <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/util/validation/field" podutil "k8s.io/kubernetes/pkg/api/pod" api "k8s.io/kubernetes/pkg/apis/core"
Code change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:

Related discussion:
text: allowAnyProfile = true continue } <ins> // With the graduation of seccomp to GA we automatically convert // the deprecated seccomp profile annotation `docker/default` to // `runtime/default`. This means that we now have to automatically // allow `runtime/default` if a user specifies `docker/default` and // vice versa in a PSP. if p == v1.DeprecatedSeccompProfileDockerDefault || p == v1.SeccompProfileRuntimeDefault { allowedProfiles[v1.SeccompProfileRuntimeDefault] = true allowedProfiles[v1.DeprecatedSeccompProfileDockerDefault] = true } </ins> allowedProfiles[p] = true } }
Code change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:

Related discussion:
text: "strings" "testing" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" api "k8s.io/kubernetes/pkg/apis/core" )
Code change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:

Related discussion:
text: allowSpecificLocalhost = map[string]string{ AllowedProfilesAnnotationKey: v1.SeccompLocalhostProfileNamePrefix + "foo", } <ins> allowSpecificDockerDefault = map[string]string{ AllowedProfilesAnnotationKey: v1.DeprecatedSeccompProfileDockerDefault, } allowSpecificRuntimeDefault = map[string]string{ AllowedProfilesAnnotationKey: v1.SeccompProfileRuntimeDefault, } </ins> ) func TestNewStrategy(t *testing.T) {
Code change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:

Related discussion:
text: }, expectedError: "", }, <ins> "docker/default PSP annotation automatically allows runtime/default pods": { pspAnnotations: allowSpecificDockerDefault, podAnnotations: map[string]string{ api.SeccompPodAnnotationKey: v1.SeccompProfileRuntimeDefault, }, expectedError: "", }, "runtime/default PSP annotation automatically allows docker/default pods": { pspAnnotations: allowSpecificRuntimeDefault, podAnnotations: map[string]string{ api.SeccompPodAnnotationKey: v1.DeprecatedSeccompProfileDockerDefault, }, expectedError: "", }, </ins> } for k, v := range tests { pod := &api.Pod{
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: - Also flaking on: Which test(s) are failing: Since when has it been failing: ~Since Oct 21? Testgrid link: CAPG conformance: CAPA conformance: gce cos master default: Reason for failure: Example spyglass link: Anything else we need to know: Triage shows that this is happening across several jobs (not just the ones I listed above) and the spike started happening earlier this week. /sig cli /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Fixed by
This is affecting ppc64le jobs as well.
/remove-kind failing-test /kind flake This is not a continuously failing test, it is instead flaking
/priority critical-urgent the top flake for per /area conformance this is a conformance test, it definitely shouldn't be flaking, and should be demoted if it can't be fixed
/reopen For CI signal to observe before marking as resolved
Reopened this issue. <detailsIn response to : /reopen For CI signal to observe before marking as resolved 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
Last failure 7 days ago 2020-11-03 05:40:32 +0000 UTC
Please review to see if we can close this now.
Let's close this - also looks like it is no longer flaking as well

Related discussion:
text: codename: '[sig-cli] Kubectl client Kubectl server-side dry-run should check if kubectl can dry-run update Pods [Conformance]' description: The command 'kubectl run' must create a pod with the specified image <del> name. After, the command 'kubectl replace --dry-run=server' should update the Pod with the new image name and server-side dry-run enabled. The image name must not change. </del> <ins> name. After, the command 'kubectl patch pod -p {...} --dry-run=server' should update the Pod with the new image name and server-side dry-run enabled. The image name must not change. </ins> release: v1.19 file: test/e2e/kubectl/kubectl.go - testname: Kubectl, version
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: - Also flaking on: Which test(s) are failing: Since when has it been failing: ~Since Oct 21? Testgrid link: CAPG conformance: CAPA conformance: gce cos master default: Reason for failure: Example spyglass link: Anything else we need to know: Triage shows that this is happening across several jobs (not just the ones I listed above) and the spike started happening earlier this week. /sig cli /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Fixed by
This is affecting ppc64le jobs as well.
/remove-kind failing-test /kind flake This is not a continuously failing test, it is instead flaking
/priority critical-urgent the top flake for per /area conformance this is a conformance test, it definitely shouldn't be flaking, and should be demoted if it can't be fixed
/reopen For CI signal to observe before marking as resolved
Reopened this issue. <detailsIn response to : /reopen For CI signal to observe before marking as resolved 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
Last failure 7 days ago 2020-11-03 05:40:32 +0000 UTC
Please review to see if we can close this now.
Let's close this - also looks like it is no longer flaking as well

Related discussion:
text: /* Release: v1.19 Testname: Kubectl, server-side dry-run Pod <del> Description: The command 'kubectl run' must create a pod with the specified image name. After, the command 'kubectl replace --dry-run=server' should update the Pod with the new image name and server-side dry-run enabled. The image name must not change. </del> <ins> Description: The command 'kubectl run' must create a pod with the specified image name. After, the command 'kubectl patch pod -p {...} --dry-run=server' should update the Pod with the new image name and server-side dry-run enabled. The image name must not change. </ins> */ framework.ConformanceIt("should check if kubectl can dry-run update Pods", func() { ginkgo.By("running the image " + httpdImage)
Code change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: - Also flaking on: Which test(s) are failing: Since when has it been failing: ~Since Oct 21? Testgrid link: CAPG conformance: CAPA conformance: gce cos master default: Reason for failure: Example spyglass link: Anything else we need to know: Triage shows that this is happening across several jobs (not just the ones I listed above) and the spike started happening earlier this week. /sig cli /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Fixed by
This is affecting ppc64le jobs as well.
/remove-kind failing-test /kind flake This is not a continuously failing test, it is instead flaking
/priority critical-urgent the top flake for per /area conformance this is a conformance test, it definitely shouldn't be flaking, and should be demoted if it can't be fixed
/reopen For CI signal to observe before marking as resolved
Reopened this issue. <detailsIn response to : /reopen For CI signal to observe before marking as resolved 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
Last failure 7 days ago 2020-11-03 05:40:32 +0000 UTC
Please review to see if we can close this now.
Let's close this - also looks like it is no longer flaking as well

Related discussion:
text: framework.RunKubectlOrDie(ns, "run", podName, "--image="+httpdImage, "--labels=run="+podName) ginkgo.By("replace the image in the pod with server-side dry-run") <del> podJSON := framework.RunKubectlOrDie(ns, "get", "pod", podName, "-o", "json") podJSON = strings.Replace(podJSON, httpdImage, busyboxImage, 1) if !strings.Contains(podJSON, busyboxImage) { framework.Failf("Failed replacing image from %s to %s in:n%sn", httpdImage, busyboxImage, podJSON) } framework.RunKubectlOrDieInput(ns, podJSON, "replace", "-f", "-", "--dry-run=server") </del> <ins> specImage := fmt.Sprintf(`{"spec":{"containers":[{"name": "%s","image": "%s"}]}}`, podName, busyboxImage) framework.RunKubectlOrDie(ns, "patch", "pod", podName, "-p", specImage, "--dry-run=server") </ins> ginkgo.By("verifying the pod " + podName + " has the right image " + httpdImage) pod, err := c.CoreV1().Pods(ns).Get(context.TODO(), podName, metav1.GetOptions{})
Code change:
/sig storage What happened: When you interrupt the e2e storage stress test, namespaced objects are cleaned up, but non-namespaced objects like StorageClasses are not cleaned up. What you expected to happen: Non-namespaced objects like StorageClasses are cleaned up so long as the user doesn't interrupt a second time. How to reproduce it (as minimally and precisely as possible):
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Related discussion:
text: var ( dInfo = driver.GetDriverInfo() cs    clientset.Interface <ins> l     *stressTest </ins> ) <ins> // Check preconditions before setting up namespace via framework below. </ins> ginkgo.BeforeEach(func() { <del> // Check preconditions. </del> if dInfo.StressTestOptions == nil { e2eskipper.Skipf("Driver %s doesn't specify stress test options -- skipping", dInfo.Name) }
Code change:
/sig storage What happened: When you interrupt the e2e storage stress test, namespaced objects are cleaned up, but non-namespaced objects like StorageClasses are not cleaned up. What you expected to happen: Non-namespaced objects like StorageClasses are cleaned up so long as the user doesn't interrupt a second time. How to reproduce it (as minimally and precisely as possible):
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Related discussion:
text: // f must run inside an It or Context callback. f := framework.NewDefaultFramework("stress") <del> init := func() *stressTest { </del> <ins> init := func() { </ins> cs = f.ClientSet <del> l := &stressTest{} </del> <ins> l = &stressTest{} </ins> // Now do the more expensive test initialization. l.config, l.driverCleanup = driver.PrepareTest(f)