jiebi/CodeConvo huggingface dataset:
Change:
"//pkg/kubelet/apis/config:go_default_library", "//pkg/kubelet/cm/cpuset:go_default_library", "//pkg/kubelet/types:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/validation:go_default_library", "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library",

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 --See for more context. What happened: When you set and , you'd expect container cfs quota period to be . However, unless you also set in the feature flags, the quota value will be silently ignored. What you expected to happen: At least a warning be logged if the feature is not enabled but is set. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node /assign karan
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig node 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:
) var _ = SIGDescribe("[Feature:Windows] Kubelet-Stats [Serial]", func() { <del> f := framework.NewDefaultFramework("kubelet-stats-test-windows") </del> <ins> f := framework.NewDefaultFramework("kubelet-stats-test-windows-serial") </ins> ginkgo.Describe("Kubelet stats collection for Windows nodes", func() { ginkgo.Context("when running 10 pods", func() {

Discussion:
Lets put a metrics CI job in place that isnt . Investigate our test coverage of metrics-server See why our CI jobs dont test metrics-server Confirm that we are doing enough in is a good test, lets make it part of all our containerd jobs by removing the Serial tags
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 windows
/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 : /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
/assign
while were at it make that iterations a non-magic number
while were at it make sure the metrics stats are non-zero , so that we catch regressions turns out we DO run SERIAL jobs in the sig-windows dashboard either we dont collect enough metrics, so the tests pass, or we do, and we dont watch the dashboards :) https://k8s- <-- check the sig-windows dashboard...
this test starts 10 pods on a node at once and run into issues starting 10 pods on a single node when this was run in parallel with other jobs. Maybe we should consider adding a different metrics job that just starts 1-3 pods and does deeper validation of the metrics retruned?
Hey, is this issue still open? I would like to work on this, I am new to open source
We cannot de-serialize the existing metrics job due to its nature. We can however create new test cases that do not need to be run in parallel and do deeper validation of metrics like Jay suggested above. I'm not sure if is still working on the issue. If not feel free to work on this. Thanks!

/unassign
/retitle Add non-serialized metrics tests for Windows
do we have to make an another var _ with [Serial] not included in it and run 3 pods instead of 10 in it. Help needed, am I thinking correct here.
Change:
} client := clientsetfake.NewSimpleClientset() <del> if tt.errOnCreate != nil { client.PrependReactor("create", "configmaps", func(action core.Action) (bool, runtime.Object, error) { return true, nil, tt.errOnCreate }) } </del> // For idempotent test, we check the result of the second call. <del> if err := UploadConfiguration(cfg, client); !tt.updateExisting && (err != nil) != tt.errExpected { t2.Fatalf("UploadConfiguration() error = %v, wantErr %v", err, tt.errExpected) </del> <ins> if err := UploadConfiguration(cfg, client); err != nil { t2.Fatalf("UploadConfiguration() error = %v", err) </ins> } if tt.updateExisting { <del> if tt.errOnUpdate != nil { client.PrependReactor("update", "configmaps", func(action core.Action) (bool, runtime.Object, error) { return true, nil, tt.errOnUpdate }) } if err := UploadConfiguration(cfg, client); (err != nil) != tt.errExpected { </del> <ins> if err := UploadConfiguration(cfg, client); err != nil { </ins> t2.Fatalf("UploadConfiguration() error = %v", err) } }

Discussion:
What happened: Running fails consistently with timeout errors What you expected to happen: Unit tests should complete without any errors. If this was a configuration problem (e.g. unsupported go version), then I should see a meaningful error rather than just a timeout error. How to reproduce it (as minimally and precisely as possible): Run Anything else we need to know?: This issue has been present in my system for months. Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: OS (e.g: ): Ubuntu 20.04 LTS (Focal Fossa) Kernel (e.g. ): Linux desktop 5.4.0-37-generic -Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others: go version go1.13.12 linux/amd64 (snap)
/sig testing
/assign
Issues targeted at the specific problematic packages and responsible SIGs will be more effective in getting this addressed
/remove-sig testing Unless we expect some broad testing change (like reconfiguring go test) this isn't SIG testing. This is SIG storage, node, and cluster lifecycle
/sig node /sig cluster-lifecycle /sig storage tagged the right sigs, though per-package issues are far more likely to drive getting this fixed
fix for cmd/kubeadm/app/phases/uploadconfig:
I'm going to open two more issues for the other two packages and work on them
sounds good, in that case please close this one.
New issues for reconciler and csi packages: ,
Closing. This problem has come up in the past, the solution is to just increase the timeout. I missed this the first time I read the doc.
Change:
} if o.Local || o.DryRun { <del> return o.PrintObject(o.Mapper, info.Object, o.Out) </del> <ins> if err := o.PrintObject(o.Mapper, info.Object, o.Out); err != nil { return err } continue </ins> } obj, err := resource.NewHelper(info.Client, info.Mapping).Patch(info.Namespace, info.Name, types.StrategicMergePatchType, patch.Patch)

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: my yaml: exec kubectl set resources command,just update first object: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cli
/kind bug
/assign
Change:
"readOnly":         "Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false.", "mountPath":        "Path within the container at which the volume should be mounted.  Must not contain ':'.", "subPath":          "Path within the volume from which the container's volume should be mounted. Defaults to "" (volume's root).", <del> "mountPropagation": "mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationHostToContainer is used. This field is alpha in 1.8 and can be reworked or removed in a future release.", </del> <ins> "mountPropagation": "mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationHostToContainer is used. This field is beta in 1.10.", </ins> } func (VolumeMount) SwaggerDoc() map[string]string {

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: Mount propagation feature was moved to beta in PR However the was not updated to reflect that it is now beta: What you expected to happen: Comment reflects feature is beta. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /assign Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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 push a PR for it.
Oops, sorry. thanks for the PR.
oops, missing priority was my fault, moving back into milestone: /priority critical-urgent /remove-priority important-soon
Update to make bot happy: PR is approved and ready to merge
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
defer cc.EventBroadcaster.Shutdown() // Setup healthz checks. <del> var checks []healthz.HealthChecker </del> <ins> var checks, readyzChecks []healthz.HealthChecker </ins> if cc.ComponentConfig.LeaderElection.LeaderElect { checks = append(checks, cc.LeaderElection.WatchDog) <ins> readyzChecks = append(readyzChecks, cc.LeaderElection.WatchDog) </ins> } <ins> readyzChecks = append(readyzChecks, healthz.NewShutdownHealthz(ctx.Done())) </ins> waitingForLeader := make(chan struct{}) isLeader := func() bool {

Discussion:
Quoted from 's Splitting healthz/ into livez/ and readyz/
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
/cc
/sig scheduling
I read all the content of the PR comment and am willing to work on this issue Do we need to continue some discussion for this issue
Hi , thanks for offering your help. But I was working in progress before knowing you can work on this. However, please feel free to contribute the similar issue
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
return fmt.Errorf("failed to listen on %q: %v", endpoint, err) } <del> return f.server.Serve(l) </del> <ins> go f.server.Serve(l) return nil </ins> } // Stop stops the fake remote runtime.

Discussion:
A race condition between fakeremote.Start() is spawned as a goroutine to listen for connections, and its caller assumes that the listener will immediately be ready to accept connections. This leads to intermittent test failures if the caller attempts before the fake remote runtime is ready to listen. The code needs to be refactored so that the fake remote returns from listen, and then spawns the server as a goroutine and returns. This can be reproduced by running the remoteruntimetest in a loop; it fails periodically. Failure can be accelerated by putting a time.Sleep() in fake.Start() immediately before the call to util.CreateListener; the failure is then effectively deterministic. Fix tested by running about 150,000 iterations without observing any failures.
/sig pod
Reference initial issue:
/sig node
Change:
"//pkg/kubelet/apis/cri/testing:go_default_library", "//pkg/kubelet/remote/fake:go_default_library", "//vendor/github.com/stretchr/testify/assert:go_default_library", <ins> "//vendor/github.com/stretchr/testify/require:go_default_library", </ins> ], )

Discussion:
A race condition between fakeremote.Start() is spawned as a goroutine to listen for connections, and its caller assumes that the listener will immediately be ready to accept connections. This leads to intermittent test failures if the caller attempts before the fake remote runtime is ready to listen. The code needs to be refactored so that the fake remote returns from listen, and then spawns the server as a goroutine and returns. This can be reproduced by running the remoteruntimetest in a loop; it fails periodically. Failure can be accelerated by putting a time.Sleep() in fake.Start() immediately before the call to util.CreateListener; the failure is then effectively deterministic. Fix tested by running about 150,000 iterations without observing any failures.
/sig pod
Reference initial issue:
/sig node
Change:
import ( "testing" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/kubernetes/pkg/apis/core"

Discussion:
What happened: A pod that has init container with request for cpu and memory, and containers that make no request for cpu or memory reports a BestEffort QoS class. This is incorrect. What you expected to happen: Containers that make requests independent of lifecycle phase should impact quality of service calculation. Found in 1.12, looks to still be present in 1.14 dev. /cc
/priority important-soon
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
/lifecycle frozen
I think this doesn't work very well with the current cpu manager logic. The problem is that a pod can't now have QoS class Guaranteed if it has init containers which don't have matching requests/limits. This means that normal containers in such a pod don't then get dedicated cpus even though the init containers are long gone when the app containers (with matching requests/limits) are finally started. This is quite non-intuitive. I would propose separating at least Guaranteed class calculation so that the init container resource requests wouldn't affect the calculation. What do you think?
Change:
kube::test::get_object_assert 'pods b -n nsb' "{{${id_field:?}}}" 'b' # apply --prune must prune a kubectl apply --prune --all -f hack/testdata/prune/b.yaml <del> # check wrong pod doesn't exist output_message=$(! kubectl get pods a -n nsb 2>&1 "${kube_flags[@]:?}") kube::test::if_has_string "${output_message}" 'pods "a" not found' # check right pod exists kube::test::get_object_assert 'pods b -n nsb' "{{${id_field:?}}}" 'b' </del> <ins> # check wrong pod doesn't exist and right pod exists kube::test::wait_object_assert 'pods -n nsb' "{{range.items}}{{${id_field:?}}}:{{end}}" 'b:' </ins> # cleanup kubectl delete ns nsb

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: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: /sig cli /cc /milestone v1.20 /prority important-soon
after creating the CRD, before applying the CR, kubectl should wait until includes :
/assign
/assign is this issue related to ?
no, this is simply kubectl trying to apply a CR before the server has made the API available at all
Got it! and I have filed to address this issue.
Still happening:
still happening: looks like the root cause is not related to CRD: I think the message Error from server (NotFound): "myobj" not found is expected, as the CR was not actually created: /reopen
Reopened this issue. <detailsIn response to : still happening: I think the message Error from server (NotFound): "myobj" not found is expected, as the CR was not actually created: 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
yes, the actual error is later: Line 177 succeeds, and the next line fails:
Change:
} func (rdm *resourceDiscoveryManager) addGroupVersionLocked(source Source, groupName string, value apidiscoveryv2beta1.APIVersionDiscovery) { <del> klog.Infof("Adding GroupVersion %s %s to ResourceManager", groupName, value.Version) </del> if rdm.apiGroups == nil { rdm.apiGroups = make(map[groupKey]*apidiscoveryv2beta1.APIGroupDiscovery)

Discussion:
I upgraded k3s from to and noticed a log message is repeated in the I also see this message when deploying a container that uses apiserver aggregation, such as in other distros such as in the api-server log. The message should not repeated in the logs. This causes a nuisance and the logs eventually are rotated. Upgrade kubernetes to and install a container that uses uses apiserver aggregation such as or . For reference the original issue was reported here: <details</details<details</details<details</details<details</details<details</details<details</details
/cc /sig api-machinery The log was in since v1.26.
Thanks for raising this, opened as a potential fix.
/triage accepted
/assign
Change:
f: f, } It("should test privileged pod", func() { <del> hostExecPod := NewHostExecPodSpec(f.Namespace.Name, "hostexec") pod, err := config.getPodClient().Create(hostExecPod) expectNoError(err) config.hostExecPod = pod </del> <ins> config.hostExecPod = LaunchHostExecPod(config.f.Client, config.f.Namespace.Name, "hostexec") </ins> By("Creating a privileged pod") config.createPrivilegedPod()

Discussion:
Test failed with the following error: Expected error: <*errors.errorString | 0xc208509700: { s: "Error running &{/jenkins-master-data/jobs/kubernetes-e2e-gce-parallel/workspace/kubernetes/platforms/linux/amd64/kubectl [kubectl --server=https://104.197.78.129 --kubeconfig=/var/lib/jenkins/jobs/kubernetes-e2e-gce- exec --namespace=e2e-tests-e2e-privilegedpod-lviv7 hostexec -- /bin/sh -c curl -q 'http://10.245.1.19:8080/shell?shellCommand=ip+link+add+dummy1+type+dummy'] [] error: pod hostexec is not running and cannot execute commands; current phase is Pendingn [] 0xc2085241c0 exit status 1 true [0xc208418828 0xc208418848 0xc208418868] [0xc208418828 0xc208418848 0xc208418868] [0xc208418840 0xc208418860] [0x7f0740 0x7f0740] 0xc208340c60}:nCommand stdout:nnstderr:nerror: pod hostexec is not running and cannot execute commands; current phase is Pendingnn", } Error running &{/jenkins-master-data/jobs/kubernetes-e2e-gce-parallel/workspace/kubernetes/platforms/linux/amd64/kubectl [kubectl --server=https://104.197.78.129 --kubeconfig=/var/lib/jenkins/jobs/kubernetes-e2e-gce- exec --namespace=e2e-tests-e2e-privilegedpod-lviv7 hostexec -- /bin/sh -c curl -q 'http://10.245.1.19:8080/shell?shellCommand=ip+link+add+dummy1+type+dummy'] [] error: pod hostexec is not running and cannot execute commands;

current phase is Pending [] 0xc2085241c0 exit status 1 true [0xc208418828 0xc208418848 0xc208418868] [0xc208418828 0xc208418848 0xc208418868] [0xc208418840 0xc208418860] [0x7f0740 0x7f0740] 0xc208340c60}: Command stdout: stderr: error: pod hostexec is not running and cannot execute commands; current phase is Pending not to have occurred
The example failure is here:
This happened again - increasing priority to P0 according to the policy we discussed: The failure is here:
FYI
Yet another example:
Can you point to the publicly visible artifacts for those tests? It's not obvious to me from the description why I was @ mentioned
- I though that you were involved in this test - if not, please ignore that I mentioned you
Another:
I think is the right person to tag.
It looks like the test doesn't wait for the hostexec pod to start running:
Easy fix, I'll take it.
Thanks Jeff.
Change:
"$ref": "#/components/schemas/io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1.WebhookConversion" } ], <del> "description": "webhook describes how to call the conversion webhook. Required when `strategy` is set to `Webhook`." </del> <ins> "description": "webhook describes how to call the conversion webhook. Required when `strategy` is set to `"Webhook"`." </ins> } }, "required": [

Discussion:
Currently we have inconsistency in most of the API where the field name should be used in description so the generated docs match the API fields people actually set. A linter could be for checking To avoid confusing users
/good-first-issue
/triage accepted
/assign
Hey can you provide some more information for this issue
are you still working on this?
Hey feel free to take it. I am unassigning myself
/triage needs-information /remove-good-first-issue
/sig api-machinery
Change:
exit 0 fi <ins> # Ensure we have the right godep version available kube::util::ensure_godep_version </ins> if [[ -z ${TMP_GOPATH:-} ]]; then # Create a nice clean place to put our new godeps _tmpdir="$(mktemp -d -t gopath.XXXXXX)"

Discussion:
Didn't see an issue for this. Godep recently updated its version to v80. This broke several builds that directly godep, grabbing latest. /kind bug cc Example https://k8s- Here are some examples where we grab master:
We have helpers to grab godep. We should use them everywhere.
/cc
/assign