jiebi/CodeConvo huggingface dataset:
Change:
} func TestSearchDisk(t *testing.T) { <del> fakeMounter := fcDiskMounter{ fcDisk: &fcDisk{ </del> <ins> tests := []struct { name        string wwns        []string lun         string expectError bool }{ { name: "PCI disk", </ins> wwns: []string{"500a0981891b8dc5"}, lun:  "0", <del> io:   &fakeIOHandler{}, </del> }, <del> deviceUtil: util.NewDeviceHandler(util.NewIOHandler()), </del> <ins> { name: "Non PCI disk", wwns: []string{"5005076810213b32"}, lun:  "2", }, { name:        "Invalid Storage Controller", wwns:        []string{"5005076810213404"}, lun:         "0", expectError: true, }, { name:        "Non existing disk", wwns:        []string{"500507681fffffff"}, lun:         "0", expectError: true, }, </ins> } <del> devicePath, error := searchDisk(fakeMounter) // if no disk matches input wwn and lun, exit if devicePath == "" || error != nil { t.Errorf("no fc disk found") </del> <ins> for _, test := range tests { t.Run(test.name, func(t *testing.T) { fakeMounter := fcDiskMounter{ fcDisk: &fcDisk{ wwns: test.wwns, lun:  test.lun, io:   &fakeIOHandler{}, }, deviceUtil: util.NewDeviceHandler(util.NewIOHandler()), } devicePath, err := searchDisk(fakeMounter) if test.expectError && err == nil { t.Errorf("expected error but got none") } if !test.expectError && err != nil { t.Errorf("got unexpected error: %s", err) } // if no disk matches input wwn and lun, exit if devicePath == "" && !test.expectError { t.Errorf("no fc disk found") } }) </ins> } }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Currently, we have logic here to look for the disk names with but this fails when we have devices which are starting with e.g: on ppc64le architecture, NPIV based fc disks are discovered as follows: and here is the udev information for one of the disk: Because of the existing logic k8s fails to detect the disk because it does not start with instead starts with , so pod creation fails with the following error: What you expected to happen: FC disk should get attached properly to the pod How to reproduce it (as minimally and precisely as possible): sample pod yaml on a machine with path names starts with Anything else we need to know?: Environment:
/sig storage
/triage accepted
Change:
} } }` <del> // The following images are not added into NodeImageWhiteList, because this test is </del> <ins> // The following images are not added into NodePrePullImageList, because this test is </ins> // testing image pulling, these images don't need to be prepulled. The ImagePullPolicy <del> // is v1.PullAlways, so it won't be blocked by framework image white list check. </del> <ins> // is v1.PullAlways, so it won't be blocked by framework image pre-pull list check. </ins> for _, testCase := range []struct { description string image       string

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should come up with a better name for : Why is this needed: From /sig testing /priority important-soon /cleanup /help /good-first-issue
This request has been marked as suitable for new contributors. 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 : <!-- Please only use this template for submitting enhancement requests --We should come up with a better name for : From /priority important-soon /cleanup /help /good-first-issue 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
I'd like to help out with this. /assign
mind. It seems like you have a PR for it already. /unassign
And I misread the changes you made in . I'm back on this one. /assign
I'm going to rename this to . Please let me know if there are any objections or if there are things that I should be considering.
please feel free to take it. I'm only changing ImageWhileList withint
ultimately was changed to NodePrePullImageList because that's what it's actually used for, not for any sort of filtering.
Change:
<ins> // +build !windows /* Copyright 2019 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package mount import ( "os" "syscall" ) // IsCorruptedMnt return true if err is about corrupted mount point func IsCorruptedMnt(err error) bool { if err == nil { return false } var underlyingError error switch pe := err.(type) { case nil: return false case *os.PathError: underlyingError = pe.Err case *os.LinkError: underlyingError = pe.Err case *os.SyscallError: underlyingError = pe.Err } return underlyingError == syscall.ENOTCONN || underlyingError == syscall.ESTALE || underlyingError == syscall.EIO || underlyingError == syscall.EACCES } </ins>

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: pod with smb(cifs) mount could not be terminated on Windows when that smb account is invalid, the pod will be stuck forever What you expected to happen: How to reproduce it (as minimally and precisely as possible): a pod with azure file mount on Windows the storage account of azure file invalid the pod with azure file mount could not be terminated forever Anything else we need to know?: similar to case: Environment: Kubernetes version (use ): v1.12.6 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /assign /sig windows
Change:
Namespace: namespace.Name, Prefix:    "configmap", } <del> defer volume.TestCleanup(f, config) </del> configMap := &v1.ConfigMap{ TypeMeta: metav1.TypeMeta{ Kind:       "ConfigMap",

Discussion:
<!-- 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
Change:
<ins> reviewers: - lavalamp - smarterclayton - thockin approvers: - lavalamp - smarterclayton - thockin </ins>

Discussion:
/assign /cc Please ensure that every sub directory of / contains an owners file. The following sub directories do not define them: The result of this is that any PR which changes anything in api, Godeps, staging, vendor, etc will always get assigned to one of you for both the review and approval.
I recall someone also mentioning that certain files or dirs may not need approvers files. If that would help, we can add that functionality (i've already started the work)
staging and api should be easy to find owners for. may have ideas for translations. The big one is Godeps, third_party, vendor. Those are just grunt work. And figuring out criteria for approving is hard as they are a lot of code and it is unclear that things are tested well or automatically. (I'm thinking things like libraries for accessing cloud APIs). Having a dedicated team/process there might help.
I'll open some proposals for staging and API.
Godep in particular needs to be watched for things like licenses, which I have mostly been doing.
Thanks Clayton for the staging and api additions! How about if we pick two of you at random and shove them in as owners for each of the remaining directories?
What's left: translations: the kubectl specific translations is being handled by sig-cli, but the rest of the files like README and test have been handled and approved mostly by thirdparty: this is a tricky mix of stuff like forked code.. mostly handled by the likes of or for approvals. Godep/vendor: These could probably be solved by having a process to follow, and then delegating to a team in OWNERSALIASES for both folders.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Still relevant. /remove-lifecycle stale
Change:
maxBudget time.Duration } <del> func newTimeBudget(stopCh <-chan struct{}) *timeBudget { result := &timeBudget{ </del> <ins> func newTimeBudget(stopCh <-chan struct{}) timeBudget { result := &timeBudgetImpl{ </ins> budget:    time.Duration(0), refresh:   refreshPerSecond, maxBudget: maxBudget,

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: bazel-test-master (periodic-kubernetes-bazel-test-master ) Which test(s) are flaking: gotest: Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --cc
/sig api-machinery
This is continuing to be flaky with more recent failure:
/assign Would you mind taking a look here? thanks! /triage accepted
- can we somehow uncover when this started happening? This test is very old and it seems it started happening very recently, so it would be helpful to see when this started happening...
Triage shows flakes starting ~Sept 30: Before Sept 30 it seems the job was flaking much less frequently.
Might be related to I will take a look.
It seems it's not related to that PR (neither to the previous: ) As there were already failures like that on Sep 24th (before this one was merged). I will take a deeper look.
OK - it's not related to any changes mentioned before. I can reproduce this particular failure by simply adding somewhere in this block: So it's probably connected to cpu-starvation at the test level and the solution is to switch to less aggressive timeouts. Will send out a PR.
Actually - it appeared to be slightly more subtle then that. But I already fully understand the problem. It's purely test issue, but require a bit more changes (and I won't get to it today/tomorrow). I will send a fix for that early next week.
- if that changes anything from your tracking perspective ^^
No board changes yet - the next stage is "Observing" once this issue gets closed :) If you have time - I'd love to pick your brain/understand the error more thoroughly though! Hoping you drop a good explanation in your PR next week
Thanks for sharing those insights, on your discovery of the solution to this bug.
It seems the PR didn't address that fully. Looking.
out for review
Change:
// NewBase64Plugin is a constructor for Base64Plugin. func NewBase64Plugin(t testing.TB, socketPath string) *Base64Plugin { <del> server := grpc.NewServer() </del> <ins> server := grpc.NewServer( grpc.UnaryInterceptor( func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) { if val := metadata.ValueFromIncomingContext(ctx, ":authority"); len(val) != 1 || val[0] != "localhost" { t.Errorf("wanted localhost authority, got: %v", val) } return handler(ctx, req) }, ), ) </ins> result := &Base64Plugin{ grpcServer: server, mu:         &sync.Mutex{},

Discussion:
KMS Plugins require communication via grpc UDS. Currently, the k8s grpc client sets the authority header to the socket path which is marked as invalid preventing successful socket communication. I expect a custom KMS provider plugin to be sent valid authority headers so that successful communication can be established between the k8s and grpc client/server. Create a grpc server according to the and attempt to establish socket communication. This issue has been resolved in for device plugins and CSI. The same solution will likely fix this issue as well. I will create a PR for this and link it here after. <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig auth /triage accepted
Change:
SelectorParam("kubernetes.io/cluster-service=true"). ResourceTypeOrNameArgs(false, []string{"services"}...). Latest() <del> b.Do().Visit(func(r *resource.Info, err error) error { </del> <ins> err = b.Do().Visit(func(r *resource.Info, err error) error { </ins> if err != nil { return err }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: reports that the cluster is running and returns exit code 0. correctly identifies that the cluster is not running and exists with exit code 1. What you expected to happen: should fail when the cluster is not running. How to reproduce it (as minimally and precisely as possible): Start and stop a kubernetes cluster using minikube and then type kubectl cluster-info. Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-28T22:57:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-06T20:53:14Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: Local OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux Ubuntu16-HP-800 4.10.0-35-generic ~16.04.1-Ubuntu SMP Wed Sep 13 09:02:42 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: snap for kubectl. minikube local for k8s. Others:
/assign /sig cli
Change:
import ( "errors" "fmt" <ins> "sort" </ins> "sync" "github.com/coreos/go-etcd/etcd"

Discussion:
kubectl returns resources in a random order, which makes it hard to look for things when users have a lot resources. Returning resources in deterministic order should be a helpful and trivial change (hopefully). We have an issue about pagination , but that's a larger and separate issue.
We should be cause to not do this on the * namespace - I think thats a special case. No disagreement for other list calls
What is the default etcd response order? Last created or last modified? Sent from my iPhone
I think the order is by key if sort param is given. If not given, the order is by last created (maybe, but we shouldn't trust it). It seems we are not trying to get sorted result from etcd.
Today, I think it's random order in the child key space in etcd (because the node structure uses a map), so you get golang map iteration order without sort. I don't know if sort on server is any cheaper than sort on client today, so we may want to do this in rest / registry rather than by passing etcd.
Apart from performance, sorting in clients means we can also take control of how responses are sorted, so for * namespace, we can sort by namespace, then by resource ID. , Clayton Coleman wrote: Master of Electrical and Computer Engineering Carnegie Mellon University
We can always hint sort to the registry storage layer in the future, so sorting on the client now won't kill us.
Just took a closer look at our rest/registry code to implement the sort (in client), but implementation-wise, it seems much easier to pass sort to etcd (one line change). Also, namespace is a prefix on resource, so sort across all namespace with etcd key will essentially sort resources by namespace then by Name. If we are to implement sort on client side, we can either: sort package: have each list object, ie.e PodList, ControllerList, implement sort interface. (We won't do this). have ListMeta implement sort interface, if there is a way to find enclosing structs (so we can use items field) have api.Object implement sort interface, verify object is list before sorting. sort algorithm ourself, and do it in rest. Is there other golang or kubernetes idom that I haven't been aware of that can be applied to this use case?

----- Original Message ----- I think sorting it on etcd is fine for now - that's the simplest possible thing that works.
Is there any material perf impact in etcd to enable it? Sent from my iPhone
Probably not material. Can always switch away if necessary
Famous last words :-) Sent from my iPhone
Got my hat ready
Change:
<ins> /* Copyright 2018 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package unstructured import ( "testing" "github.com/stretchr/testify/assert" ) func TestNilUnstructuredContent(t *testing.T) { var u Unstructured uCopy := u.DeepCopy() content := u.UnstructuredContent() expContent := make(map[string]interface{}) assert.EqualValues(t, expContent, content) assert.Equal(t, uCopy, &u) } </ins>

Discussion:
What happened: In I introduced an optimization - do a deep copy instead of to and from JSON roundtrip to convert anything that implements . I then discovered that the method that is used there in both and may mutate the original object. This is problematic because previously (before ) there was no mutation and because this is unexpected and may lead to data races - it is bad behaviour to mutate original object when you just want a copy of it. This issue was fixed by . However the underlying issue is not fixed here - is brittle and dangerous. Method name does not imply that it mutates data when you call it. And godoc does not mention that either: Something needs to be done about it IMO. This method is misused in these places (mutation side effect is not intended): Also implementation in does not implement the behaviour required by godoc in . What you expected to happen: There should be a method that returns the current unstructured contents without mutation and perhaps not providing the write-through effect. /kind bug /sig api-machinery
/cc
Is this still required and could I work on it? I'm looking for something to work on as a new contributor :)
Yes and yes! :)
Perfect, I'll get started on it!
I've got out. I'd appreciate a review :)
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
Change:
pv.Spec.AccessModes = r.plugin.GetAccessModes() } <del> return pv, os.MkdirAll(pv.Spec.HostPath.Path, 0750) </del> <ins> if err := os.MkdirAll(pv.Spec.HostPath.Path, 0750); err != nil { return nil, err } if selinux.GetEnabled() { err := selinux.SetFileLabel(pv.Spec.HostPath.Path, config.KubeletContainersSharedSELinuxLabel) if err != nil { return nil, fmt.Errorf("failed to set selinux label for %q: %v", pv.Spec.HostPath.Path, err) } } return pv, nil </ins> } // hostPathDeleter deletes a hostPath PV from the cluster.

Discussion:
crio-e2e tests The following tests fail when run on a node with SELinux enabled: Probably since these tests were . No response The host path volumes created under /tmp/hostpathpv don't have the right SELinux label set for access by containers started during the test. No response_ /sig node
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
BASH_TARGETS=" update-generated-protobuf update-codegen <ins> update-generated-runtime update-generated-device-plugin </ins> update-generated-docs update-generated-swagger-docs update-swagger-spec

Discussion:
Happy New Year! Now when I run make I get a diff like this in every zz_generated file: Not sure what a smart solution is, but we could merge something like in the meantime.
Change:
t.Fatal("New DS has the same UID as the old one!") } <del> err = wait.PollImmediate(100*time.Millisecond, informerSyncTimeout, func() (bool, error) { klog.V(8).Infof("Waiting for queue to have 1 item, currently has: %d", dsc.queue.Len()) return dsc.queue.Len() == 1, nil }) if err != nil { t.Fatalf("Re-creating DS didn't result in new item in the queue: %v", err) } </del> <ins> waitForQueueLength(1, "recreated DS") </ins> ok = dsc.processNextWorkItem() if !ok { t.Fatal("Queue is shutting down!")

Discussion:
Which jobs are failing: TestExpectationsOnRecreate unit test, in along with expectations bugfix during 1.19 and cherry-picked to 1.18/1.17 Which test(s) are failing: Reason for failure: Anything else we need to know: These failures are masked in CI because bazel test runs with flake retries (), so the test can fail 2/3 times and the job can still pass (cc
adding to the milestone for triage, in case this is a real bug and not just a test issue /milestone v1.19
cc
/assign
looks like the panic is due to the test continuing in the !exists case (rather than exiting with a Fatal): however, that still means the test is failing in three distinct places:
it looks like the same failure existed in 1.18, so this probably isn't release blocking, but it does need to be resolved in order for us to stop ignoring unit test flakes in CI runs
it actually looks like this test was during the 1.19 dev cycle and cherry-picked back to 1.18/1.17, which is why release-1.18 is failing :-/
figured it out... the controller sync is updating the DS, which is triggering an update event and adding an extra enqueue which the test did not account for good news is that it appears to be a test-only issue
possible test deflake in