jiebi/CodeConvo huggingface dataset:
Change:
if !strings.Contains(output, test.accBody) { t.Errorf("Expected response body to contain %v, got %v", test.accBody, output) } <ins> if test.notBody != "" && strings.Contains(output, test.notBody) { t.Errorf("Expected response not to contain %v, got %v", test.notBody, output) } </ins> } }() }

Discussion:
Grabbed tcpdump of a readiness probe - the src ip was the bridge address (10.244.1.1), but apart from this, there is no identifying information in the HTTP request that this is a Kubernetes daemon requesting readiness checks - this might help QoS/priority assignment by the container application.
IIUC, you mean we should add a better when kubernetes daemon request a readiness check to identify this request comes from kubernetes daemon?
Yes, we should override the default net/http user-agent with our own. Better usability for users and we have no future upgrade hazards if users start hardcoding and expecting this default User-Agent string in their analytic tools.
Any news about this one? It would be nice! I've this little hack in my nginx configuration (in order to not be spamed by health check in logs) :)
This can probably be closed now that probes have support.
Change:
// verify workers that are not terminated stay open even if config no longer // sees them podWorkers.SyncKnownPods(nil) <del> if len(podWorkers.podUpdates) != 2 { </del> <ins> drainAllWorkers(podWorkers) if len(podWorkers.podUpdates) != 0 { </ins> t.Errorf("Incorrect number of open channels %v", len(podWorkers.podUpdates)) } if len(podWorkers.podSyncStatuses) != 2 {

Discussion:
Corresponds to merge of /kind failing-test /sig node /assign /milestone v1.27 /priority critical-urgent === RUN TestSyncKnownPods WARNING: DATA RACE Write at 0x00c000906f60 by goroutine 1395: runtime.mapdeletefaststr() +0x0 (podWorkers).cleanupPodUpdates() +0x299 (podWorkers).completeTerminated() +0x1f4 (podWorkers).podWorkerLoop() +0x18b6 (podWorkers).UpdatePod.func1() +0x175 Previous read at 0x00c000906f60 by goroutine 1380: () +0x1056 testing.tRunner() +0x216 testing.(T).Run.func1() +0x47 Goroutine 1395 (running) created at: (podWorkers).UpdatePod() +0x5131 () +0xc4 testing.tRunner() +0x216 testing.(*T).Run.func1() +0x47
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
This is crazy hard to reproduce locally - I also don't think I saw it one time during development. It's definitely a race caused by my change, but I don't remember hitting it (I would have been hypersensitive to this test). That's concerning.
Rank 2nd for : " TestSyncKnownPods": 15,
Change:
func TestSingleWatch(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> ns := "blargh" deleteAllEtcdKeys()

Discussion:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.
Change:
package util import ( <ins> "context" </ins> "fmt" <ins> "github.com/google/go-cmp/cmp" </ins> "testing" "time"

Discussion:
I am aware that the following is a corner case that does not occur in day-to-day business, but it took me a long while to debug, so I thought I would raise this issue to save others from the same pain. Deploying the following job with empty imagePullSecrets leads to it being stuck in forever, and status looking the following way: The status should look something like: This would allow my autoscaler to kick in and add the corresponding nodes. Run Kubernetes version (use ):Cloud provider or hardware configuration: AWS EKS OS (e.g: ): MacOSX 11.3 Kernel (e.g. ): Darwin Kernel Version 20.4.0 Install tools: brew
/sig scheduling (I assume)
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig scheduling (I assume) 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 Scheduler log
Should we instead forbid empty items in ? Is there a use case for using as ?
For me personally that would be totally fine I had no use case for it. It was more produced by chance as I wasn't aware that I had to handle the case separately. An error which led to an early failure would have been fine by me and solved all my problems in tracking this down.
/assign as
Forbidding it is the appropriate solution. However, we can't do it for backwards compatibility of the API. /triage accepted
Change:
}) <del> /* Testname: Service, NodePort, same port different protocols Description: Create a service of type NodePort listening on port 53 for two protocols TCP and UDP. Service creation MUST be successful by assigning a ClusterIP and two unique nodePorts for each protocol, making service reachable on every node's IP and nodePort. TODO: Test Service reachability, good to include this check in Conformance perspective. */ ginkgo.It("should use same NodePort with same port but different protocols", func() { serviceName := "nodeports" ns := f.Namespace.Name t := e2eservice.NewServerTest(cs, ns, serviceName) defer func() { defer ginkgo.GinkgoRecover() errs := t.Cleanup() if len(errs) != 0 { framework.Failf("errors in cleanup: %v", errs) } }() ginkgo.By("creating service " + serviceName + " with same NodePort but different protocols in namespace " + ns) service := &v1.Service{ ObjectMeta: metav1.ObjectMeta{ Name:      t.ServiceName, Namespace: t.Namespace, }, Spec: v1.ServiceSpec{ Selector: t.Labels, Type:     v1.ServiceTypeNodePort, Ports: []v1.ServicePort{ { Name:     "tcp-port", Port:     53, Protocol: v1.ProtocolTCP, }, { Name:     "udp-port", Port:     53, Protocol: v1.ProtocolUDP, }, }, }, } result, err := t.CreateService(service) framework.ExpectNoError(err, "failed to create service: %s in namespace: %s", serviceName, ns) if len(result.Spec.Ports) != 2 { framework.Failf("got unexpected len(Spec.Ports) for new service: %v", result) } if result.Spec.Ports[0].NodePort != result.Spec.Ports[1].NodePort { framework.Failf("should use same NodePort for new service: %v", result) } }) </del> ginkgo.It("should prevent NodePort collisions", func() { // TODO: use the ServiceTestJig here baseName := "nodeport-collision-"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Following are two e2e testing service functioning over same port but different protocol, but do not test service reachability. be able to update NodePorts with two same port numbers but different protocols use same NodePort with same port but different protocols Note: Both the e2e are verifying the same behavior of "service using same port but different protocols" differs in and . Primary goal: Test service reachability for these E2Es. Secondary goal: As both the above e2e are verifying same E2E behavior, it's good to have single e2e in spite of 2 differing in "updating" and "create only" nodePort service. For "create only", suite has another specific e2e . Why is this needed: E2E Improvement and make e2e eligible for Conformance. Service related e2e are getting promoted in /area conformance /sig testing /assign
Change:
// and reduce the default page size to 2. storeWithCounter := &storageWithCounter{Interface: registry.Storage.Storage} registry.Storage.Storage = storeWithCounter <ins> originalDeleteCollectionPageSize := deleteCollectionPageSize </ins> deleteCollectionPageSize = 2 <ins> defer func() { deleteCollectionPageSize = originalDeleteCollectionPageSize }() </ins> numPods := 10 for i := 0; i < numPods; i++ {

Discussion:
various Oct 30 2023 6pm pst No response Looks like different test are failing with connection timeout errors: One of the tests triggered a core dump: No response /sig
are both suffers from pkg/registry and is from compoent-base, which likely same reason from `
/retitle failing-test: pkg/kubelet/eviction TestManagerWithLocalStorageCapacityIsolationOpen
/sig node
TestManagerWithLocalStorageCapacityIsolationOpen only failed in one of the PRs, so I don't think that specific test is the problem.
ok, rename as see fit. just put owning sigs please for triage.
TestStoreDeleteCollectionWithContextCancellation is the one that seems to be failing across all the failing PRs, so let's start there first. /retitle failing-test: TestStoreDeleteCollectionWithContextCancellation /sig api-machinery
triage link at shows this just starting (happening in CI jobs as well)
image used in the unit test job didn't change around the timeframe this was seen ()
looking for jumps in package unit test runtimes when this failure started happening to see if something is taking longer or stressing the system: ! - cc ! - cc ! - cc Could any of those have introduced changes that could be stressing or exhausting listener connections in unit tests?
the PR in question introduced a poll function around an API call that is unit tested with a fake client i.e. the poll is unit tested, but the fake client has reactors that return error or success right away, so in theory the poll should not be stretched to 1 retries with 1 connection attempts per fake client. while testing locally i did not notice any significant time difference after or the prior i can do some more checks to see what's going on.
merged right at the time the flakes were seen DeleteCollection invokes List, which was modified in that PR to cancel more aggressively cc
I can reproduce about a 10-20% flake rate at HEAD with: failures look like: or while testing that package with , I see ~1300-1500 open connections with this:
Let's revert it then. I looked into it and I don't know from a quick glance why it's failing and I don't have time to debug it now.

I opened
Okay, it looks like we need more debugging to open this PR
one optimization to strip some ~40 fake client connections and 2 seconds from a test:
sounds good, pointed at that commit as well
/triage accepted
Change:
} func (s *ContainerRuntimeOptions) AddFlags(fs *pflag.FlagSet) { <ins> dockerOnlyWarning := "This docker-specific flag only works when container-runtime is set to docker." </ins> // General settings. fs.StringVar(&s.ContainerRuntime, "container-runtime", s.ContainerRuntime, "The container runtime to use. Possible values: 'docker', 'remote', 'rkt (deprecated)'.") fs.StringVar(&s.RuntimeCgroups, "runtime-cgroups", s.RuntimeCgroups, "Optional absolute name of cgroups to create and run the runtime in.")

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When use remote container runtime, the remote can't get any PodSandboxImage config set by kubelet What you expected to happen: We want the all container runtime should know what's right PodSandboxImage How to reproduce it (as minimally and precisely as possible): in new node with into k8s cluster kubelet with options expect frakti can create sandbox container with , but get default (k8s version: v1.8.2) Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: bootstrap by kubeadm v1.8.2 OS (e.g. from /etc/os-release): Debian GNU/Linux 9 (stretch) Kernel (e.g. ): SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x8664 GNU/Linux Install tools: kubeadm Others:
/sig node
good news! thanks!
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
Actually we do a no-op when the container runtime is . This is why config can not be set by flag for . In your case, the correct place to change the default sandbox image is in .
Change:
*/ framework.ConformanceIt("should function for intra-pod communication: http [NodeConformance]", func() { config := e2enetwork.NewCoreNetworkingTestConfig(f, false) <del> for _, endpointPod := range config.EndpointPods { config.DialFromTestContainer("http", endpointPod.Status.PodIP, e2enetwork.EndpointHTTPPort, config.MaxTries, 0, sets.NewString(endpointPod.Name)) } </del> <ins> checkNodeConnectivity(config, "http", e2enetwork.EndpointHTTPPort) </ins> }) /*

Discussion:
What would you like to be : Right now we poll one node at a time for intra-pod tests. We ultimately fail a test if any one node is unreachable. If we instead polled all nodes, multiple times, and collected the number of times a node was unreachable, this would tell us what % of nodes on the cluster were broken, rather then just telling us the first node that was broken. not break the testing contract (were still verifying intra-pod connectivity, just doing so in a way that gives us holistic cluster info) Why is this needed: I described why this would make triage alot easier, and in general make it easier to see why tests are failing, here ... i'll collect a little more data on this to justify the decision .... as this is a conformance test so the bar for modification is higher (even if the test itself isnt changing) then regular tests.
/sig network
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
func (s *InsecureServingOptions) AddFlags(fs *pflag.FlagSet) { fs.IPVar(&s.BindAddress, "insecure-bind-address", s.BindAddress, ""+ "The IP address on which to serve the --insecure-port (set to 0.0.0.0 for all interfaces).") <ins> fs.MarkDeprecated("insecure-bind-address", "This flag will be removed in a future version.") </ins> fs.IntVar(&s.BindPort, "insecure-port", s.BindPort, ""+ "The port on which to serve unsecured, unauthenticated access. It is assumed "+ "that firewall rules are set up such that this port is not reachable from outside of "+ "the cluster and that port 443 on the cluster's public address is proxied to this "+ <del> "port. This is performed by nginx in the default setup. Set to zero to disable") </del> <ins> "port. This is performed by nginx in the default setup. Set to zero to disable.") fs.MarkDeprecated("insecure-port", "This flag will be removed in a future version.") </ins> } <ins> // TODO: remove it until kops stop using `--address` </ins> func (s *InsecureServingOptions) AddDeprecatedFlags(fs *pflag.FlagSet) { fs.IPVar(&s.BindAddress, "address", s.BindAddress, "DEPRECATED: see --insecure-bind-address instead.")

Discussion:
Currently as authentication and authorization are both standard config for all clusters, the kubeapiserver insecure http handler is unsecure, which means the cluster is vulnerable to the attack. So it should be deprecated, even removed totally.
/sig api-machinery
I think removing the insecure option is a good idea. Can you send an email the sig-apimachinery mailing list with a proposed timeline? I think this should be like other GA features and have a one year clock.
Sure, I will send it ASAP.
:+1:
Change:
"containers": [ { "name": "kube-proxy", <del> "image": "gcr.io/google_containers/hyperkube-ARCH:VERSION", </del> <ins> "image": "REGISTRY/hyperkube-ARCH:VERSION", </ins> "command": [ "/hyperkube", "proxy",

Discussion:
Because of the revert on commit , when building for 3rd party registry, hyperkube is broken again.
Can we close this now? looks like the PR has merged
Change:
result = IsErrorRetriable(fmt.Errorf("Retriable: true")) assert.Equal(t, true, result) } <ins> func TestHasErrorCode(t *testing.T) { // false case result := HasStatusForbiddenOrIgnoredError(fmt.Errorf("HTTPStatusCode: 408")) assert.False(t, result) // true case 404 result = HasStatusForbiddenOrIgnoredError(fmt.Errorf("HTTPStatusCode: %d", http.StatusNotFound)) assert.True(t, result) // true case 403 result = HasStatusForbiddenOrIgnoredError(fmt.Errorf("HTTPStatusCode: %d", http.StatusForbidden)) assert.True(t, result) } </ins>

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: controller-manager is stuck in deleting an incorrectly configured LB type service. it cannot be recovered until restarted. What you expected to happen: controller-manager should recover. At least it should allow us to create the service without restarting it. How to reproduce it (as minimally and precisely as possible): put a random IP in above yaml and make sure the resource group doen't exist. Anything else we need to know?: Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig azure
I also want to add that the above repro is stuck in 403. It's possible for it to be stuck in 404 as well when the SP has the right permission.
Can you share the log for 404?
Thanks for reporting the issue. /assign Do you mean other services couldn't be configured when this happens?
correct.
FYI, we had the same issue when the Idle Timeout annotation was set to "3" which isn't a supported case. Will this PR also cover this edge case ?
Unfortunately , this is still not fixed. The idle timeout is not 403 or 404. We need another fix for this (and possibly more for other annotations)
Change:
return sha256.New() }, } <del> legacyregistry.MustRegister(encryptionConfigAutomaticReloadFailureTotal) legacyregistry.MustRegister(encryptionConfigAutomaticReloadSuccessTotal) </del> <ins> legacyregistry.MustRegister(encryptionConfigAutomaticReloadsTotal) legacyregistry.MustRegister(deprecatedEncryptionConfigAutomaticReloadFailureTotal) legacyregistry.MustRegister(deprecatedEncryptionConfigAutomaticReloadSuccessTotal) </ins> legacyregistry.MustRegister(encryptionConfigAutomaticReloadLastTimestampSeconds) }) } func RecordEncryptionConfigAutomaticReloadFailure(apiServerID string) { apiServerIDHash := getHash(apiServerID) <del> encryptionConfigAutomaticReloadFailureTotal.WithLabelValues(apiServerIDHash).Inc() </del> <ins> encryptionConfigAutomaticReloadsTotal.WithLabelValues("failure", apiServerIDHash).Inc() deprecatedEncryptionConfigAutomaticReloadFailureTotal.WithLabelValues(apiServerIDHash).Inc() </ins> recordEncryptionConfigAutomaticReloadTimestamp("failure", apiServerIDHash) } func RecordEncryptionConfigAutomaticReloadSuccess(apiServerID string) { apiServerIDHash := getHash(apiServerID) <del> encryptionConfigAutomaticReloadSuccessTotal.WithLabelValues(apiServerIDHash).Inc() </del> <ins> encryptionConfigAutomaticReloadsTotal.WithLabelValues("success", apiServerIDHash).Inc() deprecatedEncryptionConfigAutomaticReloadSuccessTotal.WithLabelValues(apiServerIDHash).Inc() </ins> recordEncryptionConfigAutomaticReloadTimestamp("success", apiServerIDHash) }

Discussion:
Change encryption config controller reload metrics to be consistent with other places (Authn, Authz) xref: Combine and into a single metric with with an enum value of and . /sig auth /triage accepted
cc
We probably should keep the existing metrics for some time to allow folks to migrate to the new one.
Ah I was thinking about this as well! Looking at "may be deleted at any time", I was leaning towards just removing it. If the common approach is to keep it for a release before removing, we could do that. I believe we can set a for the 2 metrics we want to remove.
I don't have a good sense of metrics stability because they tend to stay alpha forever and folks don't go back to update them. Since the associated feature set is GA, I think we should be conservative with the changes we make. Perhaps SIG instrumentation folks can provide some guidance here?
As part of the PR, I was going to ask when is the right time to graduate these metrics do you have thoughts on to take while deleting an alpha metric metrics should be graduated from alpha to beta and stable?
Change:
if g.kubeScheduler == "" { return SchedulerMetrics{}, fmt.Errorf("kube-scheduler pod is not registered. Skipping Scheduler's metrics gathering") } <del> output, err := g.getMetricsFromPod(g.client, metricsProxyPod, metav1.NamespaceSystem, kubeSchedulerPort) </del> <ins> var err error var output string g.waitForSchedulerReadyOnce.Do(func() { var lastMetricsFetchErr error if metricsWaitErr := wait.PollImmediate(time.Second, time.Minute, func() (bool, error) { output, lastMetricsFetchErr = g.getMetricsFromPod(g.client, metricsProxyPod, metav1.NamespaceSystem, kubeSchedulerPort) return lastMetricsFetchErr == nil, nil }); metricsWaitErr != nil { err = fmt.Errorf("error waiting for scheduler pod to expose metrics: %v; %v", metricsWaitErr, lastMetricsFetchErr) return } }) </ins> if err != nil { return SchedulerMetrics{}, err }

Discussion:
! /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig instrumentation /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
The flake happened in before.
This is fixed. !
/reopen This is still failing. Sample run:
Reopened this issue. <detailsIn response to : /reopen Sample run: 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
/priority critical-urgent
The error message in makes me think the apiserver is not available during that test run: . Can someone link to the frequency graphs to see if the problem is widespread?
got it:
I don't think I was right above. I think the "the server is currently unable to handle the request" is an error coming from the proxy. The proxy was around the time this issue was filed (), so it seems likely to be related to it. can you take a look?
This is a known issue, and is working on it . Now that is being blocked by the debugging handler problem, could we merge to mitigate this problem first? cc
I would prefer to reach a decision about enabling the debug handlers, but if that's not possible, then merging PR as mitigation might make sense.
Think I hit this also.
It appears to still be failing based on
Why rebase? Any new test run will be based on merge with current k/k master and thus contain
<img width="1111" alt="Screen Shot 2021-05-28 at 13 04 52" src="https://user-" looks like it has become more stable now.
/close
Closing this issue. <detailsIn response to : /close 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:
Example: apply_example, Run: func(cmd *cobra.Command, args []string) { cmdutil.CheckErr(validateArgs(cmd, args)) <del> cmdutil.CheckErr(cmdutil.ValidateOutputArgs(cmd)) </del> cmdutil.CheckErr(validatePruneAll(options.Prune, cmdutil.GetFlagBool(cmd, "all"), options.Selector)) cmdutil.CheckErr(RunApply(f, cmd, out, errOut, &options)) },

Discussion:
What happened: What you expected to happen: yaml output How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: Related PR