jiebi/CodeConvo huggingface dataset:
Change:
} // Cloning fails if the source disk is still in the process of detaching, so we wait for the VolumeAttachment to be removed before cloning. volumeAttachment := e2evolume.GetVolumeAttachmentName(ctx, f.ClientSet, testConfig, l.testCase.Provisioner, dataSourceRef.Name, l.sourcePVC.Namespace) <del> e2evolume.WaitForVolumeAttachmentTerminated(ctx, volumeAttachment, f.ClientSet, f.Timeouts.DataSourceProvision) </del> <ins> framework.ExpectNoError(e2evolume.WaitForVolumeAttachmentTerminated(ctx, volumeAttachment, f.ClientSet, f.Timeouts.DataSourceProvision)) </ins> l.testCase.TestDynamicProvisioning(ctx) })

Discussion:
This line here lacks error checking: It shouldn't continue when that function times out. Add . No response <details</details<details</details<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 storage
in StorageClassTest.TestDynamicProvisioning also fails in that test.
/assign Looks like it only times out on my local branch. I'll investigate that. However, the error check is missing on master.
Fixed, and I'll add the error check in
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs 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 or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
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]:
The Kubernetes project currently lacks enough active 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 rotten [1]:
/remove-lifecycle rotten Fix is in
Change:
if err != nil { return err } <del> c.HealthzChecks = append(c.HealthzChecks, healthz.NamedCheck("etcd", func(r *http.Request) error { </del> <ins> c.AddHealthChecks(healthz.NamedCheck("etcd", func(r *http.Request) error { </ins> return healthCheck() }))

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: The and urls do not provide as much information about the cluster as much as does. It's expected to see and (if kms is enabled) but does not. What you expected to happen: and url to include and How to reproduce it (as minimally and precisely as possible): any 1.16 pre-release cluster the server url for , and Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: IBM OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others: Logs: healthz readyz livez /sig api-machinery
/sig api-machinery
/assign
Change:
return info } <ins> func (network hnsNetworkInfo) findRemoteSubnetProviderAddress(ip string) string { var providerAddress string for _, rs := range network.remoteSubnets { _, ipNet, err := net.ParseCIDR(rs.destinationPrefix) if err != nil { klog.Fatalf("%v", err) } if ipNet.Contains(net.ParseIP(ip)) { providerAddress = rs.providerAddress } if ip == rs.providerAddress { providerAddress = rs.providerAddress } } return providerAddress } </ins> type endpointsChange struct { previous proxyEndpointsMap current  proxyEndpointsMap

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: In Overlay mode, When 2 service has the same backend node IP, the LB was not programmed correctly causing datapath issues. What you expected to happen: Service data path to work properly How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: 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 network /sig windows These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
nc.deliverNamespace(namespace, nc.namespaceReviewDelay, false) } <del> func (nc *NamespaceController) delete(namespace *api_v1.Namespace) { </del> <ins> // delete  deletes the given namespace or returns error if the deletion was not complete. func (nc *NamespaceController) delete(namespace *api_v1.Namespace) error { </ins> // Set Terminating status. updatedNamespace := &api_v1.Namespace{ ObjectMeta: namespace.ObjectMeta,

Discussion:
In PR the specific resource types are handled explicitly. Need to delete them in more generic way, in a similar way that namespace controller does.
- switching this to 1.6 as it's too late for 1.5. ok? (please switch it right back if you disagree)
did fix this?
Please close or move to next-candidate with work remaining to be done.
Yes fixed by
Change:
return fields[len(fields)-1] } <del> func determineRequestedIP(svc *v1.Service, fwdRule *compute.ForwardingRule) string { </del> <ins> // ilbIPToUse determines which IP address needs to be used in the ForwardingRule. If an IP has been // specified by the user, that is used. If there is an existing ForwardingRule, the ip address from // that is reused. In case a subnetwork change is requested, the existing ForwardingRule IP is ignored. func ilbIPToUse(svc *v1.Service, fwdRule *compute.ForwardingRule, requestedSubnet string) string { </ins> if svc.Spec.LoadBalancerIP != "" { return svc.Spec.LoadBalancerIP } <del> if fwdRule != nil { return fwdRule.IPAddress </del> <ins> if fwdRule == nil { return "" </ins> } <del> return "" </del> <ins> if requestedSubnet != fwdRule.Subnetwork { // reset ip address since subnet is being changed. return "" } return fwdRule.IPAddress </ins> } func getILBOptions(svc *v1.Service) ILBOptions { <del> return ILBOptions{AllowGlobalAccess: GetLoadBalancerAnnotationAllowGlobalAccess(svc)} </del> <ins> return ILBOptions{AllowGlobalAccess: GetLoadBalancerAnnotationAllowGlobalAccess(svc), SubnetName: GetLoadBalancerAnnotationSubnet(svc), } </ins> } // forwardingRuleComposite is a composite type encapsulating both the GA and Beta ForwardingRules.

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: ILB ip addresses come from the subnet that the K8s cluster uses. There is no ability to specify a different subnet. What you expected to happen: ILB ip addresses should be allocated from a different subnet if specified. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: GCE OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/area platform/gce /assign
/sig network
Change:
newPath := field.NewPath("KubeProxyConfiguration") successCases := []kubeproxyconfig.ProxyMode{ kubeproxyconfig.ProxyModeUserspace, <del> kubeproxyconfig.ProxyModeIPTables, kubeproxyconfig.ProxyModeIPVS, </del> kubeproxyconfig.ProxyMode(""), } <ins> if runtime.GOOS == "windows" { successCases = append(successCases, kubeproxyconfig.ProxyModeKernelspace) } else { successCases = append(successCases, kubeproxyconfig.ProxyModeIPTables, kubeproxyconfig.ProxyModeIPVS) } </ins> for _, successCase := range successCases { if errs := validateProxyMode(successCase, newPath.Child("ProxyMode")); len(errs) != 0 { t.Errorf("expected success: %v", errs)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When running , and passing the flag which was introduced in , the following error occurs: What you expected to happen: The proxy should work as it used to, supporting this mode. How to reproduce it (as minimally and precisely as possible): ./kube- --proxy-mode=kernelspace Anything else we need to know?: This was introduced after the validation was refactored in which regressed validation for . IPVS validation (and thus support) was later , but we need another mode for Windows. Environment: Kubernetes version (use ): v1.10.0-alpha.0.684+ Cloud provider or hardware configuration: n/a OS (e.g. from ): Windows Server Core 1709 Kernel (e.g. ): Install tools: Others:
/sig windows /sig network
Tentatively adding milestone so we can track getting consensus on release-blocking status.
/priority critical-urgent
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. <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:
### Avoiding Collisions in IP allocation to Services Kubernetes 1.24 introduced a new opt-in feature that allows you to <del> [soft-reserve a range for static IP address assignments](/docs/concepts/services-networking/service/#service-ip-static-sub-range) </del> <ins> [soft-reserve a range for static IP address assignments](https://kubernetes.io/docs/concepts/services-networking/service/#service-ip-static-sub-range) </ins> to Services. With the manual enablement of this feature, the cluster will prefer automatic assignment from the pool of Service IP addresses thereby reducing the risk of collision.

Discussion:
has some broken links. These are relative links that work OK in the release blog article but need to be absolute hyperlinks in the release notes. Links in release notes work. Visit Click on all the links. Specifically, “this guide” in (there are some more, this is one example) No response v1.24.0 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 release and IMO /priority important-soon
Hi Tim, I can help fix this /assign
Change:
Args: []string{ "/bin/sh", "-c", <del> fmt.Sprintf("for i in $(seq 1 5); do curl -s -m 8 %s.%s:%d && exit 0 || sleep 1; done; exit 1", </del> <ins> fmt.Sprintf("for i in $(seq 1 5); do nc -vz -w 8 %s.%s %d && exit 0 || sleep 1; done; exit 1", </ins> targetService.Name, targetService.Namespace, targetPort), }, },

Discussion:
What happened: I wanted to run the e2e network policy tests with: and I noticed that all tests are failing (I actually don't know why nobody has noticed this before). Looking into the logs I saw the following errors: which are correct because the tests using as "client" which doesn't contain . What you expected to happen: The e2e tests for network policies should actually pass. How to reproduce it (as minimally and precisely as possible): Just run: Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: kind OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig testing
With the current fix two tests are still failing: I will take a look and fix these failing tests too.
Seems to be an implementation error on the network plugin side (tested with weave latest and calico 3.6). I will investigate some time in the implementation details on the calico side. But this error/failures are no blocker for the PR from my perspective.

As far as I know the busybox image doesn't contain , only so I don't understand how the PR that changed from to has passed the CI What happened: 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 ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /kind bug cc
/sig network
NetworkPolicy tests are a and so don't get run by default. But I imagine at least some of the CI test environments implement NetworkPolicy (e2e-gce?) so probably we should fix that. So 2 fixes: Make the tests pass again; probably requires changing the test image from busybox to something else. I bet there are other tests in that they switched from wget to curl where they did remember to change the image (because the tests would have failed otherwise) so this should just be a matter of seeing what image they used there, and use it here too. Make at least one of the CI tests test NetworkPolicy /good-first-issue (at least the first part anyway)
/remove-good-first-issue /remove-help (after someone asked me about this, I realized that trying to run tests that don't get run by CI is kind of complicated...)
Change:
volumeSpec.Name(), uniquePodName, err) <ins> allVolumesAdded = false </ins> } glog.V(10).Infof(

Discussion:
Deployment/Service manifest: logs from events: In aws, the volume is attached, On the box: In only one is mounted: Where can I debug this further?
Take a look at the on your master for events related to your volume . That will show you when the volume was attached/detached. It appears that your volume attached without issue so there should be nothing unusual here. Then take a look at on the node that the volume is supposed to be attached to. Looks for the UID of your pod (). I suspect one of your mounts is failing. It looks like you are using hyperkube so it might be a mount namespace propagation issue.
I believe this happens when the RC/Pod is being created shortly after the PV or PVC. The latter two appear to need several seconds to be fully available (even if the status is already set to "Bound"). I ran into the same issue with a NFS PV. When I delete and create PV+PVC+SVC+RC all in one go, the associated Pod will be in ContainerCreating state for several seconds (10,<60), then log the warning event and afterwards be created without any problems or further delays. When I first create PV+PVC, wait for several seconds (30) and only then create SVC+RC, the pod will be created immediately and no warning event will be logged. One oddity I noticed is that the PVC will have capacity 0 and empty access modes (as shown by ), even though it was setup to request ROX for 1Gi and the PV provides 1Gi with ROX. This might be a different bug, though.
Thanks for digging into it The capacity 0 issue () was fixed by PR and is in v1.3.5. This is more or less expected behavior. The mount logic has exponential backoff so if it rapidly encounters PVC/PV does not exist, it'll back off the retries resulting in a longer mount time. We can consider optimizing this particular scenario. But I'll lower the priority on this for now and remove the milestone.
Maybe the "Bound" status could be delayed, so the RC would be held back for a while and be scheduled only when the PVC is actually ready?
I don't think the RC actually waits for PVC to be bound before scheduling.

I have also this problem using deployment with HELM, I deploy all my pv,pvc,deploy,svc in one Charts, and my pod who requiere a volume from the PVC get scheduled and stay in ContainerCreating mode. I need to wait minutes or delete pods for they correctly get rescheduled using the volume. Here is the log when the pod get automaticly deleted (after minutes) : It would be awesome if the deployment or RC wait for the PVC to be bound before schedule !
may slightly improve this situation as the maximum backoff time of 2 minutes will not fire anymore.
Note that the same error is thrown when node-size == C5 or M5 for kubectl and with kops . Solution is to set node as t2 machines. Due to it seems.
Reading from the new solution is:
Change:
t.Errorf("Expected %#v, Got %#v", 2, lastIndex) } update := (<-ch).(kubelet.PodUpdate) <del> expected := CreatePodUpdate(kubelet.SET, kubelet.Pod{Name: "foo", Manifest: api.ContainerManifest{ID: "foo"}}) </del> <ins> expected := CreatePodUpdate(kubelet.SET, kubelet.Pod{Name: "foo", Manifest: manifest}) </ins> if !reflect.DeepEqual(expected, update) { t.Errorf("Expected %#v, Got %#v", expected, update) } <ins> for i := range update.Pods { if errs := kubelet.ValidatePod(&update.Pods[i]); len(errs) != 0 { t.Errorf("Expected no validation errors on %#v, Got %#v", update.Pods[i], errs) } } </ins> } func TestWatchEtcd(t *testing.T) {

Discussion:
The hash function generates names with upper-case letters, but the validation only allows lower-case. First, we clearly need a test for this. Second, we need to fix it. Should we allow upper-case characters (which the RFC does allow for DNS labels) or should we fix the hash? Allowing upper-case seems attractive, except that the RFC also says that case doesn't matter, but should be preserved "wherever possible". So we really have three choices, I see. a) only allow lower-case b) allow upper-case and always use caseless comparisons everywhere c) allow upper-case, but normalize to lower-case since it was your hash code
Re: test - sounds like a config source -config integration test, which I'll add. Re: hash - would argue we should fix the hash to generate lowercase for now. I think, but will double check, that the collision space is still improbably low for 63 lowercase chars. I can do that shortly.
And a validate test on all sources.
Lowercase would require base32, rather than base64, no? On Aug 3, 2014 8:20 AM, "Clayton Coleman" wrote:
Yeah, although I don't believe there's a difference to the outcome between base32 and base64(lowercase) given an appropriate hash function.
Well, base32 is reversible and a modified base64is not :) On Aug 3, 2014 9:00 AM, "Clayton Coleman" wrote:
Remind me again why reversibility is important? We discussed it in another issue but I can't find the context.
I'm going to change the generated name to which even with 2^8 files per host and a thousand hosts should be well below 0.% chance of collision
Its only important if we want to use it. We don't AFAIK. On Aug 3, 2014 9:34 AM, "Clayton Coleman" wrote:
Fix makes them unique, somewhat traceable (first 15 safe chars of the name), and generates base32 output.
Change:
`, }, { <ins> name: "nil node metrics", summary: &statsapi.Summary{ Node: statsapi.NodeStats{ CPU: &statsapi.CPUStats{ Time:                 testTime, UsageCoreNanoSeconds: nil, }, Memory: &statsapi.MemoryStats{ Time:            testTime, WorkingSetBytes: nil, }, }, }, summaryErr: nil, expectedMetrics: ` # HELP scrape_error [ALPHA] 1 if there was an error while getting container metrics, 0 otherwise # TYPE scrape_error gauge scrape_error 0 `, }, { </ins> name: "arbitrary container metrics for different container, pods and namespaces", summary: &statsapi.Summary{ Pods: []statsapi.PodStats{

Discussion:
kubelet panic when accessing metrics/resource endpoint kubelet log kubelet works fine access metrics/resource endpoint of kubelet No response <details</details<details</details<details</details<details</details<detailsINFO[2022-07-14 05:36:21.474173892Z] Starting CRI-O, version: 1.23.0, git: (dirty) Version: 1.23.0 GitCommit: GitTreeState: dirty BuildDate: 1980-01-01T00:00:00Z GoVersion: go1.17.4 Compiler: gc Platform: linux/amd64 Linkmode: static BuildTags: apparmor, excludegraphdriverdevicemapper, seccomp, selinux SeccompEnabled: true AppArmorEnabled: true </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
/assign
/sig node
Change:
"strings" "k8s.io/apimachinery/pkg/api/meta" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/apimachinery/pkg/util/validation" ) // FormatMap formats map[string]string to a string. func FormatMap(m map[string]string) (fmtStr string) { <del> for key, value := range m { fmtStr += fmt.Sprintf("%v=%qn", key, value) </del> <ins> // output with keys in sorted order to provide stable output keys := sets.NewString() for key := range m { keys.Insert(key) } for _, key := range keys.List() { fmtStr += fmt.Sprintf("%v=%qn", key, m[key]) </ins> } fmtStr = strings.TrimSuffix(fmtStr, "n")

Discussion:
/kind bug What happened: When using the downward api to render a file via a volume mount from and annotation that has newlines in it, it appears that the file is rendered with the content sorted by line. A concrete example: Expected is that would contain But it does not The above is obviously contrived, this is creating a problem for my team when we are trying to use the downward api to render a yaml file (which obviously has newlines) Environment: Kubernetes version (use ): 1.9.7 Cloud provider or hardware configuration: aws OS (e.g. from /etc/os-release): centos
/sig apps Not sure about the sig here
/sig node /sig storage
Just tested it on 1.10.5 and this bug still happens.
thanks!
Change:
import ( "fmt" <ins> autoscalingv1 "k8s.io/kubernetes/pkg/apis/autoscaling/v1" </ins> "k8s.io/kubernetes/test/e2e/common" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
Currently the time it takes for HPA and CA to scale up after load increase is not measured at all, and this can lead to regressions that will be missed. This issue is about adding an e2e test that will prevent such regressions.
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 .
Filip, can you reopen? I cannot do this myself, and this issue is clearly not closed yet.
Thanks Wojtek!