jiebi/CodeConvo huggingface dataset:
Code change:
local -ra docker_cmd=( "${DOCKER[@]}" run "${docker_run_opts[@]}" "${KUBE_BUILD_IMAGE}") <del> # Remove the container if it is left over from some previous aborted run "${DOCKER[@]}" rm -f -v "${KUBE_BUILD_CONTAINER_NAME}" >/dev/null 2>&1 || true </del> <ins> # Clean up container from any previous run kube::build::destroy_container "${KUBE_BUILD_CONTAINER_NAME}" </ins> "${docker_cmd[@]}" "$@" <del> # Remove the container after we run.  '--rm' might be appropriate but it # appears that sometimes it fails. See # https://github.com/docker/docker/issues/3968 "${DOCKER[@]}" rm -f -v "${KUBE_BUILD_CONTAINER_NAME}" >/dev/null 2>&1 || true </del> <ins> kube::build::destroy_container "${KUBE_BUILD_CONTAINER_NAME}" </ins> } # Test if the output directory is remote (and can only be accessed through

Related discussion:
text: Github automatically adds a artifact to every release, which sounds very similar to the artifact that we generate as the release artifact. Assuming we don't have control over the naming or presence of the autogenerated source code artifact, I think we should consider renaming our published artifact to better disambiguate between the two.
We distribute most of our artifacts outside of GitHub. We should probably stop uploading this one entirely.
cc
We've got a thread going on w/ Tim. /assign
can you please link so folks can follow the bread crumbs? ( cc )
-- It's currently sensitive. Will share once there's an outcome.
ACK. thanks for the heads up
I think it's safe to discuss openly at this point. We had a report that the sha512 hashes on our release artifacts were incorrect. We have confirmed that the mismatch was due to a bug in the release pipeline, and not malicious. This issue here was just a point of confusion that came out of that discussion.
thanks !
/assign
Going one step back since I think the exists for historical reasons: The client and server binaries were part of this bundle, which is not the case any more: So it seems that is mostly a collection of licenses and scripts. Do we really need it or may we cleanup some code paths and remove it completely?
+1 to put the word out and remove it completely if no one depends on it.
I'm not confident that CI is not using these versioned scripts, in fact i'm fairly sure that it is. However it would not be pulling it from github.
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 I think this remains as relevant as ever.
/milestone v1.23
/triage accepted
Hi and k8s 1.23 bug triage shadow here.
Code change:
local -ra docker_cmd=( "${DOCKER[@]}" run "${docker_run_opts[@]}" "${KUBE_BUILD_IMAGE}") <del> # Remove the container if it is left over from some previous aborted run "${DOCKER[@]}" rm -f -v "${KUBE_BUILD_CONTAINER_NAME}" >/dev/null 2>&1 || true </del> <ins> # Clean up container from any previous run kube::build::destroy_container "${KUBE_BUILD_CONTAINER_NAME}" </ins> "${docker_cmd[@]}" "$@" <del> # Remove the container after we run.  '--rm' might be appropriate but it # appears that sometimes it fails. See # https://github.com/docker/docker/issues/3968 "${DOCKER[@]}" rm -f -v "${KUBE_BUILD_CONTAINER_NAME}" >/dev/null 2>&1 || true </del> <ins> kube::build::destroy_container "${KUBE_BUILD_CONTAINER_NAME}" </ins> } # Test if the output directory is remote (and can only be accessed through

Related discussion:
text: There hasn't been any activity or linked PRs for this issue. Just wanted to check in to see if this is still on track for 1.23.
/milestone v1.24
Hi I am part of the bug triage team for v1.24. We noticed that this issue hasn't been updated for a while. Just wanted to check if there is any work planned that would go into this.
this one keeps moving down the milestones. i don't see any activity since november. So kick the can down the road /milestone v1.25
Hi My name Hossein Salahi from Bug-Triage team. I am just checking to ensure if everything is on track for K8s 1.25. Thanks!
That's a question for or
any remarks on that?
the release 1.25 bug triage Lead. I'm reaching out to see the status of this issue and if we are still targeting the current release. Also, kindly if you can update the priority so we can track it in the future.
this one keeps moving down the milestones yet again!. i don't see any activity since i moved this down the line. So kick the can down the road: /milestone clear (instead of v1.26 as this has been moving down the line for a few releases now)
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
What's the current status of this issue? Is there anything that we can do to move this forward?
We got new conversations going on during Kubecon on whether we should publish our release binaries on GitHub. Given that and I think we should rethink now what we publish on the release pages. I think we should start publishing all binaries for one. It is a common practice everywhere and I think users largely expect them to be there.
Code change:
local -ra docker_cmd=( "${DOCKER[@]}" run "${docker_run_opts[@]}" "${KUBE_BUILD_IMAGE}") <del> # Remove the container if it is left over from some previous aborted run "${DOCKER[@]}" rm -f -v "${KUBE_BUILD_CONTAINER_NAME}" >/dev/null 2>&1 || true </del> <ins> # Clean up container from any previous run kube::build::destroy_container "${KUBE_BUILD_CONTAINER_NAME}" </ins> "${docker_cmd[@]}" "$@" <del> # Remove the container after we run.  '--rm' might be appropriate but it # appears that sometimes it fails. See # https://github.com/docker/docker/issues/3968 "${DOCKER[@]}" rm -f -v "${KUBE_BUILD_CONTAINER_NAME}" >/dev/null 2>&1 || true </del> <ins> kube::build::destroy_container "${KUBE_BUILD_CONTAINER_NAME}" </ins> } # Test if the output directory is remote (and can only be accessed through

Related discussion:
text: let's scope the issue to the actual "Kubernetes Source Code" tarball. We can still remove it from what I can see from the discussion.
I agree with Removing the "Kubernetes Source Code" tarball should be as easy as removing this from krel: However, there are a few questions: is it safe to do so? I believe yes, because this "Kubernetes Source Code" tarball is pointing to the GCS bucket, and we'll still continue publishing that tarball to the bucket The link is also available in the changelog, so it's easy to find do we need any deprecation period? Considering the above two points, I don't think so. If you folks agree with that, I can go ahead and create a PR to update krel.
I agree on that, let's drop an additional note on k-dev that others are aware of the change.
/assign
Update: An announcement to proceed with the removal of the "Kubernetes Source Code" artifact has been sent to k-dev: PR to remove this artifact from being published: Removal will go into effect starting the January patch releases.
Code change:
if diff := cmp.Diff(tc.wantProfiles, profiles); diff != "" { t.Errorf("unexpected profiles (-want, +got):n%s", diff) } <ins> // Extenders if len(tc.wantExtenders) != 0 { // Scheduler.Extenders extenders := make([]string, 0, len(s.Extenders)) for _, e := range s.Extenders { extenders = append(extenders, e.Name()) } if diff := cmp.Diff(tc.wantExtenders, extenders); diff != "" { t.Errorf("unexpected extenders (-want, +got):n%s", diff) } // framework.Handle.Extenders() for _, p := range s.Profiles { extenders := make([]string, 0, len(p.Extenders())) for _, e := range p.Extenders() { extenders = append(extenders, e.Name()) } if diff := cmp.Diff(tc.wantExtenders, extenders); diff != "" { t.Errorf("unexpected extenders (-want, +got):n%s", diff) } } } </ins> }) } }

Related discussion:
text: <!-- 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 --here is supposed to be set through , but is not called from anywhere except tests, so always returns . should be set through here. Am I missing something? N/A None Kubernetes version (use ): master () Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: None
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 scheduling
Thanks for pointing that out. The plumbing of extenders to the framework impact calling extenders on preemption. That seems to be a path not covered by tests end to end. Can you submit a PR to fix this? as you mentioned we need to pass the extenders on profile creation. We need to patch the fix back to v1.21 and v1.20 (the release where this was refactored). /cc
I have submitted a PR for a fix.
Code change:
if err != nil { return "", err } <del> if isLocalInstance { if metadata.Compute.VMSize != "" { return metadata.Compute.VMSize, nil </del> <ins> if !isLocalInstance { if az.vmSet != nil { return az.vmSet.GetInstanceTypeByNodeName(string(name)) </ins> } <ins> // vmSet == nil indicates credentials are not provided. return "", fmt.Errorf("no credentials provided for Azure cloud provider") } if metadata.Compute.VMSize != "" { return metadata.Compute.VMSize, nil </ins> } }

Related discussion:
text: Currently there is no way to run without any identity (be it service principal or E/MSI). In reality code running on a worker node can use via - and only via - without the need to access ARM. Here is the proposed change a new mode authN = this mode, is basically telling the cloud provider to work any identity, this means only IMDS calls is allowed. This mode can be detected from if no SPN set and both MSI settings are set to . to use a config map within the cluster. This config map can be loaded on the cluster statically. or created - if not existent - in that then only is used in The net new result of the above is users bootstrapping clusters can configure the worker node to use without any identity on said worker nodes.
/sig azure These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by ‍
In-tree AzureDisk volume plugin is also depending on Azure credential to fetch lun id. we should figure out how to solve it without credential
fetch disk lun id is also a dependency in kubelet code now, after my investigation, it could be removed on Linux node, while it cannot be removed on Windows node, need to change the k/k upstream code, there is a discussion on going here: , let' wait for the discussion result.
For Linux: 1- use IMDS my understanding is new api versions will have the disk/lun pairs. 2- don't use arm for the return of is the second parameter passed to . For Windows: I don't understand the dep on ARM for this. The above still apply, we just need to find a way to encode the value as ut return from that allow us to find the disk by on a windows machine. might be a good source for this. Ideally speaking. The value should be the same. But i will leave it for you to decide.
could be a good idea since currently it's a LUN num returned by Attach() and then it could be changed to the windows disk num, I will make the code change on v1.15 later, thanks for discussion.
Update: PR would remove the VM API calls when getting the LUN number for AzureDisk.
Code change:
jig.SanityCheckService(svc, v1.ServiceTypeLoadBalancer) defer func() { framework.StopServeHostnameService(cs, f.InternalClientset, f.ScalesGetter, ns, serviceName) <ins> lb := cloudprovider.GetLoadBalancerName(svc) framework.Logf("cleaning gce resource for %s", lb) framework.CleanupServiceGCEResources(cs, lb, framework.TestContext.CloudConfig.Region, framework.TestContext.CloudConfig.Zone) </ins> }() ingressIP := framework.GetIngressPoint(&svc.Status.LoadBalancer.Ingress[0]) port := int(svc.Spec.Ports[0].Port)

Related discussion:
text: Our GKE scalability jobs (https://k8s-) are failing in the cluster teardown step (even though the e2e tests themselves passed). E.g failures: https://k8s- https://k8s- Seems like it's caused by some leaked network-related resources: /assign Krzysiek - Could you PTAL into this when you find time? It'll be great to have our GKE suite back to green. cc
I think this is related to an earlier bug we've seen (similar one for GCE): Basically service-controller is creating some cloud resources (like firewalls) for lb-type services which are not brought down properly when the k8s cluster is brought down.
Also another related issue - There should also be an internal bug for this somewhere. IMO we may be able to fix this in test-infra (without waiting for proper long-term fix on gke side).
I am adding clean-up method. This way all of the firewall rules will be cleaned up after tests. If this method has to remove any firewall rule, the teardown phase will return exception. It's not a fix for the bug - it only allows us to easy isolate tests leaking firewall rules.
Tests: should have session affinity work for LoadBalancer service with ESIPP on should be able to switch session affinity for LoadBalancer service with ESIPP on should have session affinity work for LoadBalancer service with ESIPP off should be able to switch session affinity for LoadBalancer service with ESIPP off leak resources related to the LoadBalancer. PR will fix this.
Code change:
var cpuFractionMap = make(map[string]float64) var memFractionMap = make(map[string]float64) <ins> // For each node, stores its pods info nodeNameToPodList := podListForEachNode(cs) </ins> for _, node := range nodes { <del> cpuFraction, memFraction, _, _ := computeCPUMemFraction(cs, node, requestedResource) </del> <ins> cpuFraction, memFraction, _, _ := computeCPUMemFraction(node, requestedResource, nodeNameToPodList[node.Name]) </ins> cpuFractionMap[node.Name] = cpuFraction memFractionMap[node.Name] = memFraction if cpuFraction > maxCPUFraction {

Related discussion:
text: From After , Multi-AZ Clusters tests in 1.19 and 1.20 started timing out as createBalancedPodForNodes is extremely inefficient in scale: for each node (out of 5k), it lists all pods in a cluster serially (each list takes ~5s), which translates to ~7 hours. Optimizing this function by listing pods once and then in memory by Spec.NodeName /kind bug /priority critical-urgent /sig scheduling
/triage accepted
/assign
/reopen Looks that ComputeCPUMemFraction took only 12 minutes, but it stuck later, on It is scheduling one pod per each node: Which is waiting 5s to be ready: 5k nodes * 5s = ~7h
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
/assign Can you do the pod creations in parallel?
Yes, good idea. I'll update to do that
Code change:
#     sleep 4 #     i=$[$i+1] #   done <del> apiVersion: v1beta1 </del> <ins> apiVersion: v1beta3 </ins> kind: Pod <del> id: synthetic-logger-0.25lps-pod desiredState: manifest: version: v1beta1 id: synth-logger-0.25lps containers: - name: synth-lgr image: ubuntu:14.04 command: ["bash", "-c", "i="0"; while true; do echo -n "`hostname`: $i: "; date --rfc-3339 ns; sleep 4; i=$[$i+1]; done"] labels: name: synth-logging-source </del> <ins> metadata: labels: name: synth-logging-source name: synthetic-logger-0.25lps-pod spec: containers: - args: - bash - -c - 'i="0"; while true; do echo -n "`hostname`: $i: "; date --rfc-3339 ns; sleep 4; i=$[$i+1]; done' image: ubuntu:14.04 name: synth-lgr </ins> ``` The other YAML file [synthetic_10lps.yaml](synthetic_10lps.yaml) specifies a similar synthetic logger that emits 10 log messages every second. To run both synthetic loggers:

Related discussion:
text: Hi , I followed the instructions in examples/logging-demo, and there was no "external IP" field for elasticsearch-logging or kibana-logging, as shown below: I start up my cluster via cluster/kube- Did I miss something or is it a bug? Thanks.
Correct. This demo does not create an ELB so there is no external IP address. Access is via service proxy at the master. Type: and you should see the URLs for Elasticsearch and Kibana.
please let us know whether: a. Satnam's comment resolves your issue b. the demo should be updated to prevent this misunderstanding c. the issue isn't resolved Thank you!
Yes, Satnam's comment resolve the issue. I updated the demo in .
Awesome, thanks for sending the patch! We'll discuss there. Always fantastic to have docs updated regularly by folks trying them.
Code change:
if m == nil { return &Timestamp{} } <ins> // truncate precision to microseconds to match JSON marshaling/unmarshaling truncatedNanoseconds := time.Duration(m.Time.Nanosecond()).Truncate(time.Microsecond) </ins> return &Timestamp{ Seconds: m.Time.Unix(), <del> Nanos:   int32(m.Time.Nanosecond()), </del> <ins> Nanos:   int32(truncatedNanoseconds), </ins> } }

Related discussion:
text: Found some error logs when sending series events to apiserver: seems the later eventTime differed from the first one in series events After investigation, I found the problem was in the marshal. MicroTime is supposed to work on microsecond level precision, but init with nanosecond level precision, in this case, generates microsecond level precision data and generates nanosecond level precision, so when unmarshalled, the new time is not considered the exactly same as the original time (they are different at nanosecond level) MicroTime marshal should work at same precision for json and proto, so unmarshal can generate the exactly same MicroTime result: This causes the series events won't be updated on api-server after created master <details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/assign
Good catch... we'd probably need to truncate to microseconds when marshaling and unmarshaling proto to ensure any already persisted data is fixed up when read. Something like this:
Thanks for advice, going to send a PR soon
Code change:
func (plugin *flexVolumePlugin) getExecutable() string { parts := strings.Split(plugin.driverName, "/") execName := parts[len(parts)-1] <del> return path.Join(plugin.execPath, execName) </del> <ins> execPath := path.Join(plugin.execPath, execName) if runtime.GOOS == "windows" { execPath = volume.GetWindowsPath(execPath) } return execPath </ins> } // Name is part of the volume.VolumePlugin interface.

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I have tried FlexVolume on a Windows node, it does not work. I am now working on this feature now. Below is the FlexVolume initialization error 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 ): v1.7.7 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig windows /assign
Detailed steps about how to use flexvolume on Windows with this PR:
cc:
Code change:
if err := s.validate(); err != nil { return nil, err } <del> dockercfgContent, err := handleDockercfgContent(s.Username, s.Password, s.Email, s.Server) </del> <ins> dockercfgJsonContent, err := handleDockerCfgJsonContent(s.Username, s.Password, s.Email, s.Server) </ins> if err != nil { return nil, err } secret := &v1.Secret{} secret.Name = s.Name <del> secret.Type = v1.SecretTypeDockercfg </del> <ins> secret.Type = v1.SecretTypeDockerConfigJson </ins> secret.Data = map[string][]byte{} <del> secret.Data[v1.DockerConfigKey] = dockercfgContent </del> <ins> secret.Data[v1.DockerConfigJsonKey] = dockercfgJsonContent </ins> if s.AppendHash { h, err := hash.SecretHash(secret) if err != nil {

Related discussion:
text: /kind bug We're having trouble retrieving images from a private registry on DockerCloud. For nearly a year the following has worked flawlessly. Last Friday I pulled down the 1.9.0 CLI (via brew) and since then have not been able to access any image in a private registry on DockerCloud. I've tried this on 10+ brand new clusters created with kops v1.8.0. The Kubernetes cluster version have been 1.8.0, 1.8.4, 1.8.5 and 1.9.0 (which is not supported by kops yet) and all exhibit the same problem. We create the secret as such: And verify it using: Which yields: And create a test service with with these contents: The pod fails immediatly with: I've reviewed the 1.9.0 release notes and nothing jumps out as the root cause. For reference I've tried putting quotes around the value when creating the secret to no avail. I've also tried prefixing the value with , so the full value would read: also to no avail. Environment: Kubernetes version: Cloud provider and installation info: AWS cluster built with Kops 1.8.0, using (to isolate this issue) nearly the default settings for everything.
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
I have same problem, and I "solved" it creating a docker-registry secret in an old kubernetes version and pasting it on new kubernetes
I'm recently (I know it worked perfectly about last month) facing issues with as well. For me it ended in a similar manner saying: I was able to confirm, that this is a kubernetes CLI related issue and not end user. Based on and this I was able to create properly formatted auth information looking like this: . When encoding this one-liner using (MacOS workstation) and apply like this works fine and images can be pulled from private repository again.