jiebi/CodeConvo huggingface dataset:
Change:
return p.admitResourceSlice(nodeName, a) case csrResource: <del> if p.kubeletCSRAdmissionValidationDisabled { </del> <ins> if p.allowInsecureKubeletCertificateSigningRequests { </ins> return nil } return p.admitCSR(nodeName, a)

Discussion:
This comes from We've a feature gate, . However, we try to name feature gates after the positive thing they add, even if it's on by default, or even if we're setting if false because the positive thing is being dropped (rare, but it happens). Typically we don't start feature gate names with , as it makes the docs jar: Example quote 1: To temporarily revert to the legacy behavior, enable the feature gate. vs Example quote 2: You can enable the feature gate if you run code that relies on the previous behavior. You should plan to migrate. and because disabling things isn't really a feature. Some examples of gates you can or once could disable by turning them off_ include: - - - So, I recommend a rename of the gate before the v1.31 release. /sig auth architecture
FYI
Example gate names: (off by default) (off by default) (on by default) (on by default) (on by default) from (off by default, deprecated)
/milestone v1.31
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Milestone Maintainers Team and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /milestone v1.31 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
Another possibility: , deprecated, off by default
Hello there! I am new to kubernetes and I want to contribute in it. Is it something that I can contribute to?
This issue is not a good issue for a first-time contributor to work on.
I'm a fan of , deprecated, off by default
hoping one of you are doing the PR? :) /milestone v1.31
Change:
// add a new dummy listener in order to get a port that is free l, _ := net.Listen("tcp", ":0") <del> _, port, _ = net.SplitHostPort(l.Addr().String()) portNum, _ := strconv.Atoi(port) </del> <ins> _, newPort, _ := net.SplitHostPort(l.Addr().String()) portNum, _ := strconv.Atoi(newPort) </ins> l.Close() // Wait for the socket to actually get free. <del> if err := waitForClosedPort(p, port); err != nil { </del> <ins> if err := waitForClosedPort(p, newPort); err != nil { </ins> t.Fatalf(err.Error()) } <ins> if proxyPort == newPort { t.Errorf("expected difference, got %s %s", newPort, proxyPort) } </ins> p.OnUpdate([]api.Service{ {JSONBase: api.JSONBase{ID: "echo"}, Port: portNum}, }) if err := waitForClosedPort(p, proxyPort); err != nil { t.Fatalf(err.Error()) } <del> testEchoConnection(t, "127.0.0.1", port) </del> <ins> testEchoConnection(t, "127.0.0.1", newPort) </ins> }

Discussion:
https://travis-
Looking.
Another instance, or a different thing? https://travis-
Change:
fi fi <ins> local address="" if [[ ${GCE_PRIVATE_CLUSTER:-} == "true" ]]; then address="no-address" fi </ins> local network=$(make-gcloud-network-argument  "${NETWORK_PROJECT}"  "${REGION}"  "${NETWORK}"  "${SUBNETWORK:-}"  <del> ""  </del> <ins> "${address}"  </ins> "${ENABLE_IP_ALIASES:-}"  "${IP_ALIAS_SIZE:-}")

Discussion:
Public IPs are expensive resources. Given that we're running scalability tests on 5k-node clusters, we are unnecessarily consuming 5k IPs which is a lot. We should switch our tests so that nodes have only private IP addresses. We are going to do that by configuring NAT so that nodes can talk to outside world (e.g. to download image from dockerhub). But that also requires changing some correctness tests which assume public IPs.
To summarize recent work: setting up private gce clusters with nat, feature is gated via the env test and dashboard with correctness tests on gce private cluster - https://k8s- 27 tests fail on fixing the tests - should fix majority of them
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 /lifecycle frozen
- is there anything missing to be done here?
No, we can close this one. It was done long time ago. Thanks for catching /close
Closing this issue. <detailsIn response to : No, we can close this one. It was done long time ago. Thanks for catching 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:
containers: # TODO: Add resources in 1.8 - name: event-exporter <del> image: gcr.io/google-containers/event-exporter:v0.1.0 </del> <ins> image: gcr.io/google-containers/event-exporter:v0.1.0-r2 </ins> command: - '/event-exporter' - name: prometheus-to-sd-exporter <del> image: gcr.io/google-containers/prometheus-to-sd:v0.1.2 </del> <ins> image: gcr.io/google-containers/prometheus-to-sd:v0.1.2-r2 </ins> command: - /monitor - --component=event_exporter

Discussion:
A number of addon images have CVEs that have been fixed in the upstream base images. We should update these images before the final 1.7 release. cc
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/cc
cc
The new image appears to have removed . I'm not sure if this was expected, but it caused at least fluentd to stop working on COS (). This might also affect kubeproxy, which uses (a derivative of ).
also the metadata-proxy, prometheus-to-sd, the fluentd-event-exporter, and ip-masq-agent.
anything more to do for this issue?
yes, I need to get merged and update those images again. I also need to bump a few other images (dns and ip-masq-agent).
should be the last update needed.
Change:
}, } <del> // Columns: Name, Completions, Duration, Age </del> <ins> // Columns: Name, Status, Completions, Duration, Age </ins> expectedRows := []metav1.TableRow{ <del> {Cells: []interface{}{"job1", "1/2", "", "0s"}}, {Cells: []interface{}{"job2", "2/2", "20m", "0s"}}, </del> <ins> {Cells: []interface{}{"job1", "Running", "1/2", "", "0s"}}, {Cells: []interface{}{"job2", "Running", "2/2", "20m", "0s"}}, </ins> } rows, err := printJobList(&jobList, printers.GenerateOptions{})

Discussion:
Suspend is a GA feature and it is big component of Kueue. It would be nice to display if jobs are suspended when doing . A new column that displays if the job is suspended would be helpful. Improve UX around suspend. Its a bit difficult to know why the job has not created pods unless you know about the suspend field.
/sig cli /wg batch /good-first-issue /help-wanted
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig cli /wg batch /good-first-issue /help-wanted 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
/cc Just something I noticed as I was testing some job in JobSet. It would be nice to see which jobs are suspended when doing . Hope its not a controversial change.
cc who worked on
Not controversial at all IMO /triage accepted
/assign
Any suggestions on where to place this column? I'm thinking between completions and durations. Or, should this be displayed only when the output is set to wide?
I would put it in the default view as well. Probably before completions
Addressed in the PR:
Change:
&ConfigMapList{}, ) <del> // Register Unversioned types under their own special group scheme.AddUnversionedTypes(Unversioned, &metav1.Status{}, &metav1.APIVersions{}, &metav1.APIGroupList{}, &metav1.APIGroup{}, &metav1.APIResourceList{}, ) </del> return nil }

Discussion:
We have moved to non-global schema in a number of places in 1.6 and 1.7. It is easy to forget registering the unversioned types like , leading to encoding errors in error cases. The registration of the unversioned types should be automatic as for the types, i.e. in .
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
do we need to close out this issue? (since referenced PR has merged)
Fixed by
Change:
create-network create-subnetworks detect-subnetworks <ins> create-cloud-nat-router </ins> write-cluster-location write-cluster-name create-autoscaler-config

Discussion:
Public IPs are expensive resources. Given that we're running scalability tests on 5k-node clusters, we are unnecessarily consuming 5k IPs which is a lot. We should switch our tests so that nodes have only private IP addresses. We are going to do that by configuring NAT so that nodes can talk to outside world (e.g. to download image from dockerhub). But that also requires changing some correctness tests which assume public IPs.
To summarize recent work: setting up private gce clusters with nat, feature is gated via the env test and dashboard with correctness tests on gce private cluster - https://k8s- 27 tests fail on fixing the tests - should fix majority of them
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 /lifecycle frozen
- is there anything missing to be done here?
No, we can close this one. It was done long time ago. Thanks for catching /close
Closing this issue. <detailsIn response to : No, we can close this one. It was done long time ago. Thanks for catching 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:
// Ingress resource create/read/update/watch verbs ginkgo.By("creating") <del> _, err := ingClient.Create(context.TODO(), ingTemplate, metav1.CreateOptions{}) </del> <ins> _, err := ingClient.Create(context.TODO(), ingress1, metav1.CreateOptions{}) </ins> framework.ExpectNoError(err) <del> _, err = ingClient.Create(context.TODO(), ingTemplate, metav1.CreateOptions{}) </del> <ins> _, err = ingClient.Create(context.TODO(), ingress2, metav1.CreateOptions{}) </ins> framework.ExpectNoError(err) <del> createdIngress, err := ingClient.Create(context.TODO(), ingTemplate, metav1.CreateOptions{}) </del> <ins> createdIngress, err := ingClient.Create(context.TODO(), ingress3, metav1.CreateOptions{}) </ins> framework.ExpectNoError(err) ginkgo.By("getting")

Discussion:
We run sonobuoy tests on production running clusters whenever we upgrade our clusters. We observe that fails when we already have nginx-ingress controller running in the cluster. The newer versions of nginx-ingress controller comes up with a validating admission webhook that validates the ingress definitions. In this specific test, we are creating 3 ingress objects with the same path and the webhook do not permit to create them (the first one is created but the other two would fail) and then the job fails. The tests shouldn't fail and it requires we create ingress objects using different paths instead. Install nginx-ingress controller from Run e2e test. Test fails. No response =1.19 n/a n/a n/a n/a n/a
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 testing /area e2e-test-framework
This is a duplicate, see the comment author of the ingress nginx controller explaining why this is working as expected Edit check again, maybe is not a duplicate
Thanks for pointing this. It's infact the same issue. But the fix above should hopefully help since it would create those ingress objects with different paths and the validating webhook for ingress controller would permit creating objects in that case.
yeah sorry, just checked quickly from the mobile, I will take a look Thanks
Change:
DiskMBpsReadWrite string } <del> func newManagedDiskController(common *controllerCommon) (*ManagedDiskController, error) { return &ManagedDiskController{common: common}, nil } </del> //CreateManagedDisk : create managed disk func (c *ManagedDiskController) CreateManagedDisk(options *ManagedDiskOptions) (string, error) { var err error

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: A storageAccount API call blocks kubelet from becoming Ready when there isn't any outbound IP, 1. eventually (after 10mins), the kubelet registers again... there is a call to the ARM API done by which blocks for 10mins, before letting kubelet complete with its starting logic and making the node as details: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.11.5 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
Change:
assert.True(t, strings.Contains(err.Error(), expectedErr)) assert.Empty(t, diskURI) } <del> func TestDeleteBlobDisk(t *testing.T) { ctrl := gomock.NewController(t) defer ctrl.Finish() b := GetTestBlobDiskController(t) b.common.cloud.BlobDiskController = &b mockSAClient := mockstorageaccountclient.NewMockInterface(ctrl) b.common.cloud.StorageAccountClient = mockSAClient fakeDiskURL := "fake" diskURL := "https://foo.blob./vhds/bar.vhd" err := b.DeleteBlobDisk(fakeDiskURL) expectedErr := fmt.Errorf("failed to parse vhd URI invalid vhd URI for regex https://(.*).blob./vhds/(.*): fake") assert.Equal(t, expectedErr, err) mockSAClient.EXPECT().ListKeys(gomock.Any(), b.common.resourceGroup, "foo").Return(storage.AccountListKeysResult{}, &retryError500) err = b.DeleteBlobDisk(diskURL) expectedErr = fmt.Errorf("no key for storage account foo, err Retriable: false, RetryAfter: 0s, HTTPStatusCode: 500, RawError: <nil>") assert.Equal(t, expectedErr, err) mockSAClient.EXPECT().ListKeys(gomock.Any(), b.common.resourceGroup, "foo").Return(storage.AccountListKeysResult{ Keys: &[]storage.AccountKey{ { KeyName: to.StringPtr("key1"), Value:   to.StringPtr("key1"), }, }, }, nil) b.accounts["foo"] = &storageAccountState{} err = b.DeleteBlobDisk(diskURL) expectedErrStr := "storage: service returned error: StatusCode=403, ErrorCode=AccountIsDisabled, ErrorMessage=The specified account is disabled." assert.Error(t, err) assert.True(t, strings.Contains(err.Error(), expectedErrStr)) } </del>

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: bazel-test-master Which test(s) are flaking: gotest: Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig cloud-provider
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 cloud-provider
ping !
Interestingly the expected test string was logged: Test:
Also unable to reproduce this, ran it a few thousand times:
Looks like a true flake. Does this need attention?
/assign
I cannot repro this failure either, while if it's really flacky, I could remove this ut since that's really legacy code, since it's azure blob disk code which is deprecated long time ago, remove ut is quite safe.
here is the PR to remove this flacky ut:
/assign
Change:
if err != nil { t.Fatalf("Failed to list pods: %v", err) } <del> if len(pods.Items) != 1 { t.Fatalf("Expect only 1 pod") </del> <ins> if len(pods.Items) > 1 { t.Fatalf("Unexpected pod list: %v", pods.Items) </ins> } // wait for the garbage collector to delete the pod if err := integration.WaitForPodToDisappear(podClient, garbageCollectedPodName, 5*time.Second, 30*time.Second); err != nil {

Discussion:
Had this test fail a few times on unrelated PRs in presubmit. Example failure: https://k8s- Possibly related to which recently merged. /kind flake cc
Change:
w := printers.GetNewTabWriter(printer.out) defer w.Flush() <ins> sort.Slice(metrics, func(i, j int) bool { return metrics[i].Name < metrics[j].Name }) </ins> printColumnNames(w, NodeColumns) var usage api.ResourceList for _, m := range metrics {

Discussion:
and node should sort by namespace / name so that results don't jump around. We should consider adding sort, but only after we make a stable sort the default.
next Also, why does it sometimes lose nodes? Annoying
I did not reproduce this. I think this may be caused by the monitoring timeout of heapster. So that the data got missing.
Change:
if !IsCRDConditionEquivalent(&tc.expectedcrdCondition[i], &crd.Status.Conditions[i]) { t.Errorf("%v expected %v, got %v", tc.name, tc.expectedcrdCondition, crd.Status.Conditions) } <ins> if crd.Status.Conditions[i].LastTransitionTime.IsZero() { t.Errorf("%q lastTransitionTime should not be null: %v", tc.name, i, crd.Status.Conditions) } </ins> } } }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: the for a CRDs Established condition is always null What you expected to happen: it should have a timestamp How to reproduce it (as minimally and precisely as possible): create a CRD and then examine its yaml/json. For example: Anything else we need to know?: Environment: community master
/assign
/area custom-resource
/sig api-machinery /area custom-resources
/assign
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
edit: actually, that issue is about kubectl display and clock skew. this issue is about the condition timestamp updating, which still requires correction
Closing this issue. <detailsIn response to : duplicate of 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
Hello I'm a bug triage shadow for the 1.16 release cycle and considering this issue is tagged for 1.16, I'd like to check its status. Code freeze is starting on August 29th (about 3 days from now), which means that this PR must merged by then. Do we still target this issue to be fixed for 1.16?
yes, will take a look at it tomorrow /assign
Change:
func NewMutatingWebhookConfigurationManager(f informers.SharedInformerFactory) generic.Source { informer := f.Admissionregistration().V1().MutatingWebhookConfigurations() manager := &mutatingWebhookConfigurationManager{ <del> configuration: &atomic.Value{}, lister:        informer.Lister(), hasSynced:     informer.Informer().HasSynced, </del> <ins> configuration:              &atomic.Value{}, lister:                     informer.Lister(), hasSynced:                  informer.Informer().HasSynced, initialConfigurationSynced: &atomic.Value{}, </ins> } // Start with an empty list manager.configuration.Store([]webhook.WebhookAccessor{}) <ins> manager.initialConfigurationSynced.Store(false) </ins> // On any change, rebuild the config informer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: Testgrid link: Example pass: Example fail: Reason for failure: Unknown Anything else we need to know: Looks like it's an apiserver test, but I'm not too sure. links to appreciated: <!-- Please see the deflaking doc () for more guidance! --/kind flake
Looks like is flaky too. Example fail:
/sig api-machinery
Thanks for the report. Please report individual failing tests/packages so the responsible sigs can be assigned. The cm/devicemanager issue is tracked in
/assign
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
I don't see individual issues yet, but I do see open PRs targeting this issue /remove-lifecycle rotten
closing in favor of specific issues: /close
Closing this issue. <detailsIn response to : closing in favor of specific issues: 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