jiebi/CodeConvo huggingface dataset:
Code change:
"k8s.io/kubernetes/pkg/controlplane" "k8s.io/kubernetes/pkg/features" "k8s.io/kubernetes/test/integration/framework" <ins> "k8s.io/utils/ptr" </ins> ) const (

Related discussion:
text: My application is clustered and I have 2 pods running. I am using a rolling upgrade strategy and my partitioning number is 1. First I need to upgrade the pod with the ordinal number 1 so I triggered that upgrade with partitioning number 1 and my upgrade gets completed. After this, my pod having the ordinal number 0 gets restarted and it's automatically upgraded to a new image. This is not an expected behavior because still, my partition number is 1 and pod-0 should come up with an older image only. I am facing this issue for the v1.27 cluster. Prior to this, it was working fine. pod-0 should not upgrade to new image until I upgrade the partition number to 0.a Do helm install and upgrade pod-1 only keeping partition number to 1. No response <detailsconsole $ cat /etc/os-release $ uname -a C:wmic os get Caption, Version, BuildNumber, OSArchitecture </details<details</details<details</details<details</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
/sig/api-machinery
/sig apps /sig storage
Hi, Can someone suggest here? As this is introduced in my setup after the v1.27 upgrade? Is there any change in partition logic?
This can be reproduced by using the said STS. 1 - Deploy STS using attached that has a replica count is 2 and updatingstrategy.rolling.partition as 1. 2 - Do edit STS and update the image to 1.15. This will upgrade, pod-1 with image 1.15. 3 - Next delete the pod pod-0 and check that POD-0 came up with a new image which is not the expected behavior. POD 0 should not be updated to a new image until the partition is changed to 0. We have noticed this behavior change in v1.27.
Code change:
"k8s.io/kubernetes/pkg/controlplane" "k8s.io/kubernetes/pkg/features" "k8s.io/kubernetes/test/integration/framework" <ins> "k8s.io/utils/ptr" </ins> ) const (

Related discussion:
text: Pla suggest : apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: port: 80 name: web clusterIP: None selector: app: nginx apiVersion: apps/v1 kind: StatefulSet metadata: name: web-am spec: updateStrategy: type: RollingUpdate rollingUpdate: partition: 1 serviceName: "nginx" replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: name: nginx args: /bin/sh -c sleep 30;touch /tmp/healthy; sleep 3600 image: nginx:1.14.2 ports: containerPort: 80 name: web
Code change:
// If "only_cpu_and_memory" GET param is true then only cpu and memory is returned in response. func (h *handler) handleSummary(request *restful.Request, response *restful.Response) { onlyCPUAndMemory := false <del> request.Request.ParseForm() </del> <ins> err := request.Request.ParseForm() if err != nil { handleError(response, "/stats/summary", errors.Wrapf(err, "parse form failed")) return } </ins> if onlyCluAndMemoryParam, found := request.Request.Form["only_cpu_and_memory"]; found && len(onlyCluAndMemoryParam) == 1 && onlyCluAndMemoryParam[0] == "true" { onlyCPUAndMemory = true } var summary *statsapi.Summary <del> var err error </del> if onlyCPUAndMemory { summary, err = h.summaryProvider.GetCPUAndMemoryStats() } else {

Related discussion:
text: What happened: In handler#handleSummary, return value from request.Request.ParseForm() is ignored. What you expected to happen: The error return should be checked.
/sig node
Hi this seems to be easy to fix. Could I solve this?
Please go ahead.
Code change:
<del> apiVersion: extensions/v1beta1 </del> <ins> apiVersion: networking.k8s.io/v1beta1 </ins> kind: Ingress metadata: name: echomap

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: https://k8s- Reason for failure: Anything else we need to know: /cc /milestone v1.19 /priority important-soon /sig network
Ref:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
my fu points me to this commit [] Fix multiple conversion tests that belongs to this PR , that seems related can you confirm if that PR is causing this test to fail? (should we gate on this test?)
Yes, that PR is related to the failure. The test utility is trying to convert extensions/v1beta1 data read from various files directly to a go type. This was never a valid thing to do, and happened to silently succeed because the two structs had an identical structure. This is exactly the type of bug was designed to flush out
the correct fix is to update the test/e2e/testing- files to
/assign
It was my PR that broke this - I can also fix that.
Thanks, o it was the commit that was good but the test that was wrong :upsidedownface: , At least I got right the commit :sweat_smile:
is out for review (talked with offline, he was aware that I'll send that out)
Code change:
import ( "context" <ins> "errors" </ins> "fmt" "io/ioutil" "net/http"

Related discussion:
text: In we discovered a bug where kube-apiserver metrics were being incorrectly reported (GET vs LIST problem). In this was addressed together with test exercising that proper metrics are exposed. However, this test isn't ideal because if params wouldn't be swapped, it wouldn't catch them. We should ideally develop a lower-level unit test for mapping url paths to exact values of labels/parameters. /sig apimachinery
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : In we discovered a bug where kube-apiserver metrics were being incorrectly reported (GET vs LIST problem). In this was addressed together with test exercising that proper metrics are exposed. We should ideally develop a lower-level unit test for mapping url paths to exact values of labels/parameters. 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
/sig api-machinery
are you planning on sending a fix for this one too? Thanks!
Not very soon - if someone else could help with it, it would be great.
/assign
/triage accepted
cc
Code change:
return true } } <ins> for _, c := range pod.Spec.InitContainers { if c.Name == containerName { return true } } </ins> return false }

Related discussion:
text: Need to finish so the client allows you to select an init container, and verify the kubelet works correctly.
(this is a nice intersection of new in 1.3, node and usability, if anyone wants to give it a shot. Pretty sure Clayton is busier than I am and I don't think I'll get to it)
Will be happy to review any changes - should be fairly straightforward.
Yes, init containers are "run to completion" always. , harryz wrote:
IIUC when the init containers of pod have not complete, the pod should be in status, which means will fail, if init containers run to completion, they will exit, still fail. I don't know what you mean exec should work on init containers?
the init container is still up and running even when the pod is in pending, we should be able to exec and debug why it's hung, for example.
add a straightforward exec implementation ptal.
Code change:
"github.com/Azure/go-autorest/autorest/to" "github.com/stretchr/testify/assert" "k8s.io/api/core/v1" <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> ) func TestFindProbe(t *testing.T) {

Related discussion:
text: <!-- 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: When service is set with ILB annotation and empty string subnet, e.g. The service would be pending forever with following error: What you expected to happen: ILB should be provisioned successfully. 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: Others: /sig azure /kind bug /assign
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Thanks
Code change:
}, nil } <del> func (c *configFactory) getNextPod() *v1.Pod { pod, err := c.podQueue.Pop() if err == nil { klog.V(4).Infof("About to try and schedule pod %v/%v", pod.Namespace, pod.Name) return pod } klog.Errorf("Error while retrieving next pod from scheduling queue: %v", err) return nil } </del> // assignedPod selects pods that are assigned (scheduled and running). func assignedPod(pod *v1.Pod) bool { return len(pod.Spec.NodeName) != 0

Related discussion:
text: PLEASE COORDINATE WITH SIG-SCHEDULING BEFORE WORKING ON THIS ISSUE. We want to avoid the situation where two people accidentally start work on the same fix. Main tracking issue: The method of is a simple wrapper around . It should be converted into a simple closure instead of being a method. i.e. we should have, (code is in ) /sig scheduling /kind cleanup /help
I'd like to take this task. /assign /remove-help
Thanks, go for it! :smile:
Code change:
CGROUP_ROOT=${CGROUP_ROOT:-""} # name of the cgroup driver, i.e. cgroupfs or systemd CGROUP_DRIVER=${CGROUP_DRIVER:-""} <ins> # owner of client certs, default to current user if not specified USER=${USER:-$(whoami)} </ins> # enables testing eviction scenarios locally. EVICTION_HARD=${EVICTION_HARD:-"memory.available<100Mi"}

Related discussion:
text: Encountered this error while running on master: Should we set to by default? cc
Why is it empty? Would be better?
seems to expect $(whoami) based on the value of that variable for my machine. I can make that change if you would like.
Can you keep as an option if it is specified? returns a 6 digit numeric value on my machine (corporate provisioned) and that is incompatible with GCI images, as well as error-ing out during e2e provisioning.
that is a great idea, so should be defaulting to whoami in the case where it has not been defined.
OK, will file an PR to fix this.
Filed PR at . PTAL
Code change:
return nil, err } <del> return newRuntimeVersion(typedVersion.Version) </del> <ins> return newRuntimeVersion(typedVersion.RuntimeVersion) </ins> } // APIVersion returns the cached API version information of the container

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST? : BUG: With CRI enabled by default, kubelet reports the version of CRI instead of container runtime version: Kubernetes version (use ): Master and 1.6. What you expected to happen: Kubelet should report the version of container runtime. Will file a PR to fix this. cc
Code change:
// use kubeletServer to construct the default KubeletDeps kubeletDeps, err := app.UnsecuredDependencies(kubeletServer) <ins> if err != nil { die(err) } </ins> // add the kubelet config controller to kubeletDeps kubeletDeps.KubeletConfigController = kubeletConfigController

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Testing bringing up k8s cluster using kubeadm from latest k8s code from master branch. kubelet is not coming up and below is the errors from syslog: upon looking at the code from where the error is happening, it is evident that the err checking is missing. What you expected to happen: deployment to succeed. How to reproduce it (as minimally and precisely as possible): Use the latest code from k8s and build a k8s release and bring up cluster using kubeadm Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration**: GCE OS (e.g. from /etc/os-release): 16.04 LTS (Xenial Xerus) Kernel (e.g. ): Linux e2e--master 4.4.0-21-generic -Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Others: /sig node /cc
PTAL
Code change:
obj.CgroupDriver = "cgroupfs" } if obj.EnforceNodeAllocatable == nil { <del> obj.EnforceNodeAllocatable = defaultNodeAllocatableEnforcement </del> <ins> obj.EnforceNodeAllocatable = DefaultNodeAllocatableEnforcement </ins> } }

Related discussion:
text: Solution: I will add one.
/cc
xref
Thanks for sending a PR so quickly!
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code slush, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: If this issue is not resolved or labeled as by Wed, Nov 22 it will be moved out of the v1.9 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : 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
Code change:
package testutil import ( <ins> "fmt" </ins> "io" "github.com/prometheus/client_golang/prometheus/testutil" <ins> apimachineryversion "k8s.io/apimachinery/pkg/version" </ins> "k8s.io/component-base/metrics" )

Related discussion:
text: What would you like to be : Once a metric be deprecated, we should update the unit test accordingly if there is any. We need to work out a way for a unit test freely select codebase version, and also should make sure the unit test won't fail in the subsequent release. Why is this needed: Deprecated also needs to be protected. /sig instrumentation /assign
Code change:
// alpha: v1.4 ExternalTrafficLocalOnly utilfeature.Feature = "AllowExtTrafficLocalEndpoints" <del> // owner: @saad-ali // alpha: v1.3 DynamicVolumeProvisioning utilfeature.Feature = "DynamicVolumeProvisioning" </del> // owner: @mtaufen // alpha: v1.4 DynamicKubeletConfig utilfeature.Feature = "DynamicKubeletConfig"

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: kube-apiserver --help still shows this: It looks like the related feature can be turned off. However, dynamic volume provisioning Alpha has retried in 1.6. What you expected to happen: Remove from feature gate to avoid confusion. How to reproduce it (as minimally and precisely as possible): Run Anything else we need to know?: No Environment: Kubernetes version (use ): 1.7+ Cloud provider or hardware configuration**: Any OS (e.g. from /etc/os-release): Any Kernel (e.g. ): Any Install tools: Others:
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
/sig api-machinery
SIG API Machinery doesn't own the contents of the API. /sig storage
Code change:
// For each groupversion served by our resourcemanager, create an APIService // object connected to our fake APIServer <ins> var groupVersions []metav1.GroupVersion </ins> for _, versionInfo := range basicTestGroup.Versions { groupVersion := metav1.GroupVersion{ Group:   basicTestGroup.Name,

Related discussion:
text: reported that conformance testing with the latest version of sonobuoy against a version 1.29.0-alpha.3 cluster fails on the support the 1.17 Sample API Server using the current Aggregator test: , related to I found the reason why the test is working fine in Kubernetes CI jobs but fails with sonobuoy is because the service account used by sonobuoy "sonobuoy-serviceaccount" doesn't have read permission of the non-resource url "/", which is used by the test to confirm the removal of group path: The permission of "sonobuoy-serviceaccount" is as below: There may be two ways to fix it: the RBAC rule of sonobuoy to include "get" of "/". However, could other test runners encounter this issue? Is there a doc listing the required permissions for running e2e tests? the e2e to skip checking the removal of the group path if the service account doesn't have permission to access the root path. Which way do we usually prefer? Running e2e with sonobuoy should succeed. a v1.29.0-alpha.3 cluster. No response <details</details<details</details<details</details<details</details<details</details<details</details
implemented this solution.
/sig api-machinery
thank you for opening this issue and working on a solution. I'm probably not the right person to decide on which solution is preferred. From my perspective, either solution is fine.
Note: Sonobuoy is not owned by any Kubernetes SIG. At most it is between SIG Architecture and the CNCF to choose whether to recommend it for running tests. SIG Testing owns the e2e image that sonobuoy can be used to schedule but not sonobuoy. IMHO this is a bug in running the tests via a pod, which is not how we develop the tests (they're run outside the cluster, by a cluster admin account typically). I would say 1) is the correct answer. xref: /sig architecture /sig testing /triage accepted cc
thanks for your comment. I guess 1) means non of the existing sonobuoy versions can pass K8s conformance test against a cluster 1.29.0-alpha3, as the RBAC rule is hardcoded.
Code change:
// For each groupversion served by our resourcemanager, create an APIService // object connected to our fake APIServer <ins> var groupVersions []metav1.GroupVersion </ins> for _, versionInfo := range basicTestGroup.Versions { groupVersion := metav1.GroupVersion{ Group:   basicTestGroup.Name,

Related discussion:
text: I will file an issue to sonobuoy first.
question here is what are the set of client permissions required to run the conformance suite? perhaps a level of access or a more granular recommendation should be documented. what is your take on the root path requirement as approver for: EDIT: slack thread:
I agree, we already require e.g. privileged pods for a long time in conformance tests and we should make it clear that we expect a highly privileged client.
+1 for what is saying, that we should expect that the user running the tests has required permissions. These tests are not built for being run unprivileged.
i wanted to PR the admin note in our conformance docs under sig-arch, but then i saw this: so broke this guarantee. sounds like SIG Arch needs to comment.
This statement surprises me. Root discovery is one of the least-privileged permissions you can have on a cluster. For years this was even open for unauthorized users on the internet (if your api endpoint has been exposed). In other words, just add the permission. While thinking about it, it is surprising that the user in question does not have this access already. Don't we allow that for every authorized user?
In contrast, I hope that lots of privileged operations are tested by conformance today. If we don't test things like admission webhooks for example, we have much bigger problems. And admission webhooks are basically equivalent to cluster-admin.
that is outdated, we use hostNetwork pods one some of the tests IIRC
looks like we don't. before this ticket, i was under the impression that the conformance suite already requires admin and that all testers (like Sonobuoy) use admin level credentials. it is non-privileged (e.g., does not require root on nodes, access to raw network interfaces, or cluster admin permissions) looks like we may have to change that sentence completely.
Would have expected it here: The PR in question explicitly fixes the result returned by . If that is part of conformance (IMO it should), every conformance test needs access it obviously. Whether we require admin, or we add it manually, either would work.
Code change:
// For each groupversion served by our resourcemanager, create an APIService // object connected to our fake APIServer <ins> var groupVersions []metav1.GroupVersion </ins> for _, versionInfo := range basicTestGroup.Versions { groupVersion := metav1.GroupVersion{ Group:   basicTestGroup.Name,

Related discussion:
text: adding to milestone and making release blocking ... we should not release 1.29 in a state that the most commonly used conformance tool will fail
IMO we should clarify the state and go fix the tool, but we should keep the test and we should NOT add skip. Conformance docs are not a release artifact, and sonobuoy release lifecycle is not a conformance artifact. If we can't get sonobuoy working in a reasonable time, we already know the tests can be run by scheduling the image (which is ours) directly with kubectl instead and we can document that in the upstream conformance docs. We need to fix the for this image: ,%20master%20(dev) And it should probably be to release-blocking in the future.
it looks like the e2e change made in was not consciously made part of conformance, it was just trying to functionally test the bugfix being made. For 1.29, I think we should revert the change to and make an integration test that validates the fix instead. We can revisit whether content of is part of conformance or not for 1.30
I opened to revert the e2e change and move the functional test to an integration test
Filed to try to get the image job passing again.
We probably need another issue to track 1.30 follow-up?
If no one has done it, I could create another issue and follow up with the items that have been discussed here: outdated privilege requirement in commonly used conformance tools like sonobuoy aware of the required priviledge to avoid similar situations in the future. permission of GET "/" to authorized users via the role for root discovery.
Code change:
fi done <ins> errors_expect_error=() for file in "${all_e2e_files[@]}" do if grep "Expect(.*).To(.*HaveOccurred()" "${file}" > /dev/null then errors_expect_error+=( "${file}" ) fi done </ins> if [ ${#errors_expect_no_error[@]} -ne 0 ]; then { echo "Errors:"

Related discussion:
text: What happened: After fixing golint failures under (now still in progress), we need to put for each and . Then common error checking code has become like: We can replace this code with which is more readable and easy to be understood what the code does. Now we have following e2e test directories which can be replaced: [x] test/e2e/apimachinery/ () [x] test/e2e/apps/ () [x] test/e2e/auth/ () [x] test/e2e/common/ () [x] test/e2e/node/ () [x] test/e2e/storage/ () [x] () [x] () [x] () [x] () [x] () [x] () [x] [x] test/e2e/storage/persistentvolumes- [x] () [x] () [x] [x] [x] [x] [x] ()
/sig testing /kind cleanup
/assign PR will be submitted soon.
Fix the following in
Fix in
Fix in
Hi, maybe I could take files beneath test/e2e/storage/vsphere/
oops, I'm finished and prepare for PR.
Thank you That's OK
Fix the following in
/assign
All related PRs were merged. I think this ticket can be closed. BTW, should we also replace to ?
Thanks for your work. thing is managed with We are almost finishing the work also :-)
/remove-kind bug
I found in these files. I'm working on :
I can work to the following item.