jiebi/CodeConvo huggingface dataset:
Change:
}, Type: corev1.SecretTypeBootstrapToken, Data: map[string][]byte{ <del> bootstrapapi.BootstrapTokenIDKey:               []byte(tokenID), </del> <ins> bootstrapapi.BootstrapTokenIDKey:               []byte(validTokenID), </ins> bootstrapapi.BootstrapTokenSecretKey:           []byte("invalid"), bootstrapapi.BootstrapTokenUsageAuthentication: []byte("true"), }, } <ins> tokenExpiredTime := time.Now().Add(-time.Hour).Format(time.RFC3339) </ins> var expiredBootstrapToken = &corev1.Secret{ ObjectMeta: metav1.ObjectMeta{ Namespace: metav1.NamespaceSystem,

Discussion:
Originally tracked at . After fixing "not include test files in import-boss" in , we have a regression here: is using . We need remove dependencies from integration tests to e2e tests again. /assign /sig testing
/sig auth as per the required change
/kind cleanup /area test
It would be helpful to outline an argument as to why this is the case. I can imagine reasons, but none are mentioned here.
Description updated.
/triage accepted /priority backlog /milestone v1.21 This seems a simple enough fix to land (and thank you for doing this) but marking low enough priority to make it clear we may back out and wait for v1.22 if we don't have bandwidth for this
So while I think we should probably do this anyhow I want to note: This issue lists the reasons: we have no intention to stage e2e (there's been much discussion about this since then) we generally don't want anything non-informational (required jobs) running only sometimes anyhow, it's just not reliable Decoupling these seems like a good idea from a purely code-organization perspective, but the reasons in the previous issue are no longer valid.
/milestone v1.22 The PR didn't land in time. At this point I view this as nice to have. Even if it's low impact, let's wait until next release.
Change:
}, expectArgs: []string{ "ginkgobin", "--p", <del> "--focus=", "--skip=[Serial]", </del> <ins> "--focus=", "--skip=[Serial]", </ins> "--noColor=true", "testbin", "--", "--disable-log-dump", "--repo-root=/kubernetes", "--provider=", "--report-dir=", "--kubeconfig=",

Discussion:
What happened: When using sonobuoy to run some community tests, I realized that ginkgo was not invoked properly. More precisely, when invoking sonobuoy like this: I saw the following in the sonobuoy logs: Because I am running the tests in parallel, and sonobuoy does not set , the code defaults to (see ) for , and is set to . This is not the intended regex (should be ) and all the tests are skipped (because all test names have an ). What you expected to happen: should be set to so that only the tests with the "tag" are skipped. How to reproduce it (as minimally and precisely as possible): Use the sonobuoy command provided above. Environment:
I opened a PR for this
/sig testing
Change:
import ( "context" <ins> "encoding/json" </ins> "testing" "time" "github.com/google/go-cmp/cmp" <ins> "github.com/google/go-cmp/cmp/cmpopts" </ins> v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/apimachinery/pkg/util/strategicpatch" </ins> "k8s.io/apimachinery/pkg/util/wait" utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/client-go/informers"

Discussion:
We should enhance the to verify that adding is unit-testable. We originally thought that this would only be possible with finalizers but there looks to be other options. We could follow examples from In podgc, if we discover an orphaned pod (pod on a missing node), we add a DisruptionCondition to the pod. We only test this behavior in the integration tests because we previously rely on finalizers to halt the deletion so we can avoid flaky tests.
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
/kind cleanup /sig apps
/good-first-issue /help
Will take a look /assign
/assign
/help
newbie question please, I couldn't find the file in the codebase or the PRs. Where can I read it?
Working on it now!
/assign
/assign
Has done very good work with this so I’m not sure we will be able to accept other PRs. We are waiting for an approval on the PR
is this issue still open
Is the issue still open or awaiting for the approval on the pr?
/remove help /remove good-first-issue
The issue is waiting for approval. I removed the tags to reflect that is is almost done.
Change:
<-stoppedChan finished := make(chan interface{}) <ins> fakePlugin.Lock() </ins> fakePlugin.UnmountDeviceHook = func(mountPath string) error { // Act: // 3. While a volume is being unmounted, add it back to the desired state of world

Discussion:
Which jobs are flaking: Which test(s) are flaking: periodic-kubernetes-bazel-test-master (xref ) Testgrid link: Reason for failure: Anything else we need to know: to reproduce with : /sig storage
/assign
solved at
still flaking - /reopen
Reopened this issue. <detailsIn response to : still flaking - 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
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
-- No recent failures in the past 2 weeks, are you okay if we close this?
yeah, looks like resolved it /close
Closing this issue. <detailsIn response to : yeah, looks like resolved it 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
it's back not sure if related to this issue but same test with a data race spotted last night looking into filed
Change:
runnningNode: "node-1", }, { <del> name: "nominated node cannot pass all the filters, preemptor should find a different node", nodes: []*nodeConfig{ {name: "node-1", res: defaultNodeRes}, {name: "node-2", res: defaultNodeRes}, }, </del> <ins> name:      "nominated node cannot pass all the filters, preemptor should find a different node", nodeNames: []string{"node-1", "node-2"}, </ins> existingPods: []*v1.Pod{ initPausePod(&pausePodConfig{ <del> Name:      "low-pod1", Namespace: testCtx.NS.Name, </del> <ins> Name:      "low-pod", </ins> Priority:  &lowPriority, Resources: defaultPodRes, NodeName:  "node-1", }), }, pod: initPausePod(&pausePodConfig{ <del> Name:      "preemptor-pod", Namespace: testCtx.NS.Name, Priority:  &highPriority, </del> <ins> Name:     "preemptor-pod1", Priority: &highPriority, </ins> Resources: &v1.ResourceRequirements{Requests: v1.ResourceList{ v1.ResourceCPU:    *resource.NewMilliQuantity(500, resource.DecimalSI), v1.ResourceMemory: *resource.NewQuantity(200, resource.DecimalSI)},

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 --Integration tests are sometimes flaking locally: PreferNominatedNode Once the node gets deleted, the nodelifecycle controller is racing to update pod status and the pod deletion logic is failing causing tests to flake. Ultimately, we call testCtx.CleanUp() which cleans the nodes and the pods involved the test namespace so we are not going to leak any resources. links to appreciated links to specific failures in spyglass appreciated <!-- You can identify the SIG from the "prowjobconfigurl" on the testgrid dashboard for a test --/sig scheduling <!-- Please see the deflaking doc () for more guidance! --/assign
cc Tried addressing it via
/triage accepted thanks!
Change:
"Metric":    gstruct.Ignore(), "Value":     gomega.BeNumerically(">", value), "Timestamp": gstruct.Ignore(), <ins> "Histogram": gstruct.Ignore(), </ins> })) }

Discussion:
There's been a quite a few failures across jobs that query node metrics. The test is Last passing - First failing - appears to point to which is bump in prometheus client library. Possibly related? /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
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
Verified with presubmit that reverting the prometheus client library results in the test passing. Opened PR for revert in
/cc
/assign
thanks for filing this issue! I think seems like a promising fix (thanks ) and there's a fair chance we won't need the revert
ack, thanks for the fix, it seems we can go with that then and hold the revert.
Change:
Weight int32 } <ins> // ExtenderName is a fake plugin name put in UnschedulablePlugins when Extender rejected some Nodes. const ExtenderName = "Extender" </ins> // Diagnosis records the details to diagnose a scheduling failure. type Diagnosis struct { NodeToStatusMap NodeToStatusMap

Discussion:
When Extender filters out some Nodes, we don't set any unschedulable plugins at all. It means Extender is completely ignored during the requeueing process. So, what's happening is: If Extender filters out all Nodes during scheduling, this Pod is soon retried because this Pod doesn't have any plugin name in unschedulable plugins. If Extender filters out some Nodes during scheduling and plugins filter out all other Nodes, this Pod is retried based on plugins' QueueingHint. Even if any cluster events happen and it could change Extender's decision (but not any plugins' decision), this Pod won't be requeued to activeQ/backoffQ. The latter case is serious because it could make Pods being stuck in unschedulable pod pool in 5min. We should have a short-term solution for the latter case. We can requeue Pods, which were rejected by Extender, by any kind of cluster events because we cannot know which events make Pods schedulable. Eventually, this issue makes us wonder how Pods rejected by Extender should be requeued. We cannot implement QHint equivalent in Extenders because it'd be too slow to call Extender every time any cluster events happen. Probably, somehow implementing EventsToRegister equivalent in Extender? Use Extender which does something in Filter. No response master <detailsn/a </details<details</details<details</details<details</details<details</details
/assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling
/reopen We'll close it when all cherry-picks are done.
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
/close Cherry-picks are done.
Change:
volumeMounts: - name: kube-dns-config mountPath: /kube-dns-config <ins> securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true runAsUser: 1001 runAsGroup: 1001 </ins> - name: dnsmasq image: k8s.gcr.io/k8s-dns-dnsmasq-nanny:1.14.13 livenessProbe:

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Apply security best practices for both kube-dns and core-dns. Low hanging fruit: [x] Run as non-root & disallow privilege escalation [x] Run with the default seccomp profile (i.e. ) [x] ReadOnlyRootFilesystem [x] Avoid unnecessary HostPath volumes [x] (n/a) More advanced: [ ] Reduce dependencies in the base image () [ ] Custom seccomp profile [ ] Custom AppArmor profile [x] Drop unneeded capabilities[x] Run as non-root & disallow privilege escalation [x] Run with the default seccomp profile (i.e. ) [x] ReadOnlyRootFilesystem [x] Avoid unnecessary HostPath volumes [x] (n/a) More advanced: [ ] Reduce dependencies in the base image () [ ] Custom seccomp profile [ ] Custom AppArmor profile [x] Drop unneeded capabilities This is based on the long term issue and implemented by PR . Why is this needed: Our system pods should run using security best practices, both to enhance cluster security and serve as examples of best practices to users.
/sig auth /area security
Change:
<ins> /* Copyright 2015 Google Inc. All rights reserved. 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 e2e import ( "fmt" "path" "github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/util" . "github.com/onsi/ginkgo" ) var _ = Describe("emptyDir", func() { var ( c         *client.Client podClient client.PodInterface ) BeforeEach(func() { var err error c, err = loadClient() expectNoError(err) podClient = c.Pods(api.NamespaceDefault) }) It("volume on tmpfs should have the correct mode", func() { volumePath := "/test-volume" source := &api.EmptyDirVolumeSource{ Medium: api.StorageTypeMemory, } pod := testPodWithVolume(volumePath, source) pod.Spec.Containers[0].Args = []string{ fmt.Sprintf("--fs_type=%v", volumePath), fmt.Sprintf("--file_mode=%v", volumePath), } testContainerOutput("emptydir r/w on tmpfs", c, pod, []string{ "mount type of "/test-volume": tmpfs", "mode of file "/test-volume": dtrwxrwxrwx", // we expect the sticky bit (mode flag t) to be set for the dir }) }) It("should support r/w on tmpfs", func() { volumePath := "/test-volume" filePath := path.Join(volumePath, "test-file") source := &api.EmptyDirVolumeSource{ Medium: api.StorageTypeMemory, } pod := testPodWithVolume(volumePath, source) pod.Spec.Containers[0].Args = []string{ fmt.Sprintf("--fs_type=%v", volumePath), fmt.Sprintf("--rw_new_file=%v", filePath), fmt.Sprintf("--file_mode=%v", filePath), } testContainerOutput("emptydir r/w on tmpfs", c, pod, []string{ "mount type of "/test-volume": tmpfs", "mode of file "/test-volume/test-file": -rw-r--r--", "content of file "/test-volume/test-file": mount-tester new file", }) }) }) const containerName = "test-container" const volumeName = "test-volume" func testPodWithVolume(path string, source *api.EmptyDirVolumeSource) *api.Pod { podName := "pod-" + string(util.NewUUID()) return &api.Pod{ TypeMeta: api.TypeMeta{ Kind:       "Pod", APIVersion: "v1beta1", }, ObjectMeta: api.ObjectMeta{ Name: podName, }, Spec: api.PodSpec{ Containers: []api.Container{ { Name:  containerName, Image: "kubernetes/mounttest:0.1", VolumeMounts: []api.VolumeMount{ { Name:      volumeName, MountPath: path, }, }, }, }, Volumes: []api.Volume{ { Name: volumeName, VolumeSource: api.VolumeSource{ EmptyDir: source, }, }, }, }, } } </ins>

Discussion:
I'd like to commit without e2e support so others can unblock. We need to come back to get e2e on this. I could use help, and it seems like an easy test...
Sorry for my incorrect PR. Now I have amend it.
Change:
"strings" "testing" <ins> "github.com/spf13/cobra" </ins> "github.com/stretchr/testify/assert" )

Discussion:
When trying to use kubectl from hyperkube I'm met with "unknown flag" errors. It looks as if the flags aren't being passed through to kubectl but hyperkube is trying to handle them itself (and subsequently giving an error when you give it flags it doesn't understand). You can reproduce simply by running: And you'll see the error:
I have a fix up in PR .
Change:
type defaultFunc func(pod *api.Pod) error func tryDecodeSinglePod(data []byte, defaultFn defaultFunc) (parsed bool, pod *api.Pod, err error) { <del> obj, err := api.Scheme.Decode(data) </del> <ins> // JSON is valid YAML, so this should work for everything. json, err := utilyaml.ToJSON(data) if err != nil { return false, nil, err } obj, err := api.Scheme.Decode(json) </ins> if err != nil { return false, pod, err }

Discussion:
Following on from the Kubelet should accept YAML pod specifications. Currnelty it supports only JSON pod specifications.
Change:
claim := newClaim(t, ns.GetName(), "") class := newStorageClass(t, ns.GetName(), "") <ins> claim.Spec.StorageClassName = &class.ObjectMeta.Name </ins> testDynamicProvisioning(t, cs, claim, class) }) })

Discussion:
Current CSI E2E test has some issues which prevent it to run successfully the a local cluster. /sig storage /kind bug /assign
Change:
"docker_legacy_service.go", "docker_logs.go", "docker_sandbox.go", <del> "docker_sandbox_others.go", "docker_sandbox_windows.go", </del> "docker_service.go", "docker_stats_linux.go", "docker_stats_unsupported.go",

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: is trying to setup DNS for Windows containers, so that Pods on Windows could confirm to dns policies. However, as posted Docker is not managing the networking here for windows. So it doens't really care about any network settings. So passing it to docker shim's hostconfig also doens;t make sense here. DNS for Windows containers will be set by CNI plugins. So PR reverts . This issue tracks the process of pushing DNS configure into CNI and passed that from Kubelet to container runtime. What you expected to happen: Pods on Windows confirm to dns policies. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig windows
Need a linked issue & PR in CNI repo too so that capability arguments can be validated from kubelet
Fixed in by dns capabilities, Azure CNI has already supported this. /close
Closing this issue. <detailsIn response to : Fixed in by dns capabilities, Azure CNI has already supported this. 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
Change:
import ( "context" <ins> "crypto/ecdsa" "crypto/elliptic" "crypto/rand" </ins> "crypto/rsa" "crypto/x509" <ins> "crypto/x509/pkix" "encoding/pem" </ins> "fmt" <ins> "math" "math/big" </ins> "net" "os" "path/filepath"

Discussion:
found this by running tests on this PR: it's problematic for a couple of reasons: prevents kubeadm from moving out (eventually) there are no API guarantees in the given code/structs/functions in pkiutils the logic in cmd/kube- must be reworked to generate cert/key pair without using kubeadm. originally in pending fix PR
/sig api-machinery cluster-lifecycle architecture /area code-organization
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig api-machinery sig-cluster-lifecycle architecture /area code-organization </details
/assign
cc
Please make sure to add an import restriction to prevent a regression in the future.
/triage accepted
Change:
string(api.AzureDedicatedBlobDisk), string(api.AzureManagedDisk)) <del> supportedStorageAccountTypes = sets.NewString("Premium_LRS", "Standard_LRS") </del> <ins> supportedStorageAccountTypes = sets.NewString("Premium_LRS", "Standard_LRS", "Standard_GRS", "Standard_RAGRS") </ins> ) func getPath(uid types.UID, volName string, host volume.VolumeHost) string {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: Now for storage class only support skuName with PremiumLRS and StandardLRS Met error if the storage account was created with other sku. But actually it can work well without setting it What you expected to happen: skuName should support others if the storage account support it How to reproduce it (as minimally and precisely as possible): Create a storage account which is using StandardRAGRS sku. Create storage class as below: Create pvc as below PVC would never bind with below error: Failed to provision volume with StorageClass "scazure": azureDisk - StandardRAGRS is not supported sku/storageaccounttype. Supported values are [PremiumLRS StandardLRS] But if I remove the skuName parameter, the pvc could be bound Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.6+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-12T02:22:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.6+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-12T02:22:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): RHEL7 Install tools: ansible
/assign andyzhangx
/sig azure
thanks, it's a requirement, we should support StandardLRS, StandardZRS, StandardGRS, StandardRGRS, while for premium, it only support Premium_LRS
/kind feature
StandardZRS, PremiumGRS are not supported for azure disk now
Change:
srcs = [ "helpers_test.go", "unstructured_list_test.go", <ins> "unstructured_test.go", </ins> ], embed = [":go_default_library"], deps = [

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