jiebi/CodeConvo huggingface dataset:
Change:
utilerrors "k8s.io/kubernetes/pkg/util/errors" "k8s.io/kubernetes/pkg/util/flushwriter" utilruntime "k8s.io/kubernetes/pkg/util/runtime" <ins> "k8s.io/kubernetes/pkg/util/sets" </ins> "k8s.io/kubernetes/pkg/util/wsstream" <ins> "k8s.io/kubernetes/pkg/version" </ins> "github.com/emicklei/go-restful" "github.com/golang/glog"

Discussion:
Is this expected? Does it mean that we cannot drop and replace alpha api without waiting for the new gcloud version?
cc:
cc
cc:
My money is on the TPR discovery code that is trying to identify TPR versions and hacks them into the list of registered APIs.
I guess it's not on HEAD? Do you have the PR#?
had a PR moving StatefulSet from v1alpha1 to v1beta1 and she didn't have the same problem. It's interesting why graduating PDB will have the problem
My PR has similar failure but different symptom. I created a GCE cluster locally. doesn't give me that error, but addon-manager isn't working properly. From addon-manager container log, I saw similar error:
Ah, I was using new kubectl
was using the newly built kubectl so we didn't see the problem at first. Addon-manager is using 1.4.4 kubectl, so we observed problem later.
Hmm, if the problem is the old versions of kubectl unable to dealing with new REST endpoints, then the problem is hard. I'll take a look.
is correct. See this .
I thought the TPR code was inert by default and required a flag to kick in
It seems the flag is enabled for most commands:
We need to support 1 minor version skew for kubectl, so we have to workaround in the server. We can hide those new APIVersions in the discovery API from old kubectl. I'm going to send a PR. In the mean time, if someone can come up with a better idea.
kubectl bug is fixed in , need to cherrypick the change to 1.4. is working on server side temp fix
should fix the problem.
The issue was "fixed" because the "unable to register" error was ignored (not returned, just logged), see:
that line in doesn't seem like a fix... it seems like it's leaving the client restmapper in an unknown state, which seems bad to me
Yeah it's not really a fix
Looks like kubectl should try to register the version to the existing group. IMO this isn't a blocker for
can you make sure there's a 1.5 issue tracking the failure to register the new versions into existing groups correctly, or we'll have a related issue in the future
Filed to track this
Change:
} // NewREST returns a RESTStorage object that will work against API services. <del> func NewREST(scheme *runtime.Scheme, optsGetter generic.RESTOptionsGetter) *REST { </del> <ins> func NewREST(scheme *runtime.Scheme, optsGetter generic.RESTOptionsGetter) (*REST, error) { </ins> strategy := NewStrategy(scheme) store := &genericregistry.Store{

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: When joining a new control plane node with stacked , while the local server starts and joins the cluster, can't connect to it and panics: What you expected to happen: Not sure if this is a bug per se, because in the end the static pod restarts and starts successfully after the server joins the cluster, but that panic should probably be gracefully handled. How to reproduce it (as minimally and precisely as possible): Join a new control plane node. Anything else we need to know?: Environment: Kubernetes version (use ): 1.18.0 Cloud provider or hardware configuration: Hetzner VPS OS (e.g: ): Ubuntu 18.04.4 LTS Kernel (e.g. ): 5.3.0-45-generic (Ubuntu's default HWE kernel) Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
Yeah, the storage signature needs adjusting to propagate the error: /remove-kind bug /kind cleanup /priority backlog
/assign
Change:
package endpointslicemirroring import ( <ins> "sort" </ins> "testing" discovery "k8s.io/api/discovery/v1beta1"

Discussion:
seen in the PR updating to go1.15, but this unit test should not be flaky /assign
was the flaky run
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
can reproduce locally with:
looks like toCreateByAddrType is a map which doesn't have a defined iteration order, so the address family order of toUpdate is not well-defined
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
Containers: []api.Container{ { Name:  "webserver", <del> Image: "gcr.io/google_containers/nettest:1.3", </del> <ins> Image: "gcr.io/google_containers/nettest:1.4", </ins> Args: []string{ "-service=" + name, //peers >= totalPods should be asserted by the container.

Discussion:
test panicked: (root)/Kubernetes%%20suite/Monitoringverifymonitoringpodsandallclusternodesareavailableoninfluxdbusingheapster/ cc
Vish please take a look if you have cycles or reassign if there's someone with better context.
I looked at the panic and it was due to the last test (networking) timing out but still running. I think the fix is more in better cleanup between tests.
I just saw this... it's totally due to ginkgo's cleanup when a test times out. I can fix.
I will get this one.
Ugh, the thing ginkgo does when a test times out is totally lame...
Instead of working around this, I've filed I'm going to go back to a manual timeout on this test.
Change:
"strings" "time" <ins> "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/watch" clientset "k8s.io/client-go/kubernetes" "k8s.io/client-go/tools/cache" </ins> v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/uuid" <del> "k8s.io/apimachinery/pkg/util/wait" </del> podutil "k8s.io/kubernetes/pkg/api/v1/pod" "k8s.io/kubernetes/pkg/kubelet/events" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
pull-kubernetes-e2e-kind-ipv6 Kubernetes e2e suite.[It] [sig-node] Probing container should mark readiness on pods to false and disable liveness probes while pod is in progress of terminating See also, possibly related: Kubernetes e2e suite.[It] [sig-node] Probing container should mark readiness on pods to false while pod is in progress of terminating when a pod has a readiness probe Not sure. At least as of July 27, 2022, but probably earlier than that. No response ! /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
/sig node
/assign we should use listwatch to monitor pod status changes accurately, this interval 2s may lose pod change and cause the test failure
we did the same recently in another test, didn't we? I can't find the PR
sorry, i have not committed yet. do you plan to fix this test again? if so, I can unassign
he, no sorry for the confusion, I thought you were the one that fixed it, maybe it was ? There was one e2e that was flake and was solved using a listwatch instead of polling it every few seconds, I was trying to find the PR to show you , in case it can give you some idea ... please go ahead and fix it :)
this one?
yeah, so my memory was good then, I've identified the right author :smile:
I didn't understand what you said at first, but now I understand :smile:
Change:
nodeInfoSnapshot:               snapshot, } <ins> metrics.Register() </ins> var sched *Scheduler source := options.schedulerAlgorithmSource switch {

Discussion:
What happened: two scheduler metrics, and , was not recorded in . scheduler has some code for this already. It seems to be a bug. What you expected to happen: and was recorded How to reproduce it (as minimally and precisely as possible): /king bug /sig scheduling
/assign
What do you expect for ? And I think pending pods are available in metrics, but not from scheduler. You can get it from pods info metrics.
actually, scheduler has some code already for recording these metrics. But I found a bug in these code. I will post my PR to fix this issue soon. // I updated the issue description for clarifying.
Change:
RUN cp /bin/bash-static /sh <del> FROM RUNNERIMAGE </del> <ins> FROM ${RUNNERIMAGE} </ins> WORKDIR / COPY --from=builder /sh /bin/

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 --Building the etcd integration-test-image fails with the following err: Failure Log: Expected the image build to pass. k/k cluster/images/etcd build-integration-test-image Change that probably broke it: 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 etcd
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig etcd 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 release
/sig api-machinery
/cc /cc
/cc
/assign /triage accepted
is working on this in .
Change:
"strings" "sync" <ins> grpccodes "google.golang.org/grpc/codes" grpcstatus "google.golang.org/grpc/status" </ins> apierrors "k8s.io/apimachinery/pkg/api/errors" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema"

Discussion:
TestChangeCRD " TestChangeCRD": 37, Recently, not sure the date. No response_ /sig api-machinery
also flaking in weirdly, this doesn't show up at all in
cc I can't tell if this is related to the openapi change or not
Actually, I think this is an issue either with the test or with watch behavior, not sure which. The test starts 10 watches, lets them run, then waits for them to exit cleanly, and instead, they are getting watch errors. I can't tell if the watch errors are expected or not, or if server or watch client behavior changed here or not. Opened to debug further
and stand out as a recent change to watching
cc on whether the watching changes in could explain this integration test getting watch errors it didn't previously get
also stands out
would explain this integration test getting watch errors it didn't previously get?
the filter is enabled only when the server run option has a positive time duration (the default is zero). I searched the k/k repo, only the unit tests in enables this filter: I did a quick scan of the logs, did not see any graceful termination activity either. I will take a deeper look at the logs
and all merged changes were limited to that filter?
This is a Go test, so the entire test output is treated as the failure message. That output is very different from one failure to the other, so in triage we probably have x different "clusters" with one failure in each, instead of one cluster with x failures. I don't know what triage does with such small clusters.
we have changes in only the the filter adds to the request context, I just searched the code base, did not find any other call site for by default, should block (on a nil channel) If the test is receiving an event, it implies that the following case is executing, right?
xref: ??
Thank you all for deflaking.
/triage accepted
Change:
var diskPathRegexp = regexp.MustCompile("/dev/disk/(?:by-id|by-path)/") func TestVolumes(t *testing.T) { <del> cfg, ok := configFromEnv() </del> <ins> cfg, ok := configFromEnvWithPasswd() </ins> if !ok { t.Skip("No config found in environment") }

Discussion:
This issue was reported in the Description When configuring components of infrastructure, environment variables allow a trivial method of gathering settings. However, not all settings should be derived from these variables. For example, the file used the CFSSLCAPKPASSWORD environment variable, where a plain-text password should be found within the variable. Figure 8.1: A string password being recovered from the CFSSLCAPKPASSWORD environment variable. If this variable is configured, an attacker could potentially gain access to its stored value through environment logging, or further exploitation of the endpoint. The assessment team found seemingly sensitive environment variables in at least the following locations: Exploit Scenario Alice configures her environment with the CFSSLCAPKPASSWORD environment variable. Eve gains access to Alice’s environment and determines that the CFSSLCAPK_PASSWORD environment variable is set. Because this variable contains the private key password, Eve is able to recover the private key and use it trivially, leading to further exploitation of Alice’s environment. Recommendation Short term, ensure highly sensitive information is not collected directly from environment variables for long periods of time. Long term, consider using Kubernetes secrets for all areas of the system. This will allow users to have one unified interface and location for all secrets, and avoid accidentally exposing secrets to other users within a host system. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of TOB-K8S-005 and it was finding 9 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 35 of the Environment: Kubernetes version: 1.13.4
/sig auth /sig cloud-provider /area security /kind bug /remove-kind feature
Also secrets
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17?
is it ok to close this issue also cc:
no, still remains
cc
seen this yet?
Thanks for the attention, we are using it as a fallback option mostly for test and dev env, we are working to remove them.
AFAIK is the only use for this testing. Would it be appropriate to move this code into ?
Submitted a PR to move password retrieval to
Change:
w := res.ResponseWriter namespace, name, err := namer.Name(req) if err != nil { <del> notFound(w, req.Request) </del> <ins> errorJSON(err, codec, w) </ins> return } ctx := ctxFn(req)

Discussion:
e.g. REST.Update should never return an arbitrary error value. Maybe we should change the return code to something stricter than generic error.
/cc
FYI: is for remaining cases where the API doesn't return JSON/Status errors.
Re-opening this until we
I think etcd errors require more abstraction, also:
There are some admission control plugins that did not always follow that practice which I will resolve as part of
Are there any known instances of this remaining?
None that I know of.
Change:
// the pod. The cluster DNS server itself will forward queries to other nameservers that is configured to use, // in case the cluster DNS server cannot resolve the DNS query itself dns := []string{kl.clusterDNS.String()} <del> var dnsSearch []string if kl.clusterDomain != "" { nsSvcDomain := fmt.Sprintf("%s.svc.%s", pod.Namespace, kl.clusterDomain) svcDomain := fmt.Sprintf("svc.%s", kl.clusterDomain) dnsSearch = append([]string{nsSvcDomain, svcDomain, kl.clusterDomain}, hostSearch...) } else { dnsSearch = hostSearch } </del> <ins> dnsSearch := kl.formDNSSearch(hostSearch, pod) </ins> return dns, dnsSearch, nil }

Discussion:
Kubernetes version v1.3.0 Kubelet concatenates host and cluster domain entries for my pod, resulting in an invalid config (too many entries with duplicates). The max is only 6 search domains. Any more and DNS resolution breaks when trying to leverage search domains. The example below has only cluster DNS entries, but illustrates the issue: Host search nameserver 10.233.0.2 nameserver 10.90.0.1 options timeout:2 options attempts:2 Container kubectl run -i --tty busybox --image=busybox -- sh (skip waiting text) / # cat search nameserver 10.233.0.2 options attempts:2 options ndots:5 I should be enable cluster DNS config in my host DNS settings and still have functional pod DNS. Kubelet should be intelligent enough to filter out duplicate search domain entries (or drop search domains beyond the 6th entry)
I think some sane checks needs to be too. libc limits search field to 6 records and 255(?) characters. This limitation should be checked before creation.
Hey guys, I'm working on it.
Dup of
Change:
return fmt.Errorf("Error building CNI config: %v", err) } <del> glog.V(3).Infof("Calling cni plugins to add container to network with cni runtime: %+v", rt) res, err := plugin.cniConfig.AddNetwork(plugin.netConfig, rt) if err != nil { return fmt.Errorf("Error adding container to network: %v", err) } if res.IP4 == nil { return fmt.Errorf("CNI plugin reported no IPv4 address for container %v.", id) </del> <ins> if err = plugin.addContainerToNetwork(id, rt); err != nil { return err </ins> } <del> plugin.podCIDRs[id] = res.IP4.IP.String() </del> // The first SetUpPod call creates the bridge; ensure shaping is enabled if plugin.shaper == nil { plugin.shaper = bandwidth.NewTCShaper(BridgeName)

Discussion:
I gathered e2e test results of suite for last 100 runs. The following is the list of flaky tests. Some might not be related to . I will start with the service tests. Any help would be appreciated. Detail list: Jenkins project:
cc/ Cluster team is working on to make kubenet default. Once we switch this to production, we don't need to restart docker to configure cbr0.
After a bunch of PRs got merged, the kubenet suite is much more stable. One more known flake can be fixed by I will post new flake tests here.
Just bump into a new failure: One of the nodes () got panic: Looks like it crashed at shaper reset.: Can you take a look?
Change:
import ( "context" <ins> "errors" </ins> "fmt" <ins> "syscall" </ins> "testing" "time"

Discussion:
If there is a connection failure when updating the Pod status, we don't retry. Furthermore, due to , we won't have another chance until much later. The problem is that if we don't mark the Pod as Unschedulable, other controllers (such as cluster-autoscaler) wouldn't react to these pods. We should have stronger guarantees to mark a Pod as Unschedulable. You need an unschedulable Pod (for example, a Pod with a non matching node affinity) and a flaky connection to apiserver. No response master This is particularly problematic in 1.24, due to . Any <details</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 scheduling
That is bad, retrying in place on transient errors should probably be ok.
I'll address it. /assign
Thanks!
Change:
KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. <del> KUBE_COVER=" " KUBE_RACE=" " "${KUBE_ROOT}/hack/test-go.sh" "" -test.run="^X" -benchtime=1s -bench=. -benchmem </del> <ins> KUBE_COVER="" KUBE_RACE=" " "${KUBE_ROOT}/hack/test-go.sh" "" -test.run="^X" -benchtime=1s -bench=. -benchmem </ins>

Discussion:
Right now, we execute unit tests in Travis with , and you can see the results on each line: but we don't have an easy place to go browse our code and figure out what's covered and what isn't. Is there some awesome way to do this? At the very least, can we get the actual line-by-line coverage results integrated into our CI build process so we can poke at these somehow?
cc
I'm willing to take a look into this to at least see if something is possible.
Looking into using Coveralls; there are a few other teams at Google already using this. Integration with Travis and Go are supported with the goveralls package:
Unit test coverage can now be viewed at - both master push builds and PRs will be shown there; additionally, Coveralls will update the status and post comments on PRs with coverage stats. (If we find these too spammy, we can disable either or both.) The top-level also has a badge/link to the coverage dashbaord.
Change:
"//test/e2e/framework/providers/azure:all-srcs", "//test/e2e/framework/providers/gce:all-srcs", "//test/e2e/framework/providers/kubemark:all-srcs", <ins> "//test/e2e/framework/providers/openstack:all-srcs", </ins> "//test/e2e/framework/testfiles:all-srcs", "//test/e2e/framework/timer:all-srcs", "//test/e2e/framework/viperconfig:all-srcs",

Discussion:
What happened: When specifying "openstack" as cloud-provider of e2e test, the test is failed like What you expected to happen: We can run e2e test with openstack cloud provider. How to reproduce it (as minimally and precisely as possible): Just kick the following command: ` Anything else we need to know?: This issue doesn't happen on v1.13, so this issue seems to happen during this dev cycle for v1.14. Environment: Kubernetes version (use ): master for v1.14 Cloud provider or hardware configuration: OpenStack OS (e.g: ): Ubuntu 16.04.5 LTS Kernel (e.g. ): 4.4.0-142-generic Install tools: kubeadm Others:
/sig openstack /sig testing
The exception raises at
The reason of this issue comes from
Ideally it is nice to put a new directory for registering the cloud provider.
/assign
I was wondering we could remove "openstack" provider specific tests and conditions from e2e tests, but there are storage tests which are related to OpenStack in e2e tests. So it is nice to add registration for OpenStack at this time.
Change:
readonly KUBE_CONTAINER_RSYNC_PORT=8730 # These are the default versions (image tags) for their respective base images. <del> readonly __default_distroless_iptables_version=v0.6.1 readonly __default_go_runner_version=v2.3.1-go1.23rc2-bookworm.0 </del> <ins> readonly __default_distroless_iptables_version=v0.5.6 readonly __default_go_runner_version=v2.3.1-go1.22.5-bookworm.0 </ins> readonly __default_setcap_version=bookworm-v1.0.3 # These are the base images for the Docker-wrapped binaries.

Discussion:
sgtm, add an issue labeled as release-blocking and in the milestone to either promote to 1.23.0 or revert this to 1.22.x before our 1.31 release Originally posted by in Kubernetes is being built and tested with go1.23rc2 at HEAD () to let it bake in the CI and help iron out issues, if any, with this version of Go. However, for the 1.31 release, the version of Go should be a non-rc, released version. The release timeline of go1.23.0 is ~same as the release timeline of K8s 1.31.0 (see ). If go1.23.0 is not out by then, we should revert to go1.22.x before cutting K8s 1.31.0. /sig release architecture /area code-organization /cc
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted /cc
/milestone v1.31
cc
xposting relevant slack thread:
Also unlike in the past, missing shipping 1.23.0 in 1.31.0 is not a big deal, we have much more room to switch to 1.23.0 in a patch release after all the compat changes with the go team. So we should not fear reverting if the timelines don't line up.
(though go1.23 adds the thing that makes it workable to default to old go version compat settings, so we'll have to eke out another 5 months on 1.21/1.22 for until we can adopt 1.23 on release branches in ~Jan if we miss 1.31, but that's how it looks like it will have to happen)