jiebi/CodeConvo huggingface dataset:
Change:
}, Status: networkingv1.IngressStatus{LoadBalancer: v1.LoadBalancerStatus{}}, } <ins> ingress1 := ingTemplate.DeepCopy() ingress1.Spec.Rules[0].Host = "host1.bar.com" ingress2 := ingTemplate.DeepCopy() ingress2.Spec.Rules[0].Host = "host2.bar.com" ingress3 := ingTemplate.DeepCopy() ingress3.Spec.Rules[0].Host = "host3.bar.com" </ins> // Discovery ginkgo.By("getting /apis") {

Discussion:
We run sonobuoy tests on production running clusters whenever we upgrade our clusters. We observe that fails when we already have nginx-ingress controller running in the cluster. The newer versions of nginx-ingress controller comes up with a validating admission webhook that validates the ingress definitions. In this specific test, we are creating 3 ingress objects with the same path and the webhook do not permit to create them (the first one is created but the other two would fail) and then the job fails. The tests shouldn't fail and it requires we create ingress objects using different paths instead. Install nginx-ingress controller from Run e2e test. Test fails. No response =1.19 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 testing /area e2e-test-framework
This is a duplicate, see the comment author of the ingress nginx controller explaining why this is working as expected Edit check again, maybe is not a duplicate
Thanks for pointing this. It's infact the same issue. But the fix above should hopefully help since it would create those ingress objects with different paths and the validating webhook for ingress controller would permit creating objects in that case.
yeah sorry, just checked quickly from the mobile, I will take a look Thanks
Change:
import ( "errors" "fmt" <ins> "io/ioutil" "path" </ins> "testing" "time" "github.com/google/go-cmp/cmp" <ins> "github.com/spf13/pflag" </ins> "github.com/stretchr/testify/assert" <ins> "github.com/stretchr/testify/require" </ins> v1 "k8s.io/api/core/v1" <ins> "k8s.io/apimachinery/pkg/api/resource" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" clientsetfake "k8s.io/client-go/kubernetes/fake" componentbaseconfig "k8s.io/component-base/config"

Discussion:
introduced configuration of additional logging aspects (e.g. format) through command line flags and config file. This was merged for Kubernetes 1.28. Now the following invocation doesn't work as expected when the config file doesn't configure logging: It should run with verbosity 4. Instead it runs with verbosity 0, from the config. Run with this config file: No response 28 rc n/a No response No response No response No response
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
The problem is caused by this line: At that point, is 4 (from the command line flag), and then it gets overwritten with == 0. The normal approach would be: set up config with defaults modify config through flags modify config further by parsing a config file into it. Can kube-proxy do this? It has the downside that a config file can only overwrite fields if they are in the file. A config field doesn't get reset to defaults just by parsing the file. /cc
it looks like kube-proxy special-cases the to let a flag override config... can/should it do the same thing for verbosity? are there any other flags like this?
I don't think that's the normal approach... it's more normal to make flags and config file mutually exclusive. That's difficult for things which started as flags and moved into config
/sig network /sig instrumentation /kind bug /kind regression /milestone v1.28
let's go with and warn it and comment as much as possible, I was going with something like but Patrick is working on it so I assign to him the issue
/assign
Hey folks, v1.28 Bug Triage Lead here Just wanted to know if this is already tracked by SIG leads and someone already working actively fixing it and set a priority?
Perhaps I should have said "this is how component-base/logs was meant to be used". Somehow it worked for kubelet.

Here's my preliminary solution: It needs more testing, but I wanted to share it early because I am running out of time today.
it is , I can take over Patrick's work in case is needed
It would be nice if the logs API could distinguish between and , how about make to a pointer? But this change is supposed to be a breaking change, I'm not sure of the scope of the impact. For side, if set and at the same time, should the command flag override the config file or warn it and be discarded? I think it should be overridden.
xref:
Change:
fi env-to-grains "runtime_config" <ins> env-to-grains "kube_user" </ins> } function salt-node-role() {

Discussion:
abac-authz- hardcodes "admin" instead of using the $KUBE_USER variable. This means that "admin" is the only basic-auth username that will work with that abac config.
To workaround until it is fixed, you can add a line to the master's abac-authz- file: and then restart the kube-apiserver (docker kill it, and let it restart).
Change:
# CNI_BIN_DIR is the path to network plugin config files. CNI_BIN_DIR=${CNI_BIN_DIR:-""} <del> # KUBELET_KUBECONFIG_DIR is the path to a dir for the kubelet's kubeconfig file </del> <ins> # KUBELET_KUBECONFIG is the path to a kubeconfig file, specifying how to connect to the API server. </ins> KUBELET_KUBECONFIG=${KUBELET_KUBECONFIG:-"/var/lib/kubelet/kubeconfig"} # Creates a kubeconfig file for the kubelet.

Discussion:
/kind bug What happened: From doest not find kubeconfig file What you expected to happen: To find kubeconfig file How to reproduce it (as minimally and precisely as possible): from conformance file Anything else we need to know?: Line 185 : Starting kubelet with args But does not exist. Using from line 80 seems to work properly Environment: Kubernetes version (use ):Cloud provider or hardware configuration: hardware configuration OS (e.g. from /etc/os-release): Fedora 28 Server Kernel (e.g. ): Linux 4.17.12-200.fc28.x86_64
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
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
/area conformance
Change:
package app import ( <ins> "net/http" </ins> "testing" "time"

Discussion:
In we observed a crashlooping controller cause a cluster cold boot failure, as controller-manager wasn't able to stay up long enough to run the deployment that would have fixed the problem. We should audit everything that runs in kube-controller-manager and ensure that they all fail gracefully enough to prevent crashloops, or make them individually restart in that case, instead of the process. Longer term, we should consider classifying the controllers by run level or bootstrap order (), and splitting them into separate binaries or changing the start-up order in kcm to make sure this sort of thing doesn't happen in the future.
Same issue with metrics-server, using minikube. Also reproduced on our test cluster. Steps to reproduce: Set up localkube Install metrics-server Stop minikube: sudo minikube stop Start minikube: sudo -E minikube start --vm-driver=none Expected: Kubernetes is running Actual: Kubernetes is dead Logs: Workaround: To fix the system, we must delete the metrics-server: Now kubernetes will start normally. After that we can reinstall the metrics server, and it will be ok.
Related:
This will be a hard problem to fix permanently. In all likelihood, we should stop allowing Fatalf() in kubernetes/kubernetes, but as you can see we do this to ourselves right here...
/kind bug
I also think this bug would benefit from an e2e test where we misconfigure things in a variety of ways and verify that KCM still comes up and stays up: [ ] misconfigured apiservice [ ] broken service attached to that apiservice [ ] RBAC rules that disallow things. maybe everything! [ ] webhooks that disallow everything [ ] yr example here
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
/remove-lifecycle stale
Change:
kubelet.SetupLogging() kubelet.SetupCapabilities(kcfg.AllowPrivileged) <ins> credentialprovider.SetPreferredDockercfgPath(kcfg.RootDirectory) </ins> cfg := makePodSourceConfig(kcfg) k, err := createAndInitKubelet(kcfg, cfg) if err != nil {

Discussion:
As per We should look for the .dockercfg in three places: ./.dockercfg, ~/.dockercfg, and $rootDir/.dockercfg
I'll tackle this.
Bunch of questions: we also add a flag that overrides the search mechanism suggested in this issue? Perhaps, ? to the user's homedir requires we use os/user [0] . The os/user package and cross-compiling don't play nice [1]. So, if we add to the search path, cross-compiled kubelet binaries will not actually be able to take advantage of it. Is this an issue? is the proper lookup order? I suggest: if provided, , , . walking through the lookups, do we stop at the first file that exists, or the first file that exists and is parsed as a valid ? [0] [1] /cc
I would absolutely love a --dockercfg option, and it would also be helpful if it logged which .dockercfg it ultimately used.
1) Seems like YAGNI to me 2) Is all of os/user broken? We will eventually want actual user support. I'm fine with dropping it for now. 3) I would say $rootDir/.dockercfg, ./.dockercfg (assuming we drop ~) 4) First successful parse sounds good to me. And can we NOT log errors if files don't exist :)
would it make sense to default to the kubelet config directory if provided rather than the working directory of the kubelet process? then no extra flag required.
What ever happened with this idea?
/cc
It never got high enough on my weekend TODO list :( I can keep telling myself that I need to do it, or we can find someone who has a bit more time than me.
I can probably get to this today.
Cool, thank you! , Mike Danese wrote:
Change:
if isIndexedJob(job) { completionMode = string(*job.Spec.CompletionMode) } <del> job.Status.Conditions = append(job.Status.Conditions, *finishedCond) </del> <ins> job.Status.Conditions, _ = ensureJobConditionStatus(job.Status.Conditions, finishedCond.Type, finishedCond.Status, finishedCond.Reason, finishedCond.Message) </ins> if finishedCond.Type == batch.JobComplete { if job.Spec.Completions != nil && job.Status.Succeeded > *job.Spec.Completions { jm.recorder.Event(job, v1.EventTypeWarning, "TooManySucceededPods", "Too many succeeded pods running after completion count reached")

Discussion:
If the user update , duplicate condition: ! Only one Failed condition Create Job and wait it marked as Failed Update the Failed condition to False No response <details</details<details</details<details</details<details</details<details</details<details</details
It's not a bug. The is a list, so it can contain many conditions with different probe timestamps. Also, we should not update the fields.
But should we avoid the duplicate Type's conditionIn my opinionthis will confuse the user. According to kubelet, it will rewrite the 'Ready' condition in pod, and take is as managed only by kubelet. Should we did this for job Failed condition? Refer:
/sig apps
It is a bug. We should only have one condition for each type. /triage accepted
/assign
/assign
/assign
I have reproduced the issue locally and intend work on the fix
/priority backlog Since the user is manually modifying the status, this is not an inherent bug in the controller. Still worth avoiding duplicates.
Change:
Subsystem:         KubeletSubsystem, Name:              ActiveConfigKey, Help:              "The config source the node is actively using. The count is always 1.", <del> DeprecatedVersion: "1.22", </del> <ins> DeprecatedVersion: "1.22.0", </ins> StabilityLevel:    metrics.ALPHA, }, []string{ConfigSourceLabelKey, ConfigUIDLabelKey, ConfigResourceVersionLabelKey, KubeletConfigKeyLabelKey},

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 --kubelet failed to start when specifying ,with following error: Try to start kubelet with : Kubernetes version (use ): master branch 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 node
Submitted PR to fix this issue.
/triage accepted /priority important-soon
Change:
"type": "pd-ssd", "zone": cloudZone, }, <del> "1.5Gi", "2Gi", </del> <ins> "1.5G", "2G", </ins> func(volume *v1.PersistentVolume) error { return checkGCEPD(volume, "pd-ssd") },

Discussion:
GCE PDs are allocated in chunks of GBs (not GiB) but function incorrectly creates volume in chunks of GiB - cc /sig storage
/kind bug
/assign
/priority important-soon
Hey I submit a pr for this issue. Your suggestions are very important. Thanks.
Change:
results = append(results, groupVersion.WithResource(apiResource.Name)) } } <del> return results, nil </del> <ins> return results, utilerrors.NewAggregate(allErrs) </ins> }

Discussion:
I have been having the kube-controller-manager (running in a container) crash quite frequently with this error: I cant fathom what seems to cause it. It seems to happen consistently for a while (CrashLoopBackoff occurs) and then fixes itself after an undetermined amount of time. Kubectl version: Docker version: Networking: Calico (with the calico k8s policy agent) Please do let me know if there is any other information that I can supply. I appreciate I haven't given much to go off of. I am not sure what the steps to reproduce are...
cc
It looks like a bug. I'll take a look. Thanks for reporting it.
Weirdly, the description showed up in the email github sent me but it appears absent on the github issue?
The description was there when I read it but disappeared now.
Well thats very odd! If you have it on your email, could you post it on here please (and I will update the description)? I unfortunately haven't got the error message to hand now...
I took the liberty of just editing the OP.
thanks a lot! Not sure what happened there!
could you paste the returned output at "server-ip:port/api" and "server-ip:port/apis"?
Sure.
Thanks "" has an empty preferred version and that's causing the error you reported. Is "" created via the thirdparty resource api? ()
aha! Good spot! Yes, it was created via that API. This is the Yaml file I used to create it: Here is the output of
Thanks for the confirmation Your configuration is correct. The preferred version is left empty by the thirdparty resource controller, while our discovery client has an assumption that the preferred version won't be empty. I'll patch the discovery client to tolerate an empty preferred version, and will discuss with on if we should make a default preferred version for a thirdparty resource.
Thanks a lot Great job on working it out :)
Sent to fix.
What would be a workaround for this before the release, how can one specify the preferredVersion?
AFAIK, there is no workaround. There is no way to specify the preferredVersion for the thirdPartyResource.

I have a quick workaround to fix this : 1) Change the kubernetes to reflect the following : from : thirdpartyresources=true to : thirdpartyresources=false 2) Then restart 'kubelet' service OR reboot the K8S Master server systemctl restart kubelet 3) Revert back the changes done to kube- from : thirdpartyresources=false to : thirdpartyresources=true 4) Verify whether the above change on the above manifest file has been automatically picked up by the kubernetes API ps aux | grep -i thirdpartyresources 5) Finally you may restart kubelet service systemctl restart kubelet 6) Now verify whether the 'kube-controller-manager' is in a 'Running' state kubectl get pods --all-namespaces | grep -i controller-manager Hope this fix works for you guys as well !!
Change:
"runtime" v1 "k8s.io/api/core/v1" <ins> "k8s.io/component-helpers/scheduling/corev1" </ins> "k8s.io/klog/v2" v1helper "k8s.io/kubernetes/pkg/apis/core/v1/helper" <ins> "k8s.io/kubernetes/pkg/kubelet/types" </ins> "k8s.io/kubernetes/pkg/scheduler" schedulerframework "k8s.io/kubernetes/pkg/scheduler/framework" <ins> "k8s.io/kubernetes/pkg/scheduler/framework/plugins/tainttoleration" </ins> ) type getNodeAnyWayFuncType func() (*v1.Node, error)

Discussion:
The method doesn't check taints and tolerations. This is problematic in 2 scenarios: If the users bypass scheduler by setting a value in If the node restarts. The node would try to restart scheduled pods once it comes back up, even if it's not ready (has a not-ready taint). Kubelet to check taints and tolerations. a taint in a node. a Pod with set to the Node above, without a matching toleration. /sig node /sig scheduling
this reminds me of your kubelet sync PR ...
I don't think this is a syncing issue. The logic doesn't check taints at all.
scenario 1 is pretty bad, i will let the #sig-node slack know about this.
It doesn't sound like a syncing issue, but we seem to have multiple issues with pod admission/management on restart currently
I'm aware of that issue. This should be unrelated.
I would like to address this. /assign
I think it would be great to proceed after merging ref:
Please add me as reviewer
/triage accepted
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 PR in review:
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 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
Change:
"k8s.io/klog/v2" v1 "k8s.io/api/core/v1" <ins> "k8s.io/apimachinery/pkg/api/resource" </ins> "k8s.io/apimachinery/pkg/util/sets" clientset "k8s.io/client-go/kubernetes" restclient "k8s.io/client-go/rest"

Discussion:
A kubernetes cluster is normally constructed from a variety of machine templates. Different instance groups may have different CPU, memory capacity. They may be equipped with specialized accelerators, network devices. I think we should have an extensible way for users to custom node configuration to simulate real production cluster states. Currently, nodelabel and nodetaints are supported. I am consider to accept a template with more configuration like resources so we won't grow option list in the future. Without this feature, it's hard for users to simulate heterogeneous cluster.
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 scalability
Change:
done } <ins> # Saves prepulled Windows Docker images list to ${WINDOWS_LOGS_DIR}docker_images.log # on node $1. function export-windows-docker-images-list() { local -r node="${1}" local -r powershell_cmd="powershell.exe -Command "$logs=$(docker image list); $logs | Out-File -FilePath '${WINDOWS_LOGS_DIR}docker_images.log'"" # Retry up to 3 times to allow ssh keys to be properly propagated and # stored. for retry in {1..3}; do if gcloud compute ssh --project "${PROJECT}" --zone "${ZONE}" "${node}"  --command "$powershell_cmd"; then break else sleep 10 fi done } </ins> # Saves log files from diagnostics tool.(https://github.com/GoogleCloudPlatform/compute-image-tools/tree/master/cli_tools/diagnostics) function save-windows-logs-via-diagnostics-tool() { local node="${1}"

Discussion:
When a test run completes it would be useful to have a list of all the test containers that were pulled onto the node - see for the motivation. Let's add a call to at - just after seems like it should work fine. We can dump the output to a file and gather it from each node just like we do for
/assign Yang, we should also consider adding to the log gathering that the GCE diagnostics tool does :)
/sig windows
/reopen in the of our on 03-22 I don't see in the artifacts for the Windows node. Can you check on this? Did we miss a step or is something failing?
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
Oh, missed to add the new log file to collector list.
Added the fix:
Change:
kubeserver "k8s.io/kubernetes/pkg/kubeapiserver/server" ) <del> // NewSecureServingOptions gives default values for the kube-apiserver and federation-apiserver which are not the options wanted by </del> <ins> // NewSecureServingOptions gives default values for the kube-apiserver which are not the options wanted by </ins> // "normal" API servers running on the platform func NewSecureServingOptions() *genericoptions.SecureServingOptions { return &genericoptions.SecureServingOptions{

Discussion:
Currently as authentication and authorization are both standard config for all clusters, the kubeapiserver insecure http handler is unsecure, which means the cluster is vulnerable to the attack. So it should be deprecated, even removed totally.
/sig api-machinery
I think removing the insecure option is a good idea. Can you send an email the sig-apimachinery mailing list with a proposed timeline? I think this should be like other GA features and have a one year clock.
Sure, I will send it ASAP.
:+1: