jiebi/CodeConvo huggingface dataset:
Change:
API Server using the current Aggregator [Conformance]' description: Ensure that the sample-apiserver code from 1.17 and compiled against 1.17 will work on the current Aggregator/API-Server. <del> release: v1.17, v1.21 </del> <ins> release: v1.17, v1.21, v1.27 </ins> file: test/e2e/apimachinery/aggregator.go - testname: Custom Resource Definition Conversion Webhook, convert mixed version list codename: '[sig-api-machinery] CustomResourceConversionWebhook [Privileged:ClusterAdmin]

Discussion:
[X] Test approval issue: [X] Test PR: [x] Two weeks soak end date: [X] Test promotion PR: According to this APIsnoop query, there are still some remaining APIService endpoints which are untested. Using a number of existing e2e test practices the has to cover the outstanding APIService endpoints. There has been some around how the current Conformance test is using RBAC, which is optional and not part of Conformance. Those calls will now only happen if is true. The e2e logs for this test are listed below.

This query shows the following APIService endpoints are hit within a short period of running this e2e test example endpoint | useragent ---------------------------------------------+
createApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] deleteApiregistrationV1CollectionAPIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] listApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] patchApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] readApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIService | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] replaceApiregistrationV1APIServiceStatus | Should be able to support the 1.17 Sample API Server using the current Aggregator [Conformance] (10 rows) 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
Change:
}{ { api.RestartPolicyAlways, <del> []string{"list", "list", "list", "inspect_container", "inspect_container", "inspect_container", "create", "start", "create", "start", "list", "inspect_container", "inspect_container", "inspect_container"}, </del> <ins> []string{"list", "list", "list", "inspect_container", "inspect_container", "inspect_container", "create", "start", "create", "start", "list", "inspect_container", "inspect_container", "inspect_container", "inspect_container", "inspect_container"}, </ins> []string{"succeeded", "failed"}, []string{}, }, { api.RestartPolicyOnFailure, <del> []string{"list", "list", "list", "inspect_container", "inspect_container", "inspect_container", "create", "start", "list", "inspect_container", "inspect_container", "inspect_container"}, </del> <ins> []string{"list", "list", "list", "inspect_container", "inspect_container", "inspect_container", "create", "start", "list", "inspect_container", "inspect_container", "inspect_container", "inspect_container"}, </ins> []string{"failed"}, []string{}, },

Discussion:
Currently kubelet reports current status only. If pod's restart policy is not never, the last terminated container status will be override by the latest status, and lost. We should report last terminated container status. I am going to update our v1beta3 api first, but will hold the implementation until we have
did you have a chance to start working on it? IIUC, to support this we need to change the api (), which IIUC from what wrote in some other thread should be done this week. I'm happy to help with it if you want me to help.
Only breaking changes have a deadline. Additive changes can be done at any time.
I am working on this. PR should be ready today or tomorrow.
Also agree with This is not part of API breakage.
Thanks for answers & clarifications and
Change:
func (os *OpenStack) LoadBalancer() (cloudprovider.LoadBalancer, bool) { glog.V(4).Info("openstack.LoadBalancer() called") <ins> if reflect.DeepEqual(os.lbOpts, LoadBalancerOpts{}) { glog.V(4).Info("LoadBalancer section is empty/not defined in cloud-config") return nil, false } </ins> network, err := os.NewNetworkV2() if err != nil { return nil, false

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I use but my cloud provider doesn't support Openstack LBaaS. Because of the latter I've been using MetalLB instead to get things going. However I keep getting warnings when deploying a when there is no configuration defined in . NOTE: has only a section - there is no mention no section. What you expected to happen: should not print warning via Openstack LoadBalancer since it doesn't support/can't do anything with it. How to reproduce it (as minimally and precisely as possible): Configure Push a Create a Anything else we need to know?: See this Environment: See this
/sig cloud-provider
/sig openstack
that error is coming from row but I am not 100% sure should we support metallb in openstack cloud provider integration. Metallb is not part of openstack. any opinion? anyways it is little bit weird that EnsureLoadBalancer function is even working if LoadBalancer section is not defined in config. Openstack lbaas is not initialized but that function is called?
if there is no LBaaS in the environment and or no , we should not try to deploy one (and let metallb to do the work as it is supposed to). i think.
when you start node, do you see this log print in logs? Can you try to add following to does creating service with type loadbalancer (with metallb) work after that without error prints?
~ With the original config doesnt show up in the log files. The only reference for in the logs is:~ UPDATE BELOW Now, if adding as it yields: And: The IP allocation via MetalLB works The service is remotely available The warning on object disappears:
weird, without this Loadbalancer thing in config it should end up to row and print "Claiming to support LoadBalancer". Now when you that Loadbalancer section with random lb-version it ends up to row and it does not have support to external loadbalancer from openstack. When using metallb the init function in openstack should return false (no support from openstack) but I do not have now idea why it does not do that (when you do not have that loadbalancer section in config)
I take it back. my log level was too high ().

After moving to it shows up when there is no section in :
cool, then we should have check in function as first thing which checks is LoadBalancer even defined in config - if no then return nil, false
(or someone else openstack guy) do you have time to run some test to fix this? I am on vacation and I do not have my test environment with me :) I am thinking to add following to row So I am trying to check is lbOpts totally empty, if yes - then it does not initialize openstack lbaas at all. Maybe I will do PR, but I do not have possibility to test it
Change:
Requests: podRes, Limits:   podRes, }, <del> }, framework.PodStartShortTimeout) </del> <ins> }) </ins> defer func() { // Clean-up the critical pod

Discussion:
master-blocking kind-ipv6-master-parallel RuntimeClass should run a Pod requesting a RuntimeClass with scheduling without taints AdmissionWebhook [Privileged:ClusterAdmin] should honor timeout [Conformance] 01-27-2023 16:08 PST https://k8s- { failed [FAILED] timed out while waiting for pod runtimeclass-3517/without-label to be running In [It] at: @ 01/28/23 22:33:45.607 } No response kind cc
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
It looks like that “Kubernetes e2e suite: . Would we want to reopen this issue? I will keep a close eye on to see if it continues to flake.
Reopen to monitor failures cc
/sig node /cc
/retitle [It] [sig-node] RuntimeClass should run a Pod requesting a RuntimeClass with scheduling without taint
Example failure:
Failure The pod was created at , from the kubelet logs: so the pod started at , but it was deleted at because the 1 minute timeout was hit. It looks like the container startup took a while based on containerd logs: there is a gap there of and between and
It is hitting this timeout - That uses which is 1 min which seems to be too short. We should probably use or which is 5min or 2min, because the whole pod needs to start and it seems like 1min is too short in this case.
Change:
if !util.AccessModesContainedInAll(v.plugin.GetAccessModes(), v.options.PVC.Spec.AccessModes) { return nil, fmt.Errorf("invalid AccessModes %v: only AccessModes %v are supported", v.options.PVC.Spec.AccessModes, v.plugin.GetAccessModes()) } <del> if util.CheckPersistentVolumeClaimModeBlock(v.options.PVC) { return nil, fmt.Errorf("%s does not support block volume provisioning", v.plugin.GetPluginName()) } </del> volSpec, err := v.manager.CreateVolume(v) if err != nil {

Discussion:
FEATURE REQUEST: vSphere volume plugin does not support volume device yet. Need to add volumeMode in PV spec as other plugin did. release 1.12
/sig storage
Change:
return ret } <ins> // a simple token source simply always returns the token property </ins> type fakeTokenSource struct { <del> expiresOn   string accessToken string </del> <ins> token        *azureToken tokenCalls   uint tokenErr     error refreshToken *azureToken refreshCalls uint refreshErr   error </ins> } func (ts *fakeTokenSource) Token() (*azureToken, error) { <del> return &azureToken{ token:       newFackeAzureToken(ts.accessToken, ts.expiresOn), environment: "testenv", clientID:    "fake", tenantID:    "fake", apiserverID: "fake", }, nil </del> <ins> ts.tokenCalls++ return ts.token, ts.tokenErr } func (ts *fakeTokenSource) Refresh(*azureToken) (*azureToken, error) { ts.refreshCalls++ return ts.refreshToken, ts.refreshErr </ins> } func token2Cfg(token *azureToken) map[string]string {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, when AAD login is configured, refresh token timeout would make kubectl print an error, not able to re-login without manually remove the tokens. Expect kubectl to promote user to login again. Why is this needed: Configure refresh-token timeout from Azure is a way to force re-login after inactivity. kubectl doesn't promote re-login makes users harder to apply timeout policy.
/sig azure
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig azure 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
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/azure 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
/area provider/azure
the root cause of this issue is in this first gets the cached token (result of device code flow) at it's trying to refresh an expired token at and failed. An error is returned. Since the expired token is still in the cache, it will always hit this path until user removes the token from kubeconfig. the fix should be: the token from cache a retry to re-initiate the device code flow in
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/azure 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
/sig cli These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
I'm working on it.
are you working on it? I will grab it if I dont hear it from you :)
have the code ready will try PR this weekend Best, Ping
/assign
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
Closing as merged
Change:
reconciler.volumesNeedUpdateFromNodeStatus = append(reconciler.volumesNeedUpdateFromNodeStatus, volumeName1, volumeName2) // Act - run reconcile loop just once. // "volumesNeedUpdateFromNodeStatus" is not empty, so no unmount will be triggered. <del> reconciler.reconcileNew() </del> <ins> reconciler.reconcile() </ins> // Assert assert.True(t, reconciler.StatesHasBeenSynced())

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 --We have even encountered such case that pod continuously reports “Unable to attach or mount volumes for pod;...” when kubelet restarted. The reasons are listed in details as below: , as result of apiserver instantaneous unstablility, dswp get pvc‘s pv spec failed, then the pvc volume does not be to dsw. , syncStates() lists all the volume directories locally, and recontructs the volume from local volume, if the volume isn't in dsw, it will put the recontructed volume to asw, but now the volume.OuterVolumeSpecName isn't correct. chance, at this time, In , the fail to pvc volume is to dsw again normally in reconcile() -mountAttachVolumes(), it compares dsw and asw by volume's innerVolumename, it's all the same. but it could not sense the OuterVolumeSpecName dismatch. so it will not re-mount again to update asw cache , it checks pod's volume attach or mount success by comparing volume.OuterVolumeSpecName and , but this pv'c OuterVolumeSpecName isn't correct in asw. so pod continuously reports “Unable to attach or mount volumes for pod;...” reconcile() could sense the reconstruct volume's dismatch to the dsw, then re-mount again to make volume cache consistency Kubernetes version (use ): 1.19.4 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
/triage accepted
/assign
CC
I think this is a point that can be optimized. /cc
I will give a fix for this
Thanks for reporting the issue, this innerSpecName and outerSpecName are confusing and cause issues. Please ping me for review when you have a fix. Thanks!
Please don't triage your own issues immediately, give someone else a chance to review them :( /sig storage
okay, I know
Change:
if stdout != nil { go io.Copy(stdout, p) } <del> return command.Wait() </del> <ins> return newRktExitError(command.Wait()) </ins> } if stdin != nil { // Use an os.Pipe here as it returns true *os.File objects.

Discussion:
With rkt as the container runtime, the e2e test fails with I dove into it a bit further and it looks like a real issue. With additional logging it appears that the probe does fail (exec happens and returns incorrectly as expected), but when calls it never gets that the given ID exists. The pod definition I've been using is: It restarts very slowly with rkt (on the order of an hour I believe, see sleep 600), but restarts very frequently with docker. cc
Change:
}, expected: &value1, }, <ins> { desc: "should return correct value if elapsed UsageCoreNanoSeconds exceeds 18446744073", stats: &runtimeapi.ContainerStats{ Attributes: &runtimeapi.ContainerAttributes{ Id: "1", }, Cpu: &runtimeapi.CpuUsage{ Timestamp: int64(time.Second / time.Nanosecond), UsageCoreNanoSeconds: &runtimeapi.UInt64Value{ Value: 68172016162105, }, }, }, cpuUsageCache: map[string]*cpuUsageRecord{ "1": { stats: &runtimeapi.CpuUsage{ Timestamp: 0, UsageCoreNanoSeconds: &runtimeapi.UInt64Value{ Value: 67983588375722, }, }, }, }, expected: &value2, }, </ins> } for _, test := range tests {

Discussion:
What happened: CRI CPU metrics are incorrect when using a large number of cores, due to a overflow. What you expected to happen: CPU metrics should be correct for arbitrarily high numbers of cores. How to reproduce it (as minimally and precisely as possible): Deploy a pod with 20 CPU units allocated, and fetch the CRI metrics. The metrics will be incorrect. Environment: Kubernetes version (use ): 1.14.4 CRI: CRI-O cc cc /sig node /sig scalability
How did you get the cri cpu metrics?
kubelet /stats/summary API. For "large" pods, we confirmed that cri-o/cgroupfs calculations were being generated correctly and CPU data overflows at the kubelet CRI stats provider layer. Overflows of CPU data in /stats/summary results in metrics-server having bad data which further propagates to the HPA scaling Pods incorrectly.
Change:
Command:       cmd, Namespace:     t.f.Namespace.Name, PodName:       t.utilPod.Name, <del> ContainerName: "util", </del> <ins> ContainerName: t.utilPod.Spec.Containers[0].Name, </ins> CaptureStdout: true, CaptureStderr: true, })

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: sig-netwok jobs running serial tests Which test(s) are failing: [sig-network] DNS configMap nameserver.* Since when has it been failing: Seems this was the trigger Testgrid link: https://k8s-,%20master Reason for failure: It seems is trying to use the container Anything else we need to know:
/sig network /sig testing /cc /triage accepted
/assign
Change:
err error, ) <ins> const ( initialDuration = 1 * time.Second factor          = 2.0 steps           = 5 ) </ins> // newV1NodeClient creates a new NodeClient with the internally used gRPC // connection set up. It also returns a closer which must to be called to close // the gRPC connection when the NodeClient is not used anymore.

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!--What happened: If kubelet plugin registration fails during the registration process, the kubelet never attempts to register the socket again (assuming the error was transient), unless the socket for the driver is deleted & recreated to trigger a new registration. What you expected to happen: Maybe retry with exponential backoff when kubelet plugin registration fails instead of just logging and waiting for another filesystem event like it does today. Of course, if a socket returns a terminal error (does not implement the kubelet plugin registration service, for example), we should not retry. Follow up on /milestone v1.14 /sig storage How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
I'd like to work on this issue
/assign
Re opening. was a temporary work around for this. is the permanent fix.
Hello! We are starting Bug Freeze for 1.15. Is this issue still planned on being incorporated into 1.15?
the dependent PR is not yet merged. can we get this in for 1.15?
said that is the "permanent fix." and that has merged. So let's close this out /close
Closing this issue. <detailsIn response to : said that is the "permanent fix." and that has merged. So let's close this out 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:
go_test( name = "go_default_test", <del> srcs = ["yaml_test.go"], </del> <ins> srcs = [ "meta_test.go", "yaml_test.go", ], </ins> data = glob(["testdata/**"]), embed = [":go_default_library"], deps = [ <ins> "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/yaml:go_default_library", "//vendor/sigs.k8s.io/yaml:go_default_library", ],

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add an external MetaFactory that allows for serializing multiple YAML (or JSON) files in kubeadm. The logic of marshalling YAML should be factored out from to . Why is this needed: This will allow processing component configs containing multiple documents per file. Additionally, an out-of-tree library would allow sharing this functionality with other components.
I will try work on this as carry-on from /sig cluster-lifecycle /cc
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
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:
register("storage-version-gc", startStorageVersionGCController) } if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.DynamicResourceAllocation) { <del> controllers["resource-claim-controller"] = startResourceClaimController </del> <ins> register("resource-claim-controller", startResourceClaimController) </ins> } return controllers

Discussion:
I am a new guy to kubernetes world, and today I am looking at the source code k8s, I found out a line of code can optimize in this line, `, cus the logic here should be like impl the startController logic and then we put it into the register to find out if the controller was registered twice, if so the program will panic. I think it's better that we change to the one that I provide, which can make code clean as well, but as I'm a new guy, I need some advice on it, can someone help me out? /help wanted /area controller-manager
/sig api-machinery
/sig node Would you submit a PR to fix it if you think this is a problem? /cc as the owner of DynamicResourceAllocation was as alpha level feature in v1.26.
you're say me or the pohly? this is my first time contributing on open source, might have some issues on communicate
You. Feel free to submit PR if this is an optimization. I as he is the feature owner.
thanks, I will submit PR! so the following step should be: me fork the k8s repo to my github and git pull to my local, optimize code, then git push and submit PR, right? the editing should be written on branch master
/triage accepted