jiebi/CodeConvo huggingface dataset:
Change:
t.Fatal(err) } t.Run(mapping.Resource.String(), func(t *testing.T) { <del> if _, ok := ignoreList[mapping.Resource]; ok { t.Skip() } </del> status, ok := statusData[mapping.Resource] if !ok { status = statusDefault

Discussion:
It looks like the openapi is not routed properly to set-up the apiservice so apply requests will fail because the fieldmanager is not set-up properly. /cc /sig api-machinery /priority important-soon /kind bug
/wg apply /cc
OpenAPIModels is set to nil for the kube-aggregator server config (which serves the APIServices API): This is done because the kube-aggregator has a special openapi handler that aggregates all the other server's openapi docs. The field controls (at least) two things: /openapi endpoint serving (which we want kube-aggregator to continue to customize) creation of the field manager (which we want kube-aggregator to behave consistently on) We need to decouple presence of OpenAPIConfig and construction of StaticOpenAPISpec (which is needed by the field manager) from construction/installation of OpenAPIVersionedService. That might be a little tricky to untangle, since construction of StaticOpenAPISpec includes paths/operations. The field manager only needs the gvk/schemas.
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
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 This is not something we want closed by accident.
/assign
For reference:
Additional lines for reference: This is roughly how SSA consumes the openapi spec. openapi spec -openapi proto model -typeconverter -SSA field manager For built in types, openapi spec -openapi model openapi model -typeconverter A similar thing happens for CRDs As liggitt mentioned, SSA only requires a subset of the information in the openapi generation, and the openapi generation in the aggregator slightly different than the process for builtins and CRDs.
/unassign
/assign
Change:
} } totalSizeErrorCases := []map[string]string{ <del> {"a": strings.Repeat("b", totalAnnotationSizeLimitB)}, </del> <ins> {"a": strings.Repeat("b", TotalAnnotationSizeLimitB)}, </ins> { <del> "a": strings.Repeat("b", totalAnnotationSizeLimitB/2), "c": strings.Repeat("d", totalAnnotationSizeLimitB/2), </del> <ins> "a": strings.Repeat("b", TotalAnnotationSizeLimitB/2), "c": strings.Repeat("d", TotalAnnotationSizeLimitB/2), </ins> }, } for i := range totalSizeErrorCases {

Discussion:
Expose totalAnnotationSizeLimitB in the validation package: This value is useful for validating annotations outside of the validation package, such as in SSA: Otherwise, size validation on annotations outside of the package would diverge and cause issues later. /kind cleanup /wg api-expression 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
/assign
Change:
if err != nil { return err } <del> if !dv.CanAddr() { </del> <ins> if !dv.CanAddr() && !dv.CanSet() { </ins> return fmt.Errorf("can't write to dest") } sv, err := EnforcePtr(src)

Discussion:
In Go you cannot take the address of a because the map implementation hides that from you. Our conversion library assumes that any reflected map value can have Addr() taken, which causes a panic when you try to do the following for PodInfo conversion: The conversion code tries to call Addr() on the reflect.Value (the map's value, ContainerStatus value object) which fails because it cannot have an address. I worked around it by registering a conversion function on *PodInfo and then manually converting the map.
Oh you mean the reflection code can't addr that? ok sounds like a bug. Non-reflection code can certainly do it:
That playground is taking the address of a value before it's in the struct. You can't take the address of m ----- Original Message -----
Right, because go does magical c++ style references there. But I thought the map copying code handled that case specially already?
I think I see what you're talking about. I'll make a test.
I repro'd. Will fix.
It was actually the source value that caused the trouble. Thanks for the report!
Sorry, should have been clearer. ----- Original Message -----
Note that this map violates our API conventions. It should be a list of named subobjects.
Yeah this field has always been problematic. It's still a bug regardless-- could have triggered copying other maps.
Change:
resourceWithReq := &lazyResource{req: req.WithContext(ctx)} assert.Equal(t, "resource", fmt.Sprintf("%v", resourceWithReq)) } <ins> func TestLazyScope(t *testing.T) { assert.Equal(t, "unknown", fmt.Sprintf("%v", &lazyScope{})) scopeWithEmptyReq := &lazyScope{&http.Request{}} assert.Equal(t, "unknown", fmt.Sprintf("%v", scopeWithEmptyReq)) req := &http.Request{} ctx := request.WithRequestInfo(context.TODO(), &request.RequestInfo{Namespace: "ns"}) scopeWithReq := &lazyScope{req: req.WithContext(ctx)} assert.Equal(t, "namespace", fmt.Sprintf("%v", scopeWithReq)) } </ins>

Discussion:
One of the use-cases for APIServer tracing would be to try and debug SLO-violating requests served by the API Server. Right now, it adds just some basic attributes: For API Server , SLO-related metrics have the following labels: "verb", "dryrun", "group", "version", "resource", "subresource", "scope", "component", "code" We should add those labels to at least one of the spans created by API Server requests. It isn't a graduation requirement for , but would make the feature more helpful.
/sig instrumentation
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
We might be able to do something using RequestInfo, similar to how the dropped request metric is recorded:
Change:
// Now do the more expensive test initialization. l.config, l.testCleanup = driver.PrepareTest(f) <ins> l.intreeOps, l.migratedOps = getMigrationVolumeOpCounts(f.ClientSet, dInfo.InTreePluginName) </ins> l.resource = createGenericVolumeTestResource(driver, l.config, pattern) if l.resource.volSource == nil { framework.Skipf("Driver %q does not define volumeSource - skipping", dInfo.Name) } <del> l.intreeOps, l.migratedOps = getMigrationVolumeOpCounts(f.ClientSet, dInfo.InTreePluginName) </del> } cleanup := func() {

Discussion:
Example:
/assign
cc
For all those PD instances, tests are being skipped due to this line: Fixing it by removing that skip as suggested by
/open until we verify the issue is fixed
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Looks like diffResources became green on 5/27 /close
Closing this issue. <detailsIn response to : Looks like diffResources became green on 5/27 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:
123.45.67.89	some.domain # Entries added by HostAliases. <del> 123.45.67.89	foo 123.45.67.89	bar 123.45.67.89	baz </del> <ins> 123.45.67.89	foo	bar	baz </ins> `, }, {

Discussion:
What would you like to be : Currently, specifying multiple aliases for a single host using results in a line for each alias in . Example: leads to an file containing something like Why is this needed: Having multiple entries for the same IP address in can break DNS resolution for some software. See for more details <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/sig node
Change:
} } <ins> handlerSyncReadyCh := make(chan struct{}) handlerSyncCheck := healthz.NamedCheck("sched-handler-sync", func(_ *http.Request) error { select { case <-handlerSyncReadyCh: return nil default: } return fmt.Errorf("waiting for handlers to sync") }) readyzChecks = append(readyzChecks, handlerSyncCheck) </ins> // Start up the healthz server. if cc.SecureServing != nil { <del> handler := buildHandlerChain(newHealthzAndMetricsHandler(&cc.ComponentConfig, cc.InformerFactory, isLeader, checks...), cc.Authentication.Authenticator, cc.Authorization.Authorizer) </del> <ins> handler := buildHandlerChain(newHealthEndpointsAndMetricsHandler(&cc.ComponentConfig, cc.InformerFactory, isLeader, checks, readyzChecks), cc.Authentication.Authenticator, cc.Authorization.Authorizer) </ins> // TODO: handle stoppedCh and listenerStoppedCh returned by c.SecureServing.Serve if _, _, err := cc.SecureServing.Serve(handler, 0, ctx.Done()); err != nil { // fail early for secure handlers, removing the old error loop from above

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:
ginkgo.Context("attempt to deploy past allocatable memory limits", func() { ginkgo.It("should fail deployments of pods once there isn't enough memory", func() { <del> overrideAllocatableMemoryTest(f, 4) </del> <ins> overrideAllocatableMemoryTest(f, framework.TestContext.CloudConfig.NumNodes) </ins> }) })

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: None, test is excluded Which test(s) are failing: Since when has it been failing: Unsure Testgrid link: Currently excluded Reason for failure: All 3 nodes have , of which is allocatable. The test was trying to schedule pods with 11009703Ki if I'm understanding the logs correctly. I think 3 pods should have started and 4th should have failed. Maybe the test needs to be updated to wait for 3/4 to start, not 4/4 but that's just a guess. Anything else we need to know: /sig windows
/assign
Change:
ginkgo.By("Run a high priority pod that has same requirements as that of lower priority pod") // Create a high priority pod and make sure it is scheduled on the same node as the low priority pod. <del> runPausePod(f, pausePodConfig{ </del> <ins> runPausePodWithTimeout(f, pausePodConfig{ </ins> Name:              "preemptor-pod", PriorityClassName: highPriorityClassName, Resources: &v1.ResourceRequirements{ Requests: podRes, Limits:   podRes, }, <del> }) </del> <ins> }, framework.PodStartShortTimeout) </ins> preemptedPod, err := cs.CoreV1().Pods(pods[0].Namespace).Get(context.TODO(), pods[0].Name, metav1.GetOptions{}) podPreempted := (err != nil && apierrors.IsNotFound(err)) ||

Discussion:
Which jobs are flaking: sig-release-master-blocking Conformance - GCE - master Which test(s) are flaking: E2E: [sig-scheduling] SchedulerPreemption [Serial] validates basic preemption works [Conformance] Testgrid link: Reason for failure: Anything else we need to know: is currently unavailable links to specific failures in spyglass appreciated From TestGrid alert ...
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
I cannot spot any significant logic flaw in the test. A possible cause is the timeout is set too short (1 minute), which may be not enough for the terminating pod to run. Notice that unlike integration test, the time includes the end to end cycle: (1) preemptor being scheduled and evict low-priority pods, (2) low-priority pods being terminating -reported by kubelet that the victims have been deleted, (3) scheduler gets notifications from API server that the victims have been deleted, (4) preemptor gets scheduled, (5) kubelet reports the preemptor is running. /cc for more thoughts.
Maybe, some logs to / would help. Just making the timeout longer don't make sense.
Is addressing this flake?
I think this flake happens before the failure tries to fix:
/kind flake
That's indeed a lot of steps, and flakiness seems very low. I think increasing the timeout for preemption seems reasonable.
is this flake a must-fix in 1.20?
Change:
metric   *metricInfo podReadiness []v1.ConditionStatus <ins> podPhase     []v1.PodPhase </ins> } const (

Discussion:
/kind bug What happened: HPA fails to launch additional pods due to pods in evicted state, even with utilization significantly over target. What you expected to happen: When HPA pods reach the target utilization, new pods should be allocated and provisioned. How to reproduce it (as minimally and precisely as possible): Launch a HPA, let the pods fill the disk on the host which will trigger evictions due to "Pod The node was low on resource: [DiskPressure]", HPA will exceed target and not allocate additional pods. Anything else we need to know?: Seems related to and though those are not specific to HPA. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): cos-stable-57-9202-64-0 kernel commit id Kernel (e.g. ):Linux gke-prod1-use1b-v2--35s4 4.4.70+ SMP Mon Sep 18 12:43:08 PDT 2017 x86_64 Intel(R) Xeon(R) CPU @ 2.30GHz GenuineIntel GNU/Linux
/sig scheduling
Are there any workarounds while we wait for a fix? We have ran into this on a 1.8.4 GKE cluster.
/sig autoscaling /remove-sig scheduling
I am thinking of fixing this by excluding pods with Phase=Failed from the unreadyPods that are taken into account. It seems the right thing to do as they will not become running again. Do you see any issues?
that seems decent -- anything that will never be running again should not be factored into our calculations.
/status approved-for-milestone Adding to milestone -- if the HPA isn't functioning in the case of evictions, that seems like a decently severe HPA bug.
oops, missing priority was my fault, moving back into milestone: /priority critical-urgent /remove-priority important-soon
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, 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: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<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:
go hpaController.Run(stop) tc.Lock() <del> if tc.verifyEvents { tc.Unlock() </del> <ins> shouldWait := tc.verifyEvents tc.Unlock() if shouldWait { </ins> // We need to wait for events to be broadcasted (sleep for longer than record.sleepDuration). <del> time.Sleep(2 * time.Second) </del> <ins> timeoutTime := time.Now().Add(2 * time.Second) for now := time.Now(); timeoutTime.After(now); now = time.Now() { sleepUntil := timeoutTime.Sub(now) select { case <-tc.processed: // drain the chan of any sent events to keep it from filling before the timeout case <-time.After(sleepUntil): // timeout reached, ready to verifyResults } } </ins> } else { <del> tc.Unlock() </del> <ins> // Wait for HPA to be processed. <-tc.processed </ins> } <del> // Wait for HPA to be processed. <-tc.processed </del> tc.verifyResults(t) }

Discussion:
What happened: The unit test for Horizontal Pod Autoscaler frequently deadlocked on the OpenShift CI system. What you expected to happen: The unit test should be robust and succeed without having to win a race condition to avoid deadlock. How to reproduce it (as minimally and precisely as possible): I'm not sure. Anything else we need to know?: Here are some logs of the problem happening: https://openshift-gce- The deadlocks seem to happen when the chan fills up while waiting for events. If that happens, there's a race where immediately after an event is read but before it can acquire the lock to verify the test, 2 event reactors are able to acquire the lock and write to the chan. The second will block forever since the chan is full and there's nobody to read from it. I've opened a PR with the fix. See
/sig autoscaling
/assign
Change:
return nil } <ins> // TODO turn this into reusable method checking available resources func contains(resourcesList map[string]*unversioned.APIResourceList, resource unversioned.GroupVersionResource) bool { if resourcesList == nil { return false } resourcesGroup, ok := resourcesList[resource.GroupVersion().String()] if !ok { return false } for _, item := range resourcesGroup.APIResources { if resource.Resource == item.Name { return true } } return false } </ins> func waitForPodRunning(c *client.Client, pod *api.Pod, out io.Writer) (status api.PodPhase, err error) { for { pod, err := c.Pods(pod.Namespace).Get(pod.Name)

Discussion:
Tested with: Most of the simple basic starting guides direct users to create a cluster with . If I run kubectl 1.2 against a 1.1 cluster, I'll get the following behavior now I happen to know I can get the old behavior by doing but I don't expect an average user to know that or be able to find it easily. I'm mainly concerned that we will be breaking recommended flow for GKE users if they happen to use a new kubectl before their cluster's master is upgraded. We can just update our docs, but breaking a "porcelain" command seems like poor form. Other options include defaulting to the generator for a few patch releases, and/or making do some kind of version check so it can fallback to the generator if deployments/jobs are not available. thoughts?
We should update those docs and document how to achieve stable behavior: .
This would ideally use API discovery, though, to check whether the API exists.
How hard would it be to check whether Deployment existed? We had the same issue in 1.1, btw, with Job.
I'd accept a hack, also, which checked the k8s version if there wasn't enough discovery info in 1.1.
We have the same issue with Job in 1.2, also.
Fix is in
Change:
} if sgNeedsUpdate { glog.V(3).Infof("ensure(%s): sg(%s) - updating", serviceName, *sg.Name) <ins> // azure-sdk-for-go introduced contraint validation which breaks the updating here if we don't set these // to nil. This is a workaround until https://github.com/Azure/go-autorest/issues/112 is fixed sg.SecurityGroupPropertiesFormat.NetworkInterfaces = nil sg.SecurityGroupPropertiesFormat.Subnets = nil </ins> _, err := az.SecurityGroupsClient.CreateOrUpdate(az.ResourceGroup, *sg.Name, sg, nil) if err != nil { return nil, err

Discussion:
Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Azure / Azure Container Service OS (e.g. from /etc/os-release): Xenial Kernel (e.g. ): latest lts Install tools: kubelet + static manifests Others: n/a What happened: I created a Service (type=LoadBalancer). The load balancer did not complete provisioning and security group was not updated, so the LB that is there doesn't work. What you expected to happen: Azure load balancer is created, external IP field is populated (doesn't show as "Pending") How to reproduce it (as minimally and precisely as possible): Try it. Anything else do we need to know: No. There is an issue opened against the repo that caused this problem: This was reported here: CC:
Should we do a fix that simply sets the 2 properties to nil before a real fix comes into go-autorest?
I'd prefer to fix it properly in but as of yet, it's unclear what the timeframe is. Let me ask for a timeline.
I agree that a proper fix in go-autorest would be preferable. But as long as it's not fixed, LBs are broken on k8s=1.5.2. That's why I would like to do a workaround until the real fix comes in.
Is there a workaround? Is there a way I can manually intervene to make the LoadBalancer work?
No. Not currently, other than building your own copy of with patch applied. I'm testing a more proper fix today or tomorrow - hope to have it in for 1.5.3.