jiebi/CodeConvo huggingface dataset:
Change:
// read or write a certificate stored/embedded in a file type certificateReadWriter interface { //Exists return true if the certificate exists <del> Exists() bool </del> <ins> Exists() (bool, error) </ins> // Read a certificate stored/embedded in a file Read() (*x509.Certificate, error)

Discussion:
When the command is run with superuser privileges, it prints the requested information. Print a warning that files could not be read due to insufficient permission, or that information was missing (e.g., when the /etc/kubernetes directory is not initialized). When the directory is readable, it works as expected: where OS and kubeadm version detail was: Issue the command as a normal user when the directory /etc/kubernetes/pki exists but not readable. No response <details</details<detailsBare metal </details<details</details<detailsapt-get install kubeadm (source repo: ) </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 cluster-lifecycle
Change:
func waitForInformerSync(ctx context.Context, t *testing.T, informer cache.SharedIndexInformer, wantSynced bool, lastSyncResourceVersion string) { t.Helper() <del> syncCtx, cancel := context.WithTimeout(ctx, time.Second*30) </del> <ins> syncCtx, cancel := context.WithTimeout(ctx, time.Second*60) </ins> defer cancel() if gotSynced := cache.WaitForCacheSync(syncCtx.Done(), informer.HasSynced); wantSynced != gotSynced { t.Fatalf("wanted sync %t, got sync %t", wantSynced, gotSynced) } if len(lastSyncResourceVersion) != 0 { <del> if err := wait.PollImmediate(time.Second, time.Second*30, func() (bool, error) { </del> <ins> if err := wait.PollImmediate(time.Second, time.Second*60, func() (bool, error) { </ins> return informer.LastSyncResourceVersion() != lastSyncResourceVersion, nil }); err != nil { t.Fatalf("informer never changed resource versions from %q: %v", lastSyncResourceVersion, err)

Discussion:
wanted sync true, got sync false wanted sync true, got sync false wanted sync true, got sync false informer never changed resource versions from "": timed out waiting for the condition /kind failing-test /kind flake as it is in /sig auth Open it as it is the top flake of pull-kubernetes-integration:
Commented on PR.
/triage accepted
I've seen this test fail 2 times today on my PR Going to hope that I close my eyes and and never see it if it happens again I'll reopen this...
!
Opened to track flakes once again
Change:
if err := rest.BeforeUpdate(e.UpdateStrategy, ctx, obj, existing); err != nil { return nil, nil, err } <ins> // Ignore changes that only affect managed fields timestamps. // FieldManager can't know about changes like normalized fields, defaulted // fields and other mutations. obj, err = fieldmanager.IgnoreManagedFieldsTimestampsTransformer(ctx, obj, existing) if err != nil { return nil, nil, err } </ins> // at this point we have a fully formed object.  It is time to call the validators that the apiserver // handling chain wants to enforce. if updateValidation != nil {

Discussion:
Sending a patch built from a typed client to SSA will force a write to etcd (and bump resourceVersion) since creationTimestamp is serialized to null. This is a follow-up of which doesn't solve the issue properly. Sending a no-op SSA request with creationTimestamp to null shouldn't do anything Kubectl apply an object with creationTimestamp null twice and see that it updates the object. Probably something like this would cause it:
/sig api-machinery /wg api-expression /triage accepted /assign /priority important-soon
Change:
subsets                  []corev1.EndpointSubset epLabels                 map[string]string epAnnotations            map[string]string <ins> uid                      string </ins> endpointsDeletionPending bool maxEndpointsPerSubset    int32 existingEndpointSlices   []*discovery.EndpointSlice

Discussion:
create a service without selector, and manual create endpoints for this service endpointslicemirroring controller will create an endpointslice for this service. after endpoint slice created, and kube-controller-manager restart. during the kube-controller-manager restart, the endpoint was deleted and recreated after kube-controller-manager restart, garbagecollector controller delete this endpointslice and endpointslice not recreate until endpoint/service update event or kube-controller-manager restart endpointslice will be recreated create a service without selector, and manual create endpoints for this service endpointslicemirroring controller will create an endpointslice for this service. after endpoint slice created, and kube-controller-manager restart. during the kube-controller-manager restart, the endpoint was deleted and recreated No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig network
/assign
Trying to understand this, mostly just restating what you've said above to make sure I'm getting it: during the kube-controller-manager restart, the endpoint was deleted and recreated after kube-controller-manager restart, garbagecollector controller delete this endpointslice and endpointslice not recreate until endpoint/service update event or kube-controller-manager restart So an Endpoints resource is being deleted while kube-controller-manager is not running. The EndpointSlice mirroring controller to point to the Endpoints they're mirroring. When kube-controller-manager is restarted, the garbage collector will delete the mirrored EndpointSlice because it's owned by an Endpoints resource that was previously deleted. That deletion by garbage collection would then be , but if the EndpointSliceTracker doesn't think it should have that resource, it will ignore the deletion and not reconcile, resulting in the mirrored EndpointSlice not being recreated until something updates the Service or Endpoints resource.
/triage accepted
Change:
stopCh := make(chan struct{}) defer close(stopCh) go gc.Run(1, stopCh) <del> go gc.Sync(fakeDiscoveryClient, 10*time.Millisecond, stopCh) </del> <ins> // The pseudo-code of GarbageCollector.Sync(): // GarbageCollector.Sync(client, period, stopCh): //    wait.Until() loops with `period` until the `stopCh` is closed : //        wait.PollImmediateUntil() loops with 100ms (hardcode) util the `stopCh` is closed: //            GetDeletableResources() //            gc.resyncMonitors() //            controller.WaitForCacheSync() loops with `syncedPollPeriod` (hardcoded to 100ms), until either its stop channel is closed after `period`, or all caches synced. // // Setting the period to 200ms allows the WaitForCacheSync() to check for cache sync ~2 times in every wait.PollImmediateUntil() loop. go gc.Sync(fakeDiscoveryClient, 200*time.Millisecond, stopCh) </ins> // Wait until the sync discovers the initial resources fmt.Printf("Test output")

Discussion:
Users of the function would expect the close of the "done" channel should terminate the . We should change the function to align to users' expectation. We should document what the channel does. This is a behavior change, to be cautious, we should add a release note claiming breaking change. /kind bug
/sig api-machinery cc Feel free to assign to yourself if you have time. Otherwise I'll attempt a fix tomorrow ;)
I'll fix it. /assign
GitHub didn't allow me to assign the following users: kdada. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : I'll fix it. 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
Change:
Scaling foo-v2 up to 20 Scaling foo-v1 down to 0 `, <ins> }, { name:        "1->1 0/1 scale down unavailable rc to a ready rc (rollback)", oldRc:       oldRc(1, 1), newRc:       newRc(1, 1), newRcExists: true, maxUnavail:  intstr.FromInt(0), maxSurge:    intstr.FromInt(1), expected: []interface{}{ up{1}, down{oldReady: 0, newReady: 1, to: 0}, }, output: `Continuing update with existing controller foo-v2. Scaling up foo-v2 from 1 to 1, scaling down foo-v1 from 1 to 0 (keep 1 pods available, don't exceed 2 pods) Scaling foo-v1 down to 0 `, </ins> }, }

Discussion:
I intentionally cause the rolling update to fail by specifying a non-existent image in the spec, so that it times out. rollback then fails with a timeout as well, despite the original replication controller having 1 healthy replica: This is on 1.1.2. I expect the rollback to succeed as the original rc (copper) has 1 healthy replica still.
With 2 replicas the rollback seems to work as expected.
I found the bug inside of the function of . It erroneously assumes reducing replicas on scale down will always drop the minimum available, when this isn't the case if you are rolling back from a failed deployment (where the scale down will be on the NotReady/failed pods). It needs to consider not ready replicas as well in each RC when deciding if it can scale down. This test case illustrates the problem:
Change:
"golang.org/x/net/html/atom" "k8s.io/klog/v2" <ins> "k8s.io/apimachinery/pkg/api/errors" </ins> "k8s.io/apimachinery/pkg/util/net" "k8s.io/apimachinery/pkg/util/sets" )

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: I upgraded from 1.15 and am using prometheus to scrape my pods via the proxy functionality. Previously no error message was being printed, now with 1.19.9 every try results in an error: Example url: https://x.x.x.x:6443/api/v1/namespaces/staging/pods/proxy-app--6sxfx:80/proxy/metrics What you expected to happen: No error message to be logged, since the apiserver anyways returns a corresponding http error code. The least thing I would expect it not to log as an error, but as a debug or info log, since it doesn't actually represent an error. It returns something like that: How to reproduce it (as minimally and precisely as possible): Call the proxy functionality on an endpoint that does not listen and will refuse the connection. Anything else we need to know?: There is a lot of other issues with a similar error message, but I believe they are not interconnected since this has explicitly todo with an error raised from the proxy functionality. Environment: Kubernetes version (use ): 1.19.9 Cloud provider or hardware configuration: on premise OS (e.g: ): CentOs 7 Kernel (e.g. ): 5.4.60
/sig api-machinery
/cc /triage accepted
/assign
Change:
"//vendor/k8s.io/api/core/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/api/resource:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", <ins> "//vendor/k8s.io/apimachinery/pkg/types:go_default_library", </ins> "//vendor/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//vendor/k8s.io/client-go/util/testing:go_default_library", ],

Discussion:
This bug affects any pod that has a container with a nested volume (any type) beneath an API data volume, such as a secret, configMap, downwardAPI or projected volume. In the description and reproduction details below I use a secret volume, but any of the four will demonstrate this behavior. Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When creating a pod with nested secrets volumes (e.g. one volume mounted at and one mounted at ), the container fails to start with an error like: What you expected to happen: The container should start with both and mounted. How to reproduce it (as minimally and precisely as possible): out master, any version since a file with 2 secrets and a pod that makes volumes for the 2 secrets, with one of them mounted within the other: the 2 secrets and the pod. Assuming you named the above file : Anything else we need to know?: This may work for other runtimes if they create mountpoints outside of the sandbox. But it's definitely broken with Docker as the runtime.
This should be fixed by /sig storage /sig node /assign
Change:
Runonce                 bool } <del> func createAndInitKubelet(kc *KubeletConfig, pc *config.PodConfig) *kubelet.Kubelet { </del> <ins> func createAndInitKubelet(kc *KubeletConfig, pc *config.PodConfig) (*kubelet.Kubelet, error) { </ins> // TODO: block until all sources have delivered at least one update to the channel, or break the sync loop // up into "per source" synchronizations <del> k := kubelet.NewMainKubelet( </del> <ins> k, err := kubelet.NewMainKubelet( </ins> kc.Hostname, kc.DockerClient, kc.EtcdClient,

Discussion:
Things like SyncFrequency should have a lower-bound of acceptable, and that really should be 0ns.
The main point of this is now fixed, though we could be better about input checking all over
Change:
numNodes, err := e2enode.TotalRegistered(f.ClientSet) framework.ExpectNoError(err) replicas := int32(numNodes) <del> common.NewRCByName(c, ns, name, replicas, &gracePeriod) </del> <ins> common.NewRCByName(c, ns, name, replicas, &gracePeriod, []string{"serve-hostname"}) </ins> err = e2epod.VerifyPods(c, ns, name, true, replicas) framework.ExpectNoError(err, "Each pod should start running and responding")

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes Since when has it been failing: These tests have been failing since 6/28 Failures coincide with the following changes: Testgrid link: Reason for failure: The failure messages look as follows: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes /cc /milestone v1.16 /priority critical-urgent /kind failing-test /cc
/sig cluster-lifecycle
For more context, the code for the failing tests is here The error for both comes through  - some Pod is not responding. It is failing to find pods prefixed with "my-hostname-add-node". Within the logs we can see this: So the Pods are stuck in a Pending state. The Pods are supposed to be created by a ReplicationController in , which itself uses this method from the e2e framework . However, after being in a Pending state (after the "failed to wait for pods responding: timed out waiting for the condition" error is registered), they do seem to reach a Ready state
/assign for triage.
I think agnhost needs to be passed , but did not do so in /assign sig-testing
GitHub didn't allow me to assign the following users: sig-testing. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : I think agnhost needs to be passed , but did not do so in 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
Reopen to monitor job /reopen
Reopened this issue.

<detailsIn response to : Reopen to monitor job /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
Thank you for working on the PR to solve this. indeed solved the issue reported here. /close
Closing this issue. <detailsIn response to : Thank you for working on the PR to solve this. /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:
for _, group := range groups { if !s.isGroupValid(group) { <del> detail := fmt.Sprintf("%d is not an allowed group", group) </del> <ins> detail := fmt.Sprintf("group %d must be in the ranges: %v", group, s.ranges) </ins> allErrs = append(allErrs, field.Invalid(field.NewPath(s.field), groups, detail)) } }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: This is request for improvements. What happened: When PodSecurityPolicy provider validates or fields of a pod, it shows an error like "999 is not an allowed group" if the group doesn't belong to the range(s). What you expected to happen: It should include to the error message also the allowed values -- the ranges against what we were validating this group. This will simplify user experience and debugging. How to reproduce it (as minimally and precisely as possible): run kubernetes cluster with PSP support create a PSP that allows fsGroup/SupplementalGroups in some ranges grant to a user access to this PSP try to create a pod that has fsGroup/SupplementalGroups outside of the allowed ranges Anything else we need to know?: In order to improve the current behavior, we need to modify function here: Reported-by: /kind help
This looks like a good first issue! My suggestion would be something like . I would also suggest to merge overlaying ranges in the log message, like as , to keep the log as concise as possible. I will look into it.
Maybe something like ? Thank you!
We can use the same approach that strategy uses:
Sure, that is probably the most consistent solution.
/remove-help
Change:
if err != nil { return nil, err } <ins> serviceTags, err := getServiceTags(service) if err != nil { return nil, err } </ins> var sourceAddressPrefixes []string <del> if sourceRanges == nil || serviceapi.IsAllowAll(sourceRanges) { </del> <ins> if (sourceRanges == nil || serviceapi.IsAllowAll(sourceRanges)) && len(serviceTags) == 0 { </ins> if !requiresInternalLoadBalancer(service) { sourceAddressPrefixes = []string{"Internet"} }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When using the loadBalancerSourceRanges property of a service in a manifest, we are force to use a CIDR block. This was discovered while debugging the following issue. What you expected to happen: Azure allows us to use Service Tags (e.g. VirtualNetwork, Internet, etc) WE should be able to specify them form a k8s service manifest. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.11 Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): centOS 7.3 Kernel (e.g. ): 3.10 Install tools: Others:
/sig azure
Here's the requested Feature.
SourceRanges is part of service spec, while serviceTag is azure specific. I think we don't expect to add cloud-specific features into Kubernetes API. What about adding a new annotation for this? e.g.
I believe that at this stage, (no out of tree cloud provider logic), using an annotation would be the only way to go unfortunately.
/priority important-soon
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : New functionality. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
// maxTries == minTries will confirm that we see the expected endpoints and no // more for maxTries. Use this if you want to eg: fail a readiness check on a // pod and confirm it doesn't show up as an endpoint. <del> func (config *NetworkingTestConfig) DialFromContainer(protocol, dialCommand, containerIP, targetIP string, containerHTTPPort, targetPort, maxTries, minTries int, expectedResponses sets.String) { </del> <ins> // Returns nil if no error, or error message if failed after trying maxTries. func (config *NetworkingTestConfig) DialFromContainer(protocol, dialCommand, containerIP, targetIP string, containerHTTPPort, targetPort, maxTries, minTries int, expectedResponses sets.String) error { </ins> ipPort := net.JoinHostPort(containerIP, strconv.Itoa(containerHTTPPort)) cmd := makeCURLDialCommand(ipPort, dialCommand, protocol, targetIP, targetPort)

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