jiebi/CodeConvo huggingface dataset:
Change:
config := e2enetwork.NewNetworkingTestConfig(f, false, true) ginkgo.By(fmt.Sprintf("dialing(sctp) %v --> %v:%v (config.clusterIP)", config.TestContainerPod.Name, config.ClusterIP, e2enetwork.ClusterSCTPPort)) message := "hello" <del> config.DialEchoFromTestContainer("sctp", config.TestContainerPod.Status.PodIP, e2enetwork.EndpointSCTPPort, config.MaxTries, 0, message) </del> <ins> err := config.DialEchoFromTestContainer("sctp", config.TestContainerPod.Status.PodIP, e2enetwork.EndpointSCTPPort, config.MaxTries, 0, message) if err != nil { framework.Failf("failed dialing endpoint, %v", err) } </ins> }) ginkgo.It("should recreate its iptables rules if they are deleted [Disruptive]", func() {

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
Change:
kube::log::status "Installing godep version ${GODEP_VERSION}" go install ./vendor/github.com/tools/godep/ <ins> GP="$(echo $GOPATH | cut -f1 -d:)" hash -r # force bash to clear PATH cache PATH="${GP}/bin:${PATH}" </ins> if [[ "$(godep version 2>/dev/null)" != *"godep ${GODEP_VERSION}"* ]]; then kube::log::error "Expected godep ${GODEP_VERSION}, got $(godep version)"

Discussion:
Didn't see an issue for this. Godep recently updated its version to v80. This broke several builds that directly godep, grabbing latest. /kind bug cc Example https://k8s- Here are some examples where we grab master:
We have helpers to grab godep. We should use them everywhere.
/cc
/assign
Change:
"regexp" "time" <ins> appsv1 "k8s.io/api/apps/v1" </ins> v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /sig scheduling /cc /priority critical-urgent /milestone v1.19
Appears to have started failing after , which seems unrelated. /cc
according to the build log , the test timed out because it could not find gpu on any nodes. Is it probably a test-infra issue?
I think you are right, I don't see anything changing in the config so must be underlying infra issue /cc
yes, the issue is that the nodes do not have the GPU required to run the test The same infra commit () was used for the last passing job () and the first failing job ()
not sure who owns the node setup for the gpu tests, but I would guess
test-infra-maintainers owns e.g. prow, I don't think anything there relates to the GPUs the infra commit (test-infra commit) not changing suggests perhaps a change to the scripts / test harness in this repo?
the delta between the passing and failing runs only changed an ingress e2e test ()
The image is used in when installing the Nvidia driver. Given that ([1]) is lastly updated on July 17, 2020 at 12:22:11 AM UTC-7 (latest tag points to v2.0.0), does it seem this version is incompatible? BTW: the latest successful run pulled the image with SHA: 8d86a652759f80595cafed7d3dcde3dc53f57f9bc1e33b27bc3cfa7afea8d483 ([2]), maybe we can try that SHA specifically? [1]: [2]:
Forgot to mention, the shows that the deamonset was pending:
yes, and the log also shows that the pod was pending because the init container failed to complete could we change the image to  whose digest is exactly .
Change:
KubeVersion:    "v1.10.0-alpha.2", KubeadmVersion: "v1.10.0-alpha.2", DNSVersion:     "1.14.7", <del> EtcdVersion:    "3.1.11", </del> <ins> EtcdVersion:    "3.1.10", </ins> }, }, },

Discussion:
uses non existing etcd version for k8s 1.10.0. /kind bug /sig cluster-lifecycle
Change:
before the rollout finishes. release: v1.12 file: test/e2e/apps/deployment.go <ins> - testname: Deployment, completes the lifecycle of a Deployment codename: '[sig-apps] Deployment should run the lifecycle of a Deployment [Conformance]' description: When a Deployment is created it MUST succeed with the required number of replicas. It MUST succeed when the Deployment is patched. When scaling the deployment is MUST succeed. When fetching and patching the DeploymentStatus it MUST succeed. It MUST succeed when deleting the Deployment. release: v1.20 file: test/e2e/apps/deployment.go </ins> - testname: Jobs, orphan pods, re-adoption codename: '[sig-apps] Job should adopt matching orphans and release non-matching pods [Conformance]'

Discussion:
[x] Original approval issue: [x] Test pr: [x] Two weeks soak end date: 19 November 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still some remaining Deployment endpoints which are untested. a Deployment with a static label the Deployment with a new Label and updated data the Deployment to ensure it's patched all Deployments in all Namespaces find the Deployment(1) ensure that the Deployment is found and is patched Namespaced Deployment(1) via a Collection with a LabelSelector Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 5 points* This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
BobyMcbobs commented in original Issue: Unsure if the endpoint replaceAppsV1NamespacedDeploymentStatus is able to be hit. When this endpoint is attempted to be updated the data after retrieving the update resource doesn't reflect the values in the update
/assign
When using the appv1.Deployment structure instead of maps of interfaces to build the structure in a patch of the Deployment, this error comes up. Still in progress yment-static":"true"}: does not match template , spec.selector: Invalid value: "null": field is immutable]
replaceAppsV1NamespacedDeploymentStatus to test. Increase cover by 1 Endpoint
/reopen PR reverted by due to flaky test
Reopened this issue. <detailsIn response to : /reopen PR reverted by due to flaky test 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
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
/reopen Soaking, ready for promotion 19 November 2020
Reopened this issue. <detailsIn response to : /reopen Soaking, ready for promotion 19 November 2020 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
/remove-lifecycle stale
/triage accepted
/merged
Change:
ImagePullPolicy:          "IfNotPresent", TerminationMessagePolicy: "File", }, <ins> { Name:                     "resize-policy-cpu", Image:                    "image", ImagePullPolicy:          "IfNotPresent", TerminationMessagePolicy: "File", ResizePolicy: []core.ContainerResizePolicy{ {ResourceName: "cpu", RestartPolicy: "NotRequired"}, }, }, { Name:                     "resize-policy-mem", Image:                    "image", ImagePullPolicy:          "IfNotPresent", TerminationMessagePolicy: "File", ResizePolicy: []core.ContainerResizePolicy{ {ResourceName: "memory", RestartPolicy: "RestartContainer"}, }, }, { Name:                     "resize-policy-cpu-and-mem", Image:                    "image", ImagePullPolicy:          "IfNotPresent", TerminationMessagePolicy: "File", ResizePolicy: []core.ContainerResizePolicy{ {ResourceName: "memory", RestartPolicy: "NotRequired"}, {ResourceName: "cpu", RestartPolicy: "RestartContainer"}, }, }, </ins> } if errs := validateContainers(successCase, volumeDevices, nil, field.NewPath("field"), PodValidationOptions{}); len(errs) != 0 { t.Errorf("expected success: %v", errs)

Discussion:
The newly field field is not being validated. field should be validated. We can create a pod with invalid to reproduce this. 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
/assign /sig node /priority important-soon /milestone v1.27 adding to 1.27 milestone to resolve if possible
I'll try this for v1.27 if you don't mind.
getting a PR open, reviewed, and green is always good. we'll evaluate it for risk and if there's a second release candidate we can likely include it
Nice catch! Please review fix: This likely got dropped either during port-over of the or during bad rebase. I should not have left the . Gotta run to get my kid prepped, dr. appt and then school drop. So I'll try and add an E2E test for this later today. please hold for e2e test (but we should fix this in 1.27)
I realized you were working on a fix as well only after I sent my fix out and was catching up on emails at doc office (rushed morning). I didn't mean to step over your effort to fix it, sorry about that.
I am completely fine with that. Thanks for the fix :)
Change:
claimSize:    "1Gi", expectedSize: "1Gi", nodeName:     node.Name, <ins> attach:       true, </ins> } }

Discussion:
brought this up during the CSI Standup. It seems to be true, in the test config we do not set which is required to bring up the pod for consuming the volume. The code where is checked: The test config used where is not set to true: /kind bug /sig storage /assign /cc
Change:
rs.Labels["name"] = rsName initialDelaySeconds := framework.PodStartTimeout.Seconds() + 30 if tc.podsShouldBecomeReadyFirst { <del> initialDelaySeconds = 0 </del> <ins> initialDelaySeconds = 20 </ins> } rs.Spec.Template.Spec.Containers[0].ReadinessProbe = &v1.Probe{ ProbeHandler: v1.ProbeHandler{

Discussion:
master-blocking: gce-ubuntu-master-containerd No response /sig apps
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:
<ins> # Collecting log files from within containers with Fluentd and sending to the Google Cloud Logging service. This directory contains the source files needed to make a Docker image that collects log files from arbitrary files within a container using [Fluentd](http://www.fluentd.org/) and sends them to GCP. The image is designed to be used as a sidecar container as part of a pod. It lives in the Google Container Registry under the name `gcr.io/google_containers/fluentd-sidecar-gcp`. This shouldn't be necessary if your container writes its logs to stdout or stderr, since the Kubernetes cluster's default logging infrastructure will collect that automatically, but this is useful if your application logs to a specific file in its filesystem and can't easily be changed. In order to make this work, you have to add a few things to your pod config: 1. A second container, using the `gcr.io/google_containers/fluentd-sidecar-gcp:1.0` image to send the logs to Google Cloud Logging. 2. A volume for the two containers to share. The emptyDir volume type is a good choice for this because we only want the volume to exist for the lifetime of the pod. 3. Mount paths for the volume in each container.  In your primary container, this should be the path that the applications log files are written to. In the secondary container, this can be just about anything, so we put it under /mnt/log to keep it out of the way of the rest of the filesystem. 4. The `FILES_TO_COLLECT` environment variable in the sidecar container, telling it which files to collect logs from. These paths should always be in the mounted volume. To try it out, make sure that your cluster was set up to log to Google Cloud Logging when it was created (i.e. you set `LOGGING_DESTINATION=gcp` or are running on Container Engine), then simply run ``` kubectl create -f logging-sidecar-pod.yaml ``` You should see the logs show up in the log viewer of the Google Developer Console shortly after creating the pod. To clean up after yourself, simply run ``` kubectl delete -f logging-sidecar-pod.yaml ``` </ins>

Discussion:
We should provide a dockerfile for a pre-configured Fluentd image that can be passed file paths to collect logs from. We'll likely want one for exporting to elasticsearch and one for exporting to Google Cloud Logging, as we have today for the per-node stdout/stderr collectors. How to collect log files from within a container is a question that comes up occasionally (including ), and it provides a strong example of the usefulness of sidecar containers. cc
A controller that keeps one instance of a pod alive on each node would be useful for this. Shall I go ahead and write such a controller?
Would it be? This is intended to run as a sidecar container in a pod with the user's actual application. I think a pod-per-node controller is orthogonal (and is being discussed in and ). I'll create the actual Dockerfile, and a quick example of how to use it.
Sorry, my rush to catch up I think I mis-understood this thread.
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/client-go/kubernetes/fake" </ins> cloudvolume "k8s.io/cloud-provider/volume" )

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: We have pretty large clusters in aws and in production, we found an inefficiency in provisioning dynamic EBS volumes, where aws-ebs volume provisioner tries to look for available zone from aws directly. With scale, this can trigger massive from ec2, and affect cluster stability. This is also related to What you expected to happen: To simply get zones with available instances, we can get information from API server for efficiency. There might be a delay between node gets shutting down and such change is reflected in api server, but in case node is not ready or gets terminated, there will be higher level reconciliation triggered so we are safe. How to reproduce it (as minimally and precisely as possible): We only expect this to be hit when the cluster is huge (or aws account is huge) so not easy to reproduce. /assign /sig aws /sig cloud-provider
/assign
Change:
<del> /* Copyright 2023 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. */ package cdi import ( "testing" "github.com/stretchr/testify/assert" "k8s.io/kubernetes/pkg/kubelet/container" ) func TestGenerateAnnotations(t *testing.T) { testCases := []struct { description         string deviceIDs           []string expecteError        error expectedAnnotations []container.Annotation }{ { description: "no devices", deviceIDs:   []string{}, }, { description:         "one device", deviceIDs:           []string{"vendor.com/class=device1"}, expectedAnnotations: []container.Annotation{{Name: "cdi.k8s.io/test-driver-name_test-claim-uid", Value: "vendor.com/class=device1"}}, }, } as := assert.New(t) for _, tc := range testCases { t.Run(tc.description, func(t *testing.T) { annotations, err := GenerateAnnotations("test-claim-uid", "test-driver-name", tc.deviceIDs) as.ErrorIs(err, tc.expecteError) as.Equal(tc.expectedAnnotations, annotations) }) } } </del>

Discussion:
Kubelet should stop using annotations to pass CDI device IDs to CRI runtimes. CDIDevices CRI field should be used for this purpose. This should be done when Kubelet that doesn't support CRI field reaches EOL and two major CRI runtimes support CRI field. Here is a PR comment that gives more details about this: Kubelet started using CDIDevices CRI field in . Previous version 1.27 will reach EOL .CRI-O started using it in . Previous version 1.27 will reach EOL together with Kubernetes 1.27.Containerd started using it in . Version 1.7 will reach EOL in a 6 months after Containerd 2.0 release Previous version 1.6 doesn't support CDI injections and should not be considered. So, safer option would be to wait until Containerd 1.7 reaches EOL. However it's relatively safe to do it earlier when 1.7.0 and 1.7.1 have little chances to be in real use. Containerd v1.7.0 and v1.7.1 is not used by the Linux distributions from , so it's safe to remove annotations support from the Kubelet in 1.31 in my opinion.
/sig node
/triage accepted /priority important-longterm
/assign
Change:
<del> v1.30.0-go1.22-bullseye.0 </del> <ins> v1.30.0-go1.22.0-bullseye.0 </ins>

Discussion:
https://prow.ppc64le- Tests are not getting executed due to improper go version. It has been failing since past 4 days. No response No response No response /sig node
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
This seems to be failing due to improper version addition in dependency files where is instead of at some places. I will raise a PR for it.
/assign
fixing that
Change:
overrides      *ConfigOverrides fallbackReader io.Reader configAccess   ConfigAccess <ins> // promptedCredentials store the credentials input by the user promptedCredentials promptedCredentials </ins> } // NewDefaultClientConfig creates a DirectClientConfig using the config.CurrentContext as the context name func NewDefaultClientConfig(config clientcmdapi.Config, overrides *ConfigOverrides) ClientConfig { <del> return &DirectClientConfig{config, config.CurrentContext, overrides, nil, NewDefaultClientConfigLoadingRules()} </del> <ins> return &DirectClientConfig{config, config.CurrentContext, overrides, nil, NewDefaultClientConfigLoadingRules(), promptedCredentials{}} </ins> } // NewNonInteractiveClientConfig creates a DirectClientConfig using the passed context name and does not have a fallback reader for auth information func NewNonInteractiveClientConfig(config clientcmdapi.Config, contextName string, overrides *ConfigOverrides, configAccess ConfigAccess) ClientConfig { <del> return &DirectClientConfig{config, contextName, overrides, nil, configAccess} </del> <ins> return &DirectClientConfig{config, contextName, overrides, nil, configAccess, promptedCredentials{}} </ins> } // NewInteractiveClientConfig creates a DirectClientConfig using the passed context name and a reader in case auth information is not provided via files or flags func NewInteractiveClientConfig(config clientcmdapi.Config, contextName string, overrides *ConfigOverrides, fallbackReader io.Reader, configAccess ConfigAccess) ClientConfig { <del> return &DirectClientConfig{config, contextName, overrides, fallbackReader, configAccess} </del> <ins> return &DirectClientConfig{config, contextName, overrides, fallbackReader, configAccess, promptedCredentials{}} </ins> } func (config *DirectClientConfig) RawConfig() (clientcmdapi.Config, error) {

Discussion:
When I want to use basic-auth, kubectl will display the password I entered: I think it is more sensible to hide the password?
And it seems that kubectl request for username/password twice...
I'll take this. There is a library here: That appears to do the trick, but we need some refactoring so that it can read from an arbitrary reader to fit our usecase.
This was fixed by but I didn't close this issue. Closing it now.
Change:
package v1alpha1 import ( <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: Bug report /kind bug What happened: I'm following the directions to run the sample controller on When running it as directed, it gives these errors: E1214 10:34:25. ] Failed to list v1alpha1.Foo: v1.ListOptions is not suitable for converting to "" E1214 10:34:26. ] Failed to list v1alpha1.Foo: v1.ListOptions is not suitable for converting to "" What you expected to happen: Not to generate these errors. How to reproduce it (as minimally and precisely as possible): 1) Have a working kube config. 2) checkout kubernetes/sample-controller 3) run it: Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.6", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-14T06:55:55Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.0.845+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-10-02T22:37:04Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): my workstation is 14.04.5 LTS, Trusty Tahr Kernel (e.g. ): my workstation kernel is 4.4.0-96-generic Install tools: Others: go version 1.9
cc - Hi, it looks like you checked this in with . What all do I need to do to get this to work?
/sig api-machinery
Hey - thanks for this report. I'm not sure how, but we were missing an extra line in I've put in to resolve this (and it's working for me now :tada:)