jiebi/CodeConvo huggingface dataset:
Change:
klog.V(2).Infof("azureDisk - update(%s): vm(%s) - attach disk(%s, %s) with DiskEncryptionSetID(%s)", nodeResourceGroup, nodeName, diskName, diskURI, diskEncryptionSetID) rerr := ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, newVM, "attach_disk") if rerr != nil { <del> detail := rerr.Error().Error() if strings.Contains(detail, errLeaseFailed) || strings.Contains(detail, errDiskBlobNotFound) { // if lease cannot be acquired or disk not found, immediately detach the disk and return the original error klog.Infof("azureDisk - err %s, try detach disk(%s, %s)", detail, diskName, diskURI) ss.DetachDisk(diskName, diskURI, nodeName) </del> <ins> klog.Errorf("azureDisk - attach disk(%s, %s) on rg(%s) vm(%s) failed, err: %v", diskName, diskURI, nodeResourceGroup, nodeName, rerr) if rerr.HTTPStatusCode == http.StatusNotFound { klog.Errorf("azureDisk - begin to filterNonExistingDisks(%s, %s) on rg(%s) vm(%s)", diskName, diskURI, nodeResourceGroup, nodeName) disks := ss.filterNonExistingDisks(ctx, *newVM.VirtualMachineScaleSetVMProperties.StorageProfile.DataDisks) newVM.VirtualMachineScaleSetVMProperties.StorageProfile.DataDisks = &disks if rerr = ss.VirtualMachineScaleSetVMsClient.Update(ctx, nodeResourceGroup, ssName, instanceID, newVM, "attach_disk"); rerr != nil { return rerr.Error() } </ins> } <del> return rerr.Error() </del> } <del> klog.V(2).Infof("azureDisk - attach disk(%s, %s) succeeded", diskName, diskURI) </del> <ins> klog.V(2).Infof("azureDisk - update(%s): vm(%s) - attach disk(%s, %s) succeeded", nodeResourceGroup, nodeName, diskName, diskURI) </ins> return nil }

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: check disk status before disk azure disk There is little possibility that attach disk would cost 10min, and disk could be attached, deleted in same time, that would cause race condition. What you expected to happen: 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Change:
}, Spec: *pod.Spec.DeepCopy(), } <ins> // set EphemeralContainers to nil so that the copy of pod can be created copied.Spec.EphemeralContainers = nil </ins> // change ShareProcessNamespace configuration only when commanded explicitly if o.shareProcessedChanged { copied.Spec.ShareProcessNamespace = pointer.BoolPtr(o.ShareProcesses)

Discussion:
What happened: When using to create a debug container for a pod that has multiple init containers or ephemeral containers, fails with . What you expected to happen: should create a debug container in pod successfully. How to reproduce it (as minimally and precisely as possible): The EphemeralContainers feature gate must be enabled by using flag in your cluster. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): NAME="CentOS Linux" VERSION="7 (Core)" Kernel (e.g. ): Linux node-1 3.10.0-957.el7.x8664 SMP Thu Nov 8 23:39:32 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others: /sig cli
I have investigated this issue and it looks like this issue happens in the following cases. When using without option When using with option In those cases, the containerNameToRef function is called and each for-loop in the function refers to the same despite the range is , or .
cc If this issue needs to be fixed, I would like to work on this.
/assign
Thanks for the report and for fixing it!
Change:
// NewIPerf parses an IPerf CSV output line into an IPerfResult. func NewIPerf(csvLine string) *IPerfResult { <ins> csvLine = strings.Trim(csvLine, "n") </ins> slice := StrSlice(strings.Split(csvLine, ",")) if len(slice) != 9 { framework.Failf("Incorrect fields in the output: %v (%v out of 9)", slice, len(slice))

Discussion:
WHAT: Bug report. See the error log below, I assume the output of iperf in my test environment has an extra newline in the value of , that is What about trim the newline in the returned value before parsing it as an integer? Especially change this line Like,
/sig network
/assign
If it's a bug, may I send a PR to fix this?
Of course. It would be best to also have a commit that adds an e2e test to replicate this issue. It is hard to tell if this is environment specific and it's odd that this has not popped up before.
I see this on an aws/coreos setup
Are you still working on this? Looks like the PR was closed.
Yes, I am still working on it and PR reopen now. BTW, I can reproduce it in my local centos setup. I wonder why k8s CI environment does not has this issue.
Please refer Do think this PR can fix this issue?
/kind bug
I'm seeing this also, running a in a Travis CI Ubuntu Trusty VM.
I never dug into the issue so I don't know.
/unassign /assign
Change:
podCIDRs map[kubecontainer.ContainerID]string MTU      int <ins> mu       sync.Mutex //Mutex for protecting podCIDRs map and netConfig </ins> } func NewPlugin() network.NetworkPlugin {

Discussion:
I gathered e2e test results of suite for last 100 runs. The following is the list of flaky tests. Some might not be related to . I will start with the service tests. Any help would be appreciated. Detail list: Jenkins project:
cc/ Cluster team is working on to make kubenet default. Once we switch this to production, we don't need to restart docker to configure cbr0.
After a bunch of PRs got merged, the kubenet suite is much more stable. One more known flake can be fixed by I will post new flake tests here.
Just bump into a new failure: One of the nodes () got panic: Looks like it crashed at shaper reset.: Can you take a look?
Change:
return err } <del> func cleanupServiceShardLoadBalancer(clusterName string, service *v1.Service, timeout time.Duration) error { provider := framework.TestContext.CloudConfig.Provider if provider == nil { return fmt.Errorf("cloud provider undefined") } internalSvc := &v1.Service{} err := api.Scheme.Convert(service, internalSvc, nil) if err != nil { return fmt.Errorf("failed to convert versioned service object to internal type: %v", err) } err = wait.PollImmediate(framework.Poll, timeout, func() (bool, error) { lbi, supported := provider.LoadBalancer() if !supported { return false, fmt.Errorf("%q doesn't support load balancers", provider.ProviderName()) } err := lbi.EnsureLoadBalancerDeleted(clusterName, internalSvc) if err != nil { // Deletion failed with an error, try again. framework.Logf("Failed to delete cloud provider resources for service %q in namespace %q, in cluster %q: %v", service.Name, service.Namespace, clusterName, err) return false, nil } By(fmt.Sprintf("Cloud provider resources for Service %q in namespace %q in cluster %q deleted", service.Name, service.Namespace, clusterName)) return true, nil }) return err } </del> func podExitCodeDetector(f *fedframework.Framework, name, namespace string, code int32) func() error { // If we ever get any container logs, stash them here. logs := ""

Discussion:
In federation tests, if we observe the build logs. we see cleaning up LoadBalancer from cloud provider seems not working. It has 2 effects: delays the tests by waiting to delete but always returns error. so we waste like 5 minutes. maybe we are leaking the LoadBalancer in the project.
we can see these errors in every build. but just for reference here are some build logs https://k8s-
cc
All the errors in logs are . It doesn't necessarily indicate we are leaking resource, just now we must have clusterID initialized before calling EnsureLoadBalancerDeleted(). Would be better to not call this function directly in e2e test :)
Federation cleanup should use the same implementation as non-federated e2e test:
function looks like only specific to GCE. in future we would run the e2e tests in AWS too. it would be better to use generic functions if any.
using is working for us. here is the test logs https://k8s-
EnsureLoadBalancerResourcesDeleted() actually cleans up nothing, it only lists forwarding rules and probably logging :)
Change:
local platform_tag=${platform///-} # Replace a "/" for a "-" echo "+++ Building tarball: client $platform_tag" <del> local release_stage="${LOCAL_OUTPUT_ROOT}/release-stage/client/${platform_tag}/kubernetes" </del> <ins> local release_stage="${RELEASE_STAGE}/client/${platform_tag}/kubernetes" </ins> rm -rf "${release_stage}" mkdir -p "${release_stage}/client/bin"

Discussion:
Sometimes it is nice to have non-tar'd binaries for releases. We should upload those along with the our packaged tarballs. This will help fix
Change:
opt := NewOptions() opt.ConfigFile = file.Name() <del> err = opt.Complete() </del> <ins> err = opt.Complete(new(pflag.FlagSet)) </ins> if err != nil { t.Fatal(err) }

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:
import ( v1 "k8s.io/api/core/v1" <ins> utilfeature "k8s.io/apiserver/pkg/util/feature" </ins> v1helper "k8s.io/kubernetes/pkg/apis/core/v1/helper" <ins> "k8s.io/kubernetes/pkg/features" </ins> ) // For each of these resources, a pod that doesn't request the resource explicitly

Discussion:
The scheduler does not properly calculate pod requests for a resource as - it ignores init containers completely in . This would allow a workload to get "free" scheduling above the limit of containers (mitigated by quota, which calculates this properly) and so the scheduler would make non-optimal fits. Both kubelet and scheduler enforce the , so you can't actually schedule, but you sometimes get steered to the wrong node if you have more init container resource usage than containers. in should use and the similar helpers instead of writing its own method to calculate the request for resources. /sig scheduling
/priority important-soon
Let me follow this issue. /assign
fyi
After I checked the implementation of function, I think we just need to use it to instead of the function in the scheduler.
/priority critical-urgent
Is the pod phase not considered? When the pod phase is running, the requested resource is actually considered as . This change seems to reduce the resource utilization of the node.
Actually, I don't think we need to consider the pod.Phase. The resource request & limit are mainly used in the scheduling process. The scenario you said is not belong to the responsibility of kube-scheduler
Correct. Setting appropriate requests/limits that maintain good node usage is users responsibility. Considering the max(initContainers, sum(containers)) is the documented behavior.
I understand. Thank you for your comments!
Change:
"//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/scheme:go_default_library", <ins> "//staging/src/k8s.io/client-go/rest:go_default_library", </ins> "//staging/src/k8s.io/client-go/tools/reference:go_default_library", ], )

Discussion:
What happened: kube-scheduler panics when client-go tries to finish the existing event series, see: What you expected to happen: kube-scheduler should not panic 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /assign /priority critical-urgent /sig scheduling
Change:
tags = ["automanaged"], deps = [ "//cmd/kube-apiserver/app/options:go_default_library", <ins> "//cmd/kube-apiserver/app/preflight:go_default_library", </ins> "//pkg/api:go_default_library", "//pkg/apis/batch:go_default_library", "//pkg/capabilities:go_default_library",

Discussion:
See: This code should make several attempts before ing. Alternatively, we could consider not listening for connections until this code has succeeded.
Feel free to correct me if I'm wrong on any of this since I've never looked at kubernetes code base before. The code for the and the both appear to make multiple attempts before returning an error which leads to a Fatal.
, I think we had waited for to start at . Do we need to wait more or make it configurable?
I would like to work on this if nobody else is.
No need to ask for permission! Just say here that you're working on it, that should be sufficient to prevent duplicate work. :)
Can I have a go at this?
I have a nearly completed solution for this already. Just working on testing/test cases. WIll hopefully sumbit a PR shortly.
Ok.
I wondered why we care about this. After all, kubelet restarts failing pods. For posterity, after talking with the reason is that the apiserver may fail so fast that the kubelet begins to back off on restarts of a failing pod. That backoff may be too aggressive. (Maybe it causes spurious alerts, or maybe it allows too much downtime.) So, let's fix the apiserver. That's fine, but clearly we're not the only user that might encounter this. You may be running a server you don't want to (or can't) modify, and you might wish you could tweak the kubelet's backoff heuristics for your pod. Alternately, maybe the kubelet could choose not to enter the backoff if apiserver exited with a different code. anything like this already in place?
That's a wonderful explanation that hadn't occurred to me. If there isn't a feature request for this already I'll work on something and reference this issue.
AFAIK, the backoff mechanism is there to protect kubelet from being overwhelmed by failed user containers. Trusting the containers with returning a specific exit code sounds like a big "no" to me. Making this configurable per pod might be ok, but it's still not good in general to allow aggressive restarts.
The referred PR () only fixes the issue for kube-apiserver. We still need a generic fix in genericapiserver (Ref ).
Change:
return nil } <del> vpcCidr, err := c.getVpcCidrBlock() </del> <ins> vpcCidrBlocks, err := c.getVpcCidrBlocks() </ins> if err != nil { return err }

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: When an AWS NLB is created through the Service of type, the health check security group rule is only created with a VPC primary CIDR block, as seen here: If the VPC has multiple CIDR blocks associated, and the worker nodes are running on those corresponding subnets, the health check fails. What you expected to happen: Multiple health check security group rules are created, one for each VPC CIDR block, using both and (). How to reproduce it (as minimally and precisely as possible): a VPC with with additional subnets created on a non-primary CIDR. a Kubernetes cluster (e.g. EKS) on subnets associated with a non-primary CIDR. a Service of type with nodes are healthy due to the security group rule being created only allowing traffic from the primary CIDR. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Amazon Linux 2 Kernel (e.g. ): Install tools: N/A Others: N/A
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
Hi, i'll provide a fix next week
Change:
"tagline" : "You Know, for Search" } ``` <ins> **Note**: We use the `-L` flag in the request so that `curl` follows the returned redirect address and retrieves the Elasticsearch service information. </ins> <del> We can examine the actual redirect header: </del> <ins> If we examine the actual redirect header (instead run the same `curl` command with `-v`), we see that the request to `https://104.197.5.247/api/v1beta3/redirect/namespaces/default/services/elasticsearch-logging/` is redirected to `http://10.244.2.7:9200`: </ins> ``` <del> user@oban:~$ curl -v -k -u admin:4mty0Vl9nNFfwLJz https://104.197.5.247/api/v1beta3/redirect/namespaces/default/services/elasticsearch-logging </del> <ins> user@oban:~$ curl -v -k -u admin:4mty0Vl9nNFfwLJz https://104.197.5.247/api/v1beta3/redirect/namespaces/default/services/elasticsearch-logging/ </ins> * About to connect() to 104.197.5.247 port 443 (#0) *   Trying 104.197.5.247... * connected

Discussion:
is out of date. Please update for the current location/contents of the file and v1beta3. Once is submitted we should also update the examples to show to to curl using bearer tokens instead of basic auth credentials.
We're working on scrubbing the docs and examples of references to v1beta1 () prior to deleting that API, so it would be good to have this in soon.
: let me know if you want to punt this back to me -- now that I have some clue again about how to access an cluster (assuming I can create a cluster!).
Punting back to you. Getting the auth credentials is accomplished via But I think you have a better idea how to curl with token auth than I do.
Change:
"the cluster and that port 443 on the cluster's public address is proxied to this "+ "port. This is performed by nginx in the default setup. Set to zero to disable.") fs.MarkDeprecated("insecure-port", "This flag will be removed in a future version.") <ins> fs.Lookup("insecure-port").Hidden = false </ins> } // TODO: remove it until kops stop using `--address`

Discussion:
After merged, we should also show deprecated kube-apiserver flags.
/sig api-machinery
Change:
if len(fakeTable.Calls) != 1 || fakeTable.Calls[0] != "Get" { t.Errorf("unexpected calls create if not exists, exists: %v", fakeTable.Calls) } <ins> if len(fakeRoutes.Calls) != 1 || fakeRoutes.Calls[0] != "CreateOrUpdate" { t.Errorf("unexpected route calls create if not exists, exists: %v", fakeRoutes.Calls) } </ins> routeName := mapNodeNameToRouteName(false, route.TargetNode, string(route.DestinationCIDR)) routeInfo, found := fakeRoutes.FakeStore[cloud.RouteTableName][routeName]

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: Kubernetes shouldn't put route table when it's already been configured. Azure cloud provider should check whether the route has already been created before invoking . What you expected to happen: 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig cloud-provider /priority important-soon
Why this is a bug? A PUT operation should be idempotent and multiple calls should get the same result?
Right. But cloud provider shouldn't make unnecessary API calls.
To check whether it is configured, we need a GET call, so we're going to replace PUT call with GET call in this case?
it's not a replace, we need to LIST routes and check whether it has already been there, then PUT if it's not.
I got your point. But if we directly send a PUT request, seems route RP will also do this comparation? Is there any issue making us have to do the comparation by ourselves instead of sending PUT request to route RP?
It would help to reduce the chances of ARM PUT throttling.
I'd like to work on this
/assign