jiebi/CodeConvo huggingface dataset:
Change:
} if addressNodeHostName == nil { hostnameAddress := api.NodeAddress{Type: api.NodeHostName, Address: kl.GetHostname()} <del> node.Status.Addresses = append(nodeAddresses, hostnameAddress) </del> <ins> nodeAddresses = append(nodeAddresses, hostnameAddress) </ins> } else { glog.V(2).Infof("Using Node Hostname from cloudprovider: %q", addressNodeHostName.Address) } <ins> node.Status.Addresses = nodeAddresses </ins> } else { var ipAddr net.IP var err error

Discussion:
codablock on slack reported an issue regarding (paraphrasing) "When used in combination with the Azure cloud provider, I get errors about Node.Status.Addresses being duplicated" Looking at the code, the Azure cloudprovider returns a HostName address, but then a HostName address is also by the kubelet code itself.
cc
I have two PRs with different alternatives: adds a hostname unless the cloudprovider already set one. relies on the cloudprovider to set one, and does not add one. I think has the problem that the cloudprovider has no way to say that Hostnames are not in use. relies on the cloudprovider adding the hostname if it wants it, which is trivial for it to do (the Azure provider already does it). any thoughts on the options?
I'd get the cloudprovider to set one if it wants () and avoid duplicating. I don't think the info from --hostname-override should be lost if the cloudprovider didn't have a hostname opinion
Change:
"strings" "time" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" kubeletstatsv1alpha1 "k8s.io/kubelet/pkg/apis/stats/v1alpha1"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: While trying to run the node conformance tests with CRIO, the test I noticed failures like on the logs of the test containers. This happens because CRIO doesn't ship with capability enabled by default. Since only this test in requires it, we should add this capability only in this test and not runtime wide. Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: CRIO doesn't ship with by default. Anything else we need to know:
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 node
Change:
"strings" "time" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" kubeletstatsv1alpha1 "k8s.io/kubelet/pkg/apis/stats/v1alpha1"

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: Which test(s) are flaking: Testgrid link: https://k8s- Reason for failure: Based on the execution conditions sometimes the value of could be 0 instead of expected 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 node
This particular test also fails on CRIO with Fedora CoreOS platform because the return value of is slightly different on that platform.
thank you for opening this issue. Just to have more visibility in the future, and avoid duplicated work, could you please share issues like this one in #sig-node or with the mailist list for CI improvements ? I also see you opened so will assign you this issue /assign /triage accepted /priority important-longterm /cc
thank you for opening and working on this issue. You can check the for issues logged against tests that are producing non-deterministic results. And also it is worth noting that that logged has a for this problem along with the following specific failures
sorry I wasn't aware of CI Signal project board. Thanks for the link.
sorry my bad, I didn't realize there was already an issue for this.
More failures around not having NetworkStats and MemoryStats,
From the kubelet logs of one of the failed jobs. Open the failed job's and look for
helped me to get rid of errors related fsinfo not available. I do some more testing. It's just a temporary patch which looks for because that's what I am using. If it really works, I could make it more generic.
Change:
fi fi # Command <del> kubectl label -f "${file}" labeled=true "${kube_flags[@]}" </del> <ins> # We need to set --overwrite, because otherwise, if the first attempt to run "kubectl label" # fails on some, but not all, of the resources, retries will fail because it tries to modify # existing labels. kubectl-with-retry label -f $file labeled=true --overwrite "${kube_flags[@]}" </ins> # Post-condition: mock service and mock rc (and mock2) are labeled if [ "$has_svc" = true ]; then kube::test::get_object_assert 'services mock' "{{${labels_field}.labeled}}" 'true'

Discussion:
shippable flake: It seems that this test needs to retry on update failures. cc who fixed some other similar test flakes recently and might want to take a swing at this one.
cc
We discussed about it in Assigning to
Thanks . Removing team/control-plane, as team/CSI seem to have this in hand.
Aha, my PR was also hit by this flake just now. I'll try to fix this tmr.
has the same problem.
Change:
1.17 will work on the current Aggregator/API-Server. release: v1.17, v1.21 file: test/e2e/apimachinery/aggregator.go <ins> - testname: Aggregator, manage lifecycle of an APIService codename: '[sig-api-machinery] Aggregator should manage the lifecycle of an APIService [Conformance]' description: An APIService is created which MUST succeed. The APIService status when replaced MUST succeed. Given the updating of the APIService status, the fields MUST equal the new values. The APIService status when patched MUST succeed. Given the patching of the APIService status, the fields MUST equal the new values. The APIService when replaced MUST succeed. Given the updating of the APIService, the fields MUST equal the new values. It MUST succeed at deleting a collection of APIServices via a label selector. release: v1.25 file: test/e2e/apimachinery/aggregator.go </ins> - testname: Custom Resource Definition Conversion Webhook, convert mixed version list codename: '[sig-api-machinery] CustomResourceConversionWebhook [Privileged:ClusterAdmin] should be able to convert a non homogeneous list of CRs [Conformance]'

Discussion:
[X] Test approval issue: [X] Test PR: 7 July 2022 [x] Two weeks soak end date: 21 Jul 2022 [x] Test promotion According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. replaceApiregistrationV1APIServiceStatuspatchApiregistrationV1APIServiceStatusreplaceApiregistrationV1APIServicedeleteApiregistrationV1CollectionAPIService Using a number of existing e2e test practices a new has been created for 4 APIService endpoints. The e2e logs for this test are listed below. This query shows the following endpoints are hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /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
Change:
func init() { jsonSerializer := json.NewSerializer(json.DefaultMetaFactory, schedulerapi.Scheme, schedulerapi.Scheme, true) <ins> serializer := yaml.NewDecodingSerializer(jsonSerializer) </ins> Codec = versioning.NewDefaultingCodecForScheme( schedulerapi.Scheme, <del> jsonSerializer, jsonSerializer, </del> <ins> serializer, serializer, </ins> schema.GroupVersion{Version: Version}, runtime.InternalGroupVersioner, )

Discussion:
Kubernetes scheduler enables you to overwrite default Predicates/Priorities as well as configuring extenders in a "scheduler policy". In latest scheduler componentconfig API (v1alpha1), it can be a file or a configmap: However, if you defines a scheduler config file and specify a YAML policy file: It doesn't work. It's because only JSON is supported: It'd nice to enhance it with an UniversalSerilizer so as to support both JSON and YAML. /sig scheduling /help /priority important-longterm
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Kubernetes scheduler enables you to overwrite default Predicates/Priorities as well as configuring extenders in a "scheduler policy". /help /priority important-longterm </details
/assign
Change:
name: "Change image for all containers with set-image", opts: &DebugOptions{ CopyTo:    "myapp-copy", <del> Container: "app", </del> SetImages: map[string]string{"*": "busybox"}, }, havePod: &corev1.Pod{

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: Using without specifying should modify existing container images without trying to create a new one. Instead it tries to create a new container and returns an error that isn't set: What you expected to happen: This command should change all container images to instead of returning an error. /sig cli /kind bug /priority important-soon
/assign /triage accepted
My kubernetes cluster version is 1.19.0,and i use kubectl-debug version 0.1.1 try to debug my pod,bug i got error: <img width="1470" alt="image" src="https://user-"Who one know about that
Change:
cmd.AddCommand(NewCmdConfigGetContexts(out, pathOptions)) cmd.AddCommand(NewCmdConfigGetClusters(out, pathOptions)) cmd.AddCommand(NewCmdConfigDeleteCluster(out, pathOptions)) <del> cmd.AddCommand(NewCmdConfigDeleteContext(out, pathOptions)) </del> <ins> cmd.AddCommand(NewCmdConfigDeleteContext(out, errOut, pathOptions)) </ins> return cmd }

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No, this is a bug report. What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: MacBook Pro Mid-2015 OS (e.g. from /etc/os-release): macOS Kernel (e.g. ): Install tools: Others: N/A What happened: When deleting the context that was my current context, I entered a state where I am seemingly unable to set my context. The shows none as the current: Also, when trying to take any actions that require a context the following error is presented: When viewing the full config () I can see that my selected context is still the one I deleted. What you expected to happen: I believe there are two expectations I had: should allow me to delete my current context, but not enter an inconsistent state in the process -or- should either provide a warning or disallow removing your current context How to reproduce it (as minimally and precisely as possible): I believe that you just need a configuration with multiple contexts. I had three before deleting the context that has me unable to set a new context.

list all contexts to find your current context () delete your current context list your current contexts again, and you'll see no contexts are created try to set your context with one of the ones that exist () listing your contexts again will show none being set Anything else we need to know: 3 contexts were configured before starting to delete one 2 of them were GKE clusters, automatically set up by the binary 1 is a context set up by the context I deleted was one of the contexts The issue was resolved by manually setting my context by editing .
I think this is the confusion of doesn't switch contexts, it lets you set fields on a context. is what switches contexts.
It's technically valid to have no current context, but I agree a warning message like "warning: this removed your active context, use to select a different one" would go a long way.
SGTM.
Change:
test/integration/discoverysummarizer test/integration/examples test/integration/federation <ins> test/integration/metrics </ins> test/integration/openshift test/soak/cauldron test/soak/serve_hostnames

Discussion:
When running , I got the following errors. Did I miss anything?
This problem will show up on non-linux platforms since the test/integration/metrics has only one file and that is marked as not runnable in non-linux platforms:
Change:
Name:      "pod-forgiveness-invalid", Namespace: "ns", }, <del> Spec: extendPodSpecwithTolerations(validPodSpec(nil), []api.Toleration{{Key: "node.alpha.kubernetes.io/notReady", Operator: "Exists", Effect: "NoSchedule", TolerationSeconds: &[]int64{20}[0]}}), </del> <ins> Spec: extendPodSpecwithTolerations(validPodSpec(nil), []api.Toleration{{Key: "node.kubernetes.io/not-ready", Operator: "Exists", Effect: "NoSchedule", TolerationSeconds: &[]int64{20}[0]}}), </ins> }, }, "must be a valid pod seccomp profile": {

Discussion:
Almost all style strings use dashes, rather than javascript names. vs .
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
Thanks for notification, a quick fix is submitted.
/cc
The PR here isn't merged yet. Can we make that happen please? We're still in alpha, so should be ok
Should I add the v1.8 milestone to this issue?
Hope so. We are pending in , need approve from
I opened with safe changes. "not-ready" change needs to be discussed more, as it's a breaking change. I believe it's best with fixing that to the time we'll be moving to beta, as we'll need to do another breaking change, i.e. remove 'alpha' from the key.
Aren't we doing this at the 11th hour? Is this going to hit 1.8?
Strings like this that are part of the core API should be part of a design doc that is formally reviewed by an API group. We need to find ways to catch this stuff earlier. We should also have an evolving API style guide that lists stuff like this. /cc
Thanks , let me make some summary: quick fix for 1.8 is , will be merged soon. final fix is , we are collaborating to reach a final solution and it's not target 1.8
Agree with Joe, can someone open a PR to that documents that taint names should follow the naming conventions for annotations?
Change:
} func (plugin *glusterfsPlugin) ConstructVolumeSpec(volumeName, mountPath string) (*volume.Spec, error) { <del> glusterfsVolume := &v1.Volume{ Name: volumeName, VolumeSource: v1.VolumeSource{ Glusterfs: &v1.GlusterfsVolumeSource{ EndpointsName: volumeName, Path:          volumeName, }, }, } return volume.NewSpecFromVolume(glusterfsVolume), nil </del> <ins> // To reconstrcut volume spec we need endpoint where fetching endpoint from mount // string looks to be impossible, so returning error. return nil, fmt.Errorf("impossible to reconstruct glusterfs volume spec from volume mountpath") </ins> } // Glusterfs volumes represent a bare host file or directory mount of an Glusterfs export.

Discussion:
/kind bug What happened: Pod stays in terminating status forever What you expected to happen: POD removed. How to reproduce it (as minimally and precisely as possible): Provision container with PVC (Dynamic provisioned) using GlusterFS wait untill running and then remove POD Anything else we need to know?: Events: kubelet log Environment: Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-06-29T23:15:59Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-05-10T15:38:08Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} hardware cat /etc/os-release NAME="Container Linux by CoreOS" ID=coreos VERSION=1381.1.0 VERSIONID=1381.1.0 BUILDID=2017-04-25-2232 PRETTYNAME="Container Linux by CoreOS 1381.1.0 (Ladybug)" ANSICOLOR="38;5;75" HOMEURL="" BUGREPORTURL="" COREOSBOARD="amd64-usr" Linux server37 4.10.12-coreos SMP Tue Apr 25 22:08:35 UTC 2017 x86_64 Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz GenuineIntel GNU/Linux Install tools: hyperkube
/sig node
+1
+1
This should be fixed by
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
Actually will avoid printing out the error message "Could not construct volume information ..", but I believe that is not the root cause of the issue here.
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 stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
I had the same issue for v1.11. Pod has state Terminating. Container is alive on node in Docker 1.13. Describe shows
Change:
ns string ) f := framework.NewDefaultFramework("kubelet") <del> f.NamespacePodSecurityEnforceLevel = admissionapi.LevelBaseline </del> <ins> f.NamespacePodSecurityEnforceLevel = admissionapi.LevelPrivileged </ins> ginkgo.BeforeEach(func() { c = f.ClientSet

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/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
There is no other failures in [x] fixed [ ] will fix this one.
/sig auth /priority important-soon /milestone v1.24
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 and have them propose you as an additional delegate for this responsibility. <detailsIn response to : /sig auth /priority important-soon /milestone v1.24 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:
func newE2eService(nodeName string, cgroupsPerQOS bool, evictionHard string, context *SharedContext) *e2eService { // Special log files that need to be collected for additional debugging. var logFiles = map[string]logFileData{ <del> "kern.log":   {[]string{"/var/log/kern.log"}, []string{"-k"}}, "docker.log": {[]string{"/var/log/docker.log", "/var/log/upstart/docker.log"}, []string{"-u", "docker"}}, </del> <ins> "kern.log":       {[]string{"/var/log/kern.log"}, []string{"-k"}}, "docker.log":     {[]string{"/var/log/docker.log", "/var/log/upstart/docker.log"}, []string{"-u", "docker"}}, "cloud-init.log": {[]string{"/var/log/cloud-init.log"}, []string{"-u", "cloud*"}}, </ins> } return &e2eService{

Discussion:
If node e2es fail, it is not possible to figure out if node initialization failed. We need to collect cloud init logs as well.
This needs to happen right away. There are many flakes on GCI and we don't know why the cloud init scripts failed.
Change:
# do_start() { <ins> # Avoid a potential race at boot time when both monit and init.d start # the same service PIDS=$(pidof $DAEMON) for PID in ${PIDS}; do kill -9 $PID done </ins> # Return #   0 if daemon has been started #   1 if daemon was already running

Discussion:
During an e2e test run, on GCE, I ssh-ed into the box. After the reboot test runs, it appears that something is trying to start kubelet every 2 minutes after the reboot: It does appear that it is monit restarting the process: I do only have one copy of kubelet running, because the second kubelet fails to start:
The direct cause of monit thinking the kubelet is down is that does not match. Also, keeps changing (every two minutes?) My hypothesis is that the second kubelet writes the pid, because it gets pretty far in its boot-up. And thereafter, monit sees it as down so keeps trying to start more. And so the root cause is that first second kubelet start, which I think is down to this: My kubelet is currently listening to that url though: My guess is that kubelet is too slow to start listening to /healthz
Oh! ... or it's a simple race with init.d starting the services; monit vs kube-proxy. If monit starts kube-proxy before init.d starts kube-proxy =double start.
/cc
Ok, there is a race when monit is used to monitor services that are also started at boot time via init.d, in our ecosystem, such as kubelet, kube-proxy, and docker. Especially when a service is slow to start, monit can assume that the service is not running and possibly try to start it and raise an issue while the service is already about to start or already in its startup sequence. In this case, there is a stale pidfile which is used by monit during the service validation periodically (currently configured every 2 mins), thus run into the issue reported by here. A clean way to fix this is starting those kubernetes related services requiring monitoring by monit directly by monit. The issue is that monit is not installed by default in our gce images for now. My proposed solution is that for each dostart call in /etc/init.d/${servicedaemon}, checking if there is existing process running. If it does, kill it before calling start-stop-daemon --start Will send pr shortly.