jiebi/CodeConvo huggingface dataset:
Change:
driverInfo DriverInfo } <del> var _ TestDriver = &hostpathSymlinkDriver{} var _ PreprovisionedVolumeTestDriver = &hostpathSymlinkDriver{} var _ InlineVolumeTestDriver = &hostpathSymlinkDriver{} </del> <ins> var _ TestDriver = &hostPathSymlinkDriver{} var _ PreprovisionedVolumeTestDriver = &hostPathSymlinkDriver{} var _ InlineVolumeTestDriver = &hostPathSymlinkDriver{} </ins> <del> // InitHostpathSymlinkDriver returns hostpathSymlinkDriver that implements TestDriver interface func InitHostpathSymlinkDriver() TestDriver { return &hostpathSymlinkDriver{ </del> <ins> // InitHostPathSymlinkDriver returns hostPathSymlinkDriver that implements TestDriver interface func InitHostPathSymlinkDriver() TestDriver { return &hostPathSymlinkDriver{ </ins> driverInfo: DriverInfo{ <del> Name:        "hostpathSymlink", </del> <ins> Name:        "hostPathSymlink", </ins> MaxFileSize: testpatterns.FileSizeMedium, SupportedFsType: sets.NewString( "", // Default fsType

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?: https://k8s- What happened: The skip check for hostpath doesn't seem to be working for these test cases
can you take a look?
Oh, disruptive tests are the tests that can't be tested locally in my environment due to I will take a look.
I found that above issue is not related, I should have been checked more carefully. Sorry for that.
I found out that this was just a driver name issue, so below will fix it: hostpath -hostPath hostpathSymlink -hostPathSymlink We might be better changing the skip logic later, to make it skip not by name in order to avoid this kind of bug, though. I will make a PR for above change, soon.
I made a PR above. Also, it might be a bit out of scope of this fix, but are drivers tested with containerized volume server, like nfs, ceph, etc..., safe to be tested with subpath disruptive tests? I'm worrying about the case that test pod and containerized volume server are deployed on the same node. In such a case, the same behaviour expected or do we need to avoid this kind of situation?
Change:
if mounter.(*nfsMounter).readOnly { t.Errorf("The volume source should not be read-only and it is.") } <ins> mntDevs, err := fake.List() if err != nil { t.Errorf("fakeMounter.List() failed: %v", err) } if len(mntDevs) != 1 { t.Errorf("unexpected number of mounted devices. expected: %v, got %v", 1, len(mntDevs)) } else { if mntDevs[0].Type != "nfs" { t.Errorf("unexpected type of mounted devices. expected: %v, got %v", "nfs", mntDevs[0].Type) } if mntDevs[0].Device != expectedDevice { t.Errorf("unexpected nfs device, expected %q, got: %q", expectedDevice, mntDevs[0].Device) } } </ins> log := fake.GetLog() if len(log) != 1 { t.Errorf("Mount was not called exactly one time. It was called %d times.", len(log))

Discussion:
In bare-metal IPv6 environment, any pod consuming storage resource is not able to run. The storage should be consumable, and the pod should become in status. Running the in a bare-metal IPv6 configurations. I have replaced the cloud-based storage resource with a mounted to a folder on my localhost. Steps alongside logs are below :- $kubectl get svc $kubectl describe svc nfs-server $kubectl describe pv nfs $kubectl get pod -w $kubectl get pod -w $kubectl describe pod nfs-busybox-6r96h I have built the master branch to make sure it was not fixed up to this moment.
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
/sig storage /tirage accepted /assign
Change:
<ins> #!/bin/sh # Copyright 2015 The Kubernetes Authors. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Install prerequisites. apt-get update apt-get install -y -q --no-install-recommends  curl ca-certificates make g++ sudo bash # Install Fluentd. /usr/bin/curl -sSL https://toolbelt.treasuredata.com/sh/install-ubuntu-xenial-td-agent2.sh | sh # Change the default user and group to root. # Needed to allow access to /var/log/docker/... files. sed -i -e "s/USER=td-agent/USER=root/" -e "s/GROUP=td-agent/GROUP=root/" /etc/init.d/td-agent # Install the Elasticsearch Fluentd plug-in. # http://docs.fluentd.org/articles/plugin-management td-agent-gem install --no-document fluent-plugin-kubernetes_metadata_filter -v 0.24.0 td-agent-gem install --no-document fluent-plugin-elasticsearch -v 1.5.0 # Remove docs and postgres references rm -rf /opt/td-agent/embedded/share/doc  /opt/td-agent/embedded/share/gtk-doc  /opt/td-agent/embedded/lib/postgresql  /opt/td-agent/embedded/bin/postgres  /opt/td-agent/embedded/share/postgresql apt-get remove -y make g++ apt-get autoremove -y apt-get clean -y rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* </ins>

Discussion:
It's 400+mb and we need to pull it on every node. This leads to a lot of image pulling flake (), and also gets very expensive in some countries where bandwidth is sold at a premium. We took a stab at halving the size with: , but then realized that we were using an unsupported base image We tried to optimize to ~300Mb by building a smaller ubuntu:15 base, but that's still huge. Every other mandatory system daemon is built on busybox and so takes ~10Mb.
I can try again now that the agent supports
Newer Docker images using the spec from the official repository are based on AlpineLinux and are around ~38MB:
Change:
fi } <del> # Verify and find the various tar files that we are going to use on the server. # # Vars set: #   SERVER_BINARY_TAR #   SALT_TAR function find-release-tars { SERVER_BINARY_TAR="${KUBE_ROOT}/server/kubernetes-server-linux-amd64.tar.gz" if [[ ! -f "$SERVER_BINARY_TAR" ]]; then SERVER_BINARY_TAR="${KUBE_ROOT}/_output/release-tars/kubernetes-server-linux-amd64.tar.gz" fi if [[ ! -f "$SERVER_BINARY_TAR" ]]; then echo "!!! Cannot find kubernetes-server-linux-amd64.tar.gz" exit 1 fi SALT_TAR="${KUBE_ROOT}/server/kubernetes-salt.tar.gz" if [[ ! -f "$SALT_TAR" ]]; then SALT_TAR="${KUBE_ROOT}/_output/release-tars/kubernetes-salt.tar.gz" fi if [[ ! -f "$SALT_TAR" ]]; then echo "!!! Cannot find kubernetes-salt.tar.gz" exit 1 fi } </del> # Take the local tar files and upload them to S3.  They will then be # downloaded by the master as part of the start up script for the master. #

Discussion:
I suspect we're going through an if/else clause where KUBETARURL isn't defined, and not defaulting it, though the function header seems to indicate it should be set in the callee.
Will take a look.
Is this in Jenkins, or on a local run? The Jenkins push job is borked as well, but it looks like it's for a different reason: Which I'm taking care of in .
Jobs are generating incredibly large log files (300 Megs?) with lots of repeated lines like this: Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 /jenkins-master-data/jobs/kubernetes-push-gce-step1-deploy/workspace/kubernetes/hack/e2e-internal/../../cluster/../cluster/../c line 283: KUBETARURL: unbound variable Failure trying to curl release .sha1 I think this needs to be resolved, since it already caused an out-of-disk in Jenkins.
Okiedokie. Yes, this was my fault. silently expects and to be set in . I the extra expectation that be set, but didn't think about how would then also have to set that. Working on a fix.
(For anyone who cares, culprit is .)
Change:
type testResult bool func init() { <del> // Turn off colors by default to make it easier to collect console output in Jenkins // Override colors off with --ginkgo.noColor=false in the command-line config.DefaultReporterConfig.NoColor = true </del> // Turn on verbose by default to get spec names config.DefaultReporterConfig.Verbose = true <ins> // Turn on EmitSpecProgress to get spec progress (especially on interrupt) config.GinkgoConfig.EmitSpecProgress = true </ins> // Randomize specs as well as suites config.GinkgoConfig.RandomizeAllSpecs = true }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --/kind bug Got two different failure scenarios: ://k8s- ://k8s- /cc Please reassign if the above is wrong. Thanks!
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
Both these failures seems to be test infra issues IIUC. There are no failures in the GPU related logic.
/cc
Seems like it's fixed in
Yes, the PR GPU job had a flake with reusing a build which is a new feature that all e2e jobs will use soon. Hopefully it should be fixed now.
Once gets picked up things should be fixed. I'm still monitoring this. /assign
I have a PR out to revert using shared builds since rolling out an updated CI image will take a bit longer and the patch to kubetest needs to be rolled out.
/sig testing
This is fixed. /close
Change:
corev1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" <ins> "k8s.io/apiserver/pkg/authentication/group" </ins> "k8s.io/apiserver/pkg/authentication/request/bearertoken" bootstrapapi "k8s.io/cluster-bootstrap/token/api" "k8s.io/kubernetes/plugin/pkg/auth/authenticator/token/bootstrap"

Discussion:
While moving APF to beta (see comments on ), we discovered that the integration tests commonly present users which are not members of any groups. We had thought that the system enforced membership in either the authenticated or unauthenticated group. If this is supposed to be a system invariant (as we thought), we'd like to ask SIG Auth: Please fix the integration tests Please add e.g. logging so that if real, operational clusters hit this there's at least a log message and people will file bugs. /sig auth
Can I suggest also, if this is a real invariant, that it be documented in some place(s) likely to be read?
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale /priority important-longterm /triage accepted
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]:
/lifecycle frozen
fixes the authenticator configured in one of the integration test API server startup helpers which resolved this issue for . Remaining tests that still need fixing that are encountering unexpected users look to be ones set up to specifically test auth paths:
open to fix remaining integration test users
Change:
panic(fmt.Sprintf("b: %v", err)) } return util.StringDiff(string(ab), string(bb)) <ins> } </ins> <del> // An alternate diff attempt, in case json isn't showing you // the difference. (reflect.DeepEqual makes a distinction between // nil and empty slices, for example.) </del> <ins> // ObjectGoPrintDiff is like ObjectDiff, but uses go's %#v formatter to print the // objects, in case json isn't showing you the difference. (reflect.DeepEqual makes // a distinction between nil and empty slices, for example, even though nothing else // really does.) func ObjectGoPrintDiff(a, b Object) string { </ins> return util.StringDiff( fmt.Sprintf("%#v", a), fmt.Sprintf("%#v", b),

Discussion:
For example: struct field tag not compatible with reflect.StructTag.Get missing argument for Errorf("%v"): format reads arg 2, have only 1 args range variable pod enclosed by function struct field tag not compatible with reflect.StructTag.Get arg minion for printf verb %s of wrong type: unreachable code unreachable code
Those all look really important
I'm going to fix this unless I hear that someone else is working on this in the next couple minutes.
Change:
}, } } <ins> func newPodWithInitContainers(name string, containers []v1.Container, initContainers []v1.Container) *v1.Pod { return &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: name, }, Spec: v1.PodSpec{ Containers:     containers, InitContainers: initContainers, }, } } </ins>

Discussion:
What happened: A pod that has init container with request for cpu and memory, and containers that make no request for cpu or memory reports a BestEffort QoS class. This is incorrect. What you expected to happen: Containers that make requests independent of lifecycle phase should impact quality of service calculation. Found in 1.12, looks to still be present in 1.14 dev. /cc
/priority important-soon
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
I think this doesn't work very well with the current cpu manager logic. The problem is that a pod can't now have QoS class Guaranteed if it has init containers which don't have matching requests/limits. This means that normal containers in such a pod don't then get dedicated cpus even though the init containers are long gone when the app containers (with matching requests/limits) are finally started. This is quite non-intuitive. I would propose separating at least Guaranteed class calculation so that the init container resource requests wouldn't affect the calculation. What do you think?
Change:
}, Type: corev1.SecretTypeBootstrapToken, Data: map[string][]byte{ <del> bootstrapapi.BootstrapTokenIDKey:               []byte(tokenID), </del> <ins> bootstrapapi.BootstrapTokenIDKey:               []byte(validTokenID), </ins> bootstrapapi.BootstrapTokenSecretKey:           []byte("invalid"), bootstrapapi.BootstrapTokenUsageAuthentication: []byte("true"), <del> bootstrapapi.BootstrapTokenExpirationKey:       []byte(bootstraputil.TimeStringFromNow(-time.Hour)), </del> <ins> bootstrapapi.BootstrapTokenExpirationKey:       []byte(tokenExpiredTime), </ins> }, } type request struct {

Discussion:
Originally tracked at . After fixing "not include test files in import-boss" in , we have a regression here: is using . We need remove dependencies from integration tests to e2e tests again. /assign /sig testing
/sig auth as per the required change
/kind cleanup /area test
It would be helpful to outline an argument as to why this is the case. I can imagine reasons, but none are mentioned here.
Description updated.
/triage accepted /priority backlog /milestone v1.21 This seems a simple enough fix to land (and thank you for doing this) but marking low enough priority to make it clear we may back out and wait for v1.22 if we don't have bandwidth for this
So while I think we should probably do this anyhow I want to note: This issue lists the reasons: we have no intention to stage e2e (there's been much discussion about this since then) we generally don't want anything non-informational (required jobs) running only sometimes anyhow, it's just not reliable Decoupling these seems like a good idea from a purely code-organization perspective, but the reasons in the previous issue are no longer valid.
/milestone v1.22 The PR didn't land in time. At this point I view this as nice to have. Even if it's low impact, let's wait until next release.
Change:
} if len(matchedPluginNames) == 0 { <del> return nil, fmt.Errorf("no volume plugin matched") </del> <ins> return nil, ErrNoPluiginMatched </ins> } if len(matchedPluginNames) > 1 { return nil, fmt.Errorf("multiple volume plugins matched: %s", strings.Join(matchedPluginNames, ","))

Discussion:
In the events , the PVC has been successfully resized, but a warning-level log is still printed. And by checking the logs of kube-controller-manager, can see the following output. Do not print events with warning level. To expand a a CSI PVC, and then use "kubectl describe pvc" to view its events. (I am using xsky CSI to expand pvc, but based on my understanding of Kubernetes code, this issue can occur with any CSI.) ! ! Based on Kubernetes v1.27.3, I some logs in the func located in . These logs printed all the plugins before expansion, and I noticed that was not among them. In my understanding, it is normal for CSI to be absent from the plugins here because CSI expansion is scheduled through external-resizer instead of kube-controller-manager. Therefore, there should not be any warning-level logs printed here either. v1.27.3 (In version 1.18, the issue can also be reproduced) <details</detailsLinux debian-hk 5.10.0-23-amd64 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux kind v0.20.0 <details</details<details</details
/sig storage
We can change the ExternalExpanding event from Warning to Info. are you interested in making this change?
/triage accepted
Yes, I will submit the pull request in the next few days.
Hi Have you submitted the PR? I have a bugfix branch tested on v1.29.1. I would like to cherry-pick it to master if this is not fixed yet or not started.
You can go do it. Thank you!
Change:
// Check iptables chain and rules epIpt := netlinktest.ExpectedIptablesChain{ string(kubeServicesChain): { <ins> {JumpChain: "RETURN", SourceAddress: "127.0.0.0/8"}, </ins> {JumpChain: string(kubeLoadBalancerChain), MatchSet: kubeLoadBalancerSet}, {JumpChain: string(kubeMarkMasqChain), MatchSet: kubeClusterIPSet}, {JumpChain: string(kubeMarkMasqChain), MatchSet: kubeExternalIPSet},

Discussion:
Loopback addresses (127.0.0.0/8, ::1/128) can't be used by services in proxy-mode=ipvs it makes sense to dismiss those early, add RETURN rule to KUBE-NODE-PORT,KUBE-SERVICES No response <details</details25 <details</detailsnone <details</details<details</details<details</details<details</details
/sig network
As mentioned in , this is not a bug since the nodeport and ephemeral ranges overlap.
/kind cleanup /kind remove-bug
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind cleanup /kind remove-bug </details
/remove-kind bug
The title of this issue should be changed to something like; Which would indicate that this is not a bug fix but an improvement. Also remove the invalid use-case in the description and add references to comments in like I think to dismiss nodePort connects to localhost early for proxy-mode=ipvs is an improvement, and in the majority of systems traffic to localhost is more common than traffic to nodePorts so this change will also improve overall performance. This is not a fix for overlapping ephemeral and nodePort ranges! So if the title and description is not updated the correct triage is to close this issue as it violates the non overlapping rule for ephemeral/nodeport ranges, please see
/area ipvs
Ok, i will change issue title and descripiton
/triage accepted
Change:
if err != nil { return apierrors.NewInternalError(err) } <ins> if len(patchObj) == 0 { return nil } // if a non-empty patch was provided, and we have no object we can apply it to (e.g. a DELETE admission operation), error if attr.VersionedObject == nil { return apierrors.NewInternalError(fmt.Errorf("admission webhook %q attempted to modify the object, which is not supported for this operation", h.Name)) } </ins> objJS, err := runtime.Encode(a.plugin.jsonSerializer, attr.VersionedObject) if err != nil { return apierrors.NewInternalError(err)

Discussion:
We had mutating webhooks on delete operation. After updating to Kubernetes 1.11, it is failing. Stacktrace: I tried to debug and this is what I found: is nil. Calling causes this error. I see that the code path has not changed since 1.10. But we don't see the same error in 1.10 minikube cluster. I can't explain that. We have stopped using mutating webhook on delete operation anyway, since it does not make much sense. But I thought I should file a bug just in case. /kind bug /sig api-machinery
cc:
thanks for the report... is this on a custom resource or a native resource? edit: nevermind, found in the stack
It is a CRD.
fix is in , pick to 1.11.x in conversion of unstructured objects (used internally for CRDs) changed in 1.11 as part of CRD versioning, which made them actually go through the conversion stack
/assign
Change:
hostname = hostnameCandidate } } <del> if len(hostname) > hostnameMaxLen { hostname = hostname[:hostnameMaxLen] glog.Errorf("hostname for pod:%q was longer than %d. Truncated hostname to :%q", pod.Name, hostnameMaxLen, hostname) </del> <ins> hostname, err := truncatePodHostnameIfNeeded(pod.Name, hostname) if err != nil { return "", "", err </ins> } hostDomain := ""

Discussion:
Docker daemon complains "invalid hostname format" if the truncated host name ends with "." The truncation occurs .
Docker checks hostname with the regexp (See ): It means that the hostname must end with an alnum, not or . This issue has been here for a long time. This usually happens to static pod, because we compose a looooong name for static pod. We didn't hit this just because we are lucky. :P Will send a PR to fix this. /cc
: Needed for v1.5? please add milestone if so
Thanks for reminding. :) This is a bug fix in kubelet. Mark 1.5. /cc
Are you working on a fix?
Yeah, the fix is here