jiebi/CodeConvo huggingface dataset:
Change:
fi fi <ins> if [[ "${CLUSTER_DNS_CORE_DNS:-}" == "true" ]]; then update-coredns-config fi </ins> echo "== Validating cluster post-upgrade ==" "${KUBE_ROOT}/cluster/validate-cluster.sh"

Discussion:
Which jobs are failing: Multiple jobs on . Which test(s) are failing: on the following jobs: Since when has it been failing: Since 5/17. Testgrid links: See above. Reason for failure: All the failures mentioned above seem to have to have the same root cause, namely failure while waiting for CoreDNS to be ready. Example: /sig testing /priority critical-urgent /kind failing test /milestone v1.15 /cc
Some of this (possible all of it) is due to , which is dependent on being merged.
/sig cluster-lifecycle
Not the gce jobs thoght. Only the kinder job. So the gce jobs are failing with a problem outside of kubeadm/kinder but possibly still related to the corefile plugin change
/assign (At kubecon this week)
The gce failures appear to show the same behavior, but with kube-up instead of kubeadm. I.e. it appears that kube-up may also be retaining old configs when upgrading/downgrading. If thats true, then we may need to integrate the migration tools into kube-up as well.
I have opened which aims to fix all the failing tests except , which will be fixed via
Great job so far and Would it be possible to ask for the open PRs to be merged and/or a solution found soon? We have these tests failing for quite some time and code freeze coming up in the next days. Thank you in advance for your efforts!
thanks for the heads up. let me know if you don't have the time for the refactor that i requested and i can try to take over there. the alternative is to rollback the coredns version which i assume is not ideal, due to a variety of fixes in the new version.
is there any more work planned for this issue? I see that some of the kinder jobs are still failing after merged:
merging and will resolve and close this issue.
Thank you for the update !
updates: kinder tests were fixed via
/unassign i was here for: it's a bit flaky (which is due to the tooling), but green.
Since and we're moved to 1.16, and we're waiting for to merge, can we move this issue to 1.16?
? is that the right PR?

Good catch, I meant
The GCE test failures were fixed by and /close
Closing this issue. <detailsIn response to : The GCE test failures were fixed by and /close 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:
} // Inject error to underlying layer and check if cacher is not bypassed. <del> backingStorage.err = errDummy </del> <ins> backingStorage.injectError(errDummy) </ins> err = cacher.GetList(context.TODO(), "pods/ns", storage.ListOptions{ ResourceVersion: "0", Predicate:       pred,

Discussion:
As Jordan pointed out in: watchcache treats RV=0 and RV="" the same way, even though it's not what we document: This should be fixed. /kind bug /sig api-machinery /priority important-soon
/assign
/triage accepted
Change:
// SetCRDCondition sets the status condition. It either overwrites the existing one or creates a new one. func SetCRDCondition(crd *CustomResourceDefinition, newCondition CustomResourceDefinitionCondition) { <ins> newCondition.LastTransitionTime = metav1.NewTime(time.Now()) </ins> existingCondition := FindCRDCondition(crd, newCondition.Type) if existingCondition == nil { <del> newCondition.LastTransitionTime = metav1.NewTime(time.Now()) </del> crd.Status.Conditions = append(crd.Status.Conditions, newCondition) return } <del> if existingCondition.Status != newCondition.Status { existingCondition.Status = newCondition.Status </del> <ins> if existingCondition.Status != newCondition.Status || existingCondition.LastTransitionTime.IsZero() { </ins> existingCondition.LastTransitionTime = newCondition.LastTransitionTime } <ins> existingCondition.Status = newCondition.Status </ins> existingCondition.Reason = newCondition.Reason existingCondition.Message = newCondition.Message }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: the for a CRDs Established condition is always null What you expected to happen: it should have a timestamp How to reproduce it (as minimally and precisely as possible): create a CRD and then examine its yaml/json. For example: Anything else we need to know?: Environment: community master
/assign
/area custom-resource
/sig api-machinery /area custom-resources
/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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
edit: actually, that issue is about kubectl display and clock skew. this issue is about the condition timestamp updating, which still requires correction
Closing this issue. <detailsIn response to : duplicate of 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
Hello I'm a bug triage shadow for the 1.16 release cycle and considering this issue is tagged for 1.16, I'd like to check its status. Code freeze is starting on August 29th (about 3 days from now), which means that this PR must merged by then. Do we still target this issue to be fixed for 1.16?
yes, will take a look at it tomorrow /assign
Change:
1 /* expectedSetUpCallCount */, testKubelet.volumePlugin)) // Remove pod <del> // TODO: this may not be threadsafe (technically waitForVolumeUnmount) kubelet.podWorkers.(*fakePodWorkers).removeRuntime = map[types.UID]bool{pod.UID: true} </del> <ins> // TODO: technically waitForVolumeUnmount kubelet.podWorkers.(*fakePodWorkers).setPodRuntimeBeRemoved(pod.UID) </ins> kubelet.podManager.SetPods([]*v1.Pod{}) assert.NoError(t, kubelet.volumeManager.WaitForUnmount(pod))

Discussion:
pull-kubernetes-unit TestVolumeUnmountAndDetachControllerDisabled It failed on but after that the test is passing DATA RACE It seems that the data race is caused by below code It failing of test is Flaky, it was not reproducible on my local machine too, I have used below command to run the test output on my local machine I would like to work on this issue, is it possible to reproduce this issue locally?
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
SIG Testing owns test frameworks, CI infrastructure, and other things to support testing. But this test is owned by SIG storage I believe since it tests their code, as we own tests that test our code.
Change:
return 0, framework.NewStatus(framework.Error, fmt.Sprintf("injecting failure for pod %v", p.Name)) } <del> score := 10 </del> <ins> score := 1 </ins> if sp.numScoreCalled == 1 { // The first node is scored the highest, the rest is scored lower. sp.highScoreNode = nodeName <del> score = 100 </del> <ins> score = framework.MaxNodeScore </ins> } return score, nil }

Discussion:
What would you like to be : a default normalize score function in the scheduling framework. the plugin and log an error when the normalizing phase returns an invalid range of scores. Why is this needed: Per discussion in , we should enforce the range of score returned by the scoring plugin. /sig scheduling /priority important-soon /assign
Change:
create 0644 root root } EOF <del> done </del> } # Finds the master PD device; returns it in MASTER_PD_DEVICE

Discussion:
GCI log rotation configuration missed "" file. We should just configure log rotation to rotate all "*.log" files in /var/log.
I cherrypicked your change last night. Please do what you need to do to confirm this is resolved.
Thank you, will do.
Verified. Closing issue.
Change:
"fmt" "io" "io/ioutil" <ins> "net" </ins> "net/http" "os" "regexp"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The Kubernetes master created routes in the neutron router that assign an IPv6 nexthop for a IPv4 prefix. This is not possible and causes a reachability problem between the pods. Example route: What you expected to happen: When describing a node the master has the following information It should detect the address type and choose the correct InternalIP How to reproduce it (as minimally and precisely as possible): Deploy on a Openstack cloud with IPv6 enabled using the following playbook Anything else we need to know?: The wrong next hop is coming from calling the function and nowhere is a check if the address is IPv4 or IPv6 Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Openstack OS (e.g. from /etc/os-release): Ubuntu Xenial Kernel (e.g. ):Install tools: Others: /sig openstack
- Thank you for this detailed analysis. Seems to me that the best way to address this would be to add an IP family argument to getAddressByName() to let it know what V4/V6 family to look for for a next-hop address. In the calls to getAddressByName(), this argument could be set based on the family of route.DestinationCIDR.
Issue is probably related.
Change:
const ( // CloudProviderName is the value used for the --cloud-provider flag <del> CloudProviderName      = "azure" </del> <ins> CloudProviderName = "azure" // AzureStackCloudName is the cloud name of Azure Stack AzureStackCloudName    = "AZURESTACKCLOUD" </ins> rateLimitQPSDefault    = 1.0 rateLimitBucketDefault = 5 backoffRetriesDefault  = 6

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : PR() already proves that old api-version on Azure stack works on global Azure too, we could support azure stack in azure cloud provider lib, and then make sure following components works in Azure stack: CSI drivers: azure disk, azure file CCM Since it's mainly api-version change, we could also add e2e tests against global Azure too. Why is this needed: /assign /priority important-soon /sig cloud-provider /area provider/azure
there is blocking issue here(also need azure stack supports latest data model struct): just making the change in interfaces and not go-sdk but facing this error, since we don't have a switch inside go-sdk, we only do switch in azure cloud provider lib,
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
Change:
kube::release::create_tarball "${package_name}" "${release_stage}/.." } <del> # This is all the stuff you need to run/install kubernetes.  This includes: #   - precompiled binaries for client </del> <ins> # This is all the platform-independent stuff you need to run/install kubernetes. # Arch-specific binaries will need to be downloaded separately (possibly by # using the bundled cluster/get-kube-binaries.sh script). # Included in this tarball: </ins> #   - Cluster spin up/down scripts and configs for various cloud providers <del> #   - tarballs for server binary and salt configs that are ready to be uploaded </del> <ins> #   - Tarballs for salt configs that are ready to be uploaded </ins> #     to master by whatever means appropriate. <del> function kube::release::package_full_tarball() { kube::log::status "Building tarball: full" </del> <ins> #   - Examples (which may or may not still work) #   - The remnants of the docs/ directory function kube::release::package_final_tarball() { kube::log::status "Building tarball: final" # This isn't a "full" tarball anymore, but the release lib still expects # artifacts under "full/kubernetes/" </ins> local release_stage="${RELEASE_STAGE}/full/kubernetes" rm -rf "${release_stage}" mkdir -p "${release_stage}" <del> # Copy all of the client binaries in here, but not test or server binaries. # The server binaries are included with the server binary tarball. local platform for platform in "${KUBE_CLIENT_PLATFORMS[@]}"; do local client_bins=("${KUBE_CLIENT_BINARIES[@]}") if [[ "${platform%/*}" == "windows" ]]; then client_bins=("${KUBE_CLIENT_BINARIES_WIN[@]}") fi mkdir -p "${release_stage}/platforms/${platform}" cp "${client_bins[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/platforms/${platform}" done </del> <ins> mkdir -p "${release_stage}/client" cat <<EOF > "${release_stage}/client/README" Client binaries are no longer included in the Kubernetes final tarball. Run cluster/get-kube-binaries.sh to download client and server binaries. EOF </ins> # We want everything in /cluster except saltbase.  That is only needed on the # server.

Discussion:
Either include non-arch specific stuff in every tar or break that out too. ref cc
interested in helping with this one?
Yes, I may help
OK, I did not actually understand what was in , apparently. Alternate proposal: [ ] update all references that need just server binaries to download the server tarball directly [ ] same for places that just need (related to ) [ ] remove all arch-specific binary artifacts from and replace with a script which downloads the client/server tarballs as necessary. The alternative option, including all of the non-arch-specific code and docs in an arch-specific starts to get very tricky, since we run into a large cross product of client x server platforms/archs.
Change:
# # We specify -X to avoid a race condition that can cause minion failure to # install.  See https://github.com/saltstack/salt-bootstrap/issues/270 <del> wget -q -O - https://bootstrap.saltstack.com | sh -s -- -X </del> <ins> curl -L --connect-timeout 20 --retry 6 --retry-delay 10 https://bootstrap.saltstack.com | sh -s -- -X </ins>

Discussion:
When wgetting to this address during the installation process, this just fails silently. Turns out the issue is that if you take a raw and curl that address you get a TLS error. I've fixed it by changing to , but obviously that's more risky.
Related (filed after an email exchange around wget) I don't have easy access to the vSphere so I can't verify how it relates to my debian install.
Yes, that is exactly the error I was experiencing.
Does curl work? Or is it busted too?
Curl is not installed on the image by default. I'm building a new image based on Debian 7.7 where I pull in curl by default, so we can switch to using that everywhere (instead of an awkward mix of wget and curl).
Thanks for reporting this I hadn't seen this yet. I uploaded a new VMDK that includes curl and updated the deployment scripts to use curl. I verified that deployment works again for me.
I can confirm that this works now with latest build from master on ESX. Probably still won't work with v0.4.3 (even w new image) since the scripts still used wget back then.
We are probably going to fork for v0.5 soon. But I can backport if this trips folks up. sent from tiny keyboard On Nov 12, 2014 9:09 AM, "Ben Smith" wrote:
Change:
return &runtimeapi.ListContainersResponse{Containers: result}, nil } <ins> func (ds *dockerService) getContainerCleanupInfo(containerID string) (*containerCleanupInfo, bool) { ds.cleanupInfosLock.RLock() defer ds.cleanupInfosLock.RUnlock() info, ok := ds.containerCleanupInfos[containerID] return info, ok } func (ds *dockerService) setContainerCleanupInfo(containerID string, info *containerCleanupInfo) { ds.cleanupInfosLock.Lock() defer ds.cleanupInfosLock.Unlock() ds.containerCleanupInfos[containerID] = info } func (ds *dockerService) clearContainerCleanupInfo(containerID string) { ds.cleanupInfosLock.Lock() defer ds.cleanupInfosLock.Unlock() delete(ds.containerCleanupInfos, containerID) } </ins> // CreateContainer creates a new container in the given PodSandbox // Docker cannot store the log to an arbitrary location (yet), so we create an // symlink at LogPath, linking to the actual path of the log.

Discussion:
What happened: Windows kubelet panic occasionally on nodes which have high volume of pods run and delete. Full logs: Preliminary investigate result: How to reproduce it (as minimally and precisely as possible): Run high volume of pods and delete them when they completed in Windows nodes. Environment: Kubernetes version (use ): 1.17.7 Cloud provider or hardware configuration: Azure AKS OS (e.g: ): Windows Server 2019 Kernel (e.g. ): 10.0..1282
/assign I would like to give this a shot.
/remove-sig windows I think this is not a windows specific problem. /sig node /area kubelet
Hi! Thanks for your report, I have filed to address this issue.
This issue is a bit urgent for our situation, it occurs every few days in production clusters. Seems the PR is pending a few days, is it possible to increase the priority to merge it trunk and 1.17/1.18 branch? Thanks
I understand how urgent this issue is, but I am not privileged to do anything further :(
Do you know anyone who can help?
looks like a simple fix, add a lock for , I could help.
There is already a fix by , the problem is the PR is pending, not sure if you or someone can increase the priority to merge it trunk and 1.17/1.18 branch asap. Our AKS clusters are affecting by this frequently.
Thanks guys.
Change:
} func (fp *tokenFilter) PreFilter(ctx context.Context, state *framework.CycleState, pod *v1.Pod) (*framework.PreFilterResult, *framework.Status) { <del> return nil, nil </del> <ins> if !fp.EnablePreFilter || fp.Tokens > 0 { return nil, nil } return nil, framework.NewStatus(framework.Unschedulable) </ins> } func (fp *tokenFilter) AddPod(ctx context.Context, state *framework.CycleState, podToSchedule *v1.Pod,

Discussion:
In k8s 1.27, scheduler introduced a new "short circuit" semantics in PreFilter to bypass a Pod quickly. A change introduced here is it relies on that plugin to be stored in , which makes sense as what it was explained . However, the info, although is populated upon each plugin's PreFilter invocation, is not injected into when some PreFilter returns unschedulable: So think about this workflow: pluginA returns Skip in its PreFilter pluginB return Unschedulable in its PreFilter note: pluginA is not included in due to aforementioned bug a Pod is claimed as unschedulable (failed by pluginB) during PostFilter, it's supposed to bypass pluginA's PreEnqueueExtension's AddPod/RemovePod, but it doesn't calling a "skipped" Plugin's AddPod/RemovePod during preemption, sometimes will abort the whole preemption as the logic tries to read info from cycleState, and some plugin's "skip" version doesn't fill cycleState properly, e.g., InterPodAffinity (skip immediately w/o write preFilterStateKey). Short circuiting using Skip is fine, but should injected properly at all cases. Described in the workflow above. It's firstly captured in an out-of-tree PostFilter plugin: , but can also happen in in-tree plugins. No response v1.27 <details</details<details</details<details</details<details</details<details</details
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
/kind regression /sig scheduling
cc
Among in-tree plugins, 3 plugins employ non-nil and may return Skip in their PreFilter() implementation w/o writing to cycleState, while return error immediately if is missing in their Add/RemovePod() functions.

So technically, as long as a scheduling flow hit the following criteria, it would hit the bug (preemption doesn't function): plugin 1/2/3 return Skip in PreFilter arbitrary PreFilter plugin after the "skipped" plugin returns Unschedulable in its PreFilter
/cc
/cc
Cherry-pick PRs: 1.28: 1.27:
Change:
// loadbalancer's backend hosts. In this case, request will not hit the loadbalancer but loop back directly. // Need to add the following rule to allow request on host. if allowFromNode { <del> writeLine(proxier.natRules, append(args, "-s", fmt.Sprintf("%s/32", ingress.IP), "-j", "ACCEPT")...) </del> <ins> writeLine(proxier.natRules, append(args, "-s", utilproxy.ToCIDR(net.ParseIP(ingress.IP)), "-j", "ACCEPT")...) </ins> } // If the packet was able to reach the end of firewall chain, then it did not get DNATed.

Discussion:
We are working migrating ipv4 to ipv6, we should support ipv6 for IPVS. We should do the following things: remove ipv4 constraints of Node IPs() remove ipv4 in pkg/util/ipvs() use ipv6 conntrack tools use ipv6 iptables tools <!-- 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 feature /sig network /assign /cc
/area ipv6
FYI: I've just posted a PR (PR ) to fix the way that kube-proxy was calling conntrack without the required "-f ipv6" CLI flag whenever conntrack was being executed for a service that's using IPv6 addresses. There were a couple of lines in that needed to be changed. I don't think I can add UT coverage for those lines until more support for IPv6 addresses is to Cc
ACK! I will take care of , please feel free to ping me when you want my hand :)
Sounds good, is all yours. :) Likewise, let me know if I can help.
Sure, mate.
Change:
mountEtcHostsFile = mountEtcHostsFile && (mount.MountPath != etcHostsPath) vol, ok := podVolumes[mount.Name] if !ok || vol.Mounter == nil { <del> glog.Warningf("Mount cannot be satisfied for container %q, because the volume is missing or the volume mounter is nil: %q", container.Name, mount) continue </del> <ins> glog.Errorf("Mount cannot be satisfied for container %q, because the volume is missing or the volume mounter is nil: %+v", container.Name, mount) return nil, fmt.Errorf("cannot find volume %q to mount into container %q", mount.Name, container.Name) </ins> } relabelVolume := false

Discussion:
<!-- 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: The makeMounts function adding volumes to the volumes list if the volume doesn't exist or mounter doesn't exist. This is potentially dangerous behavior because an application can write to the mount path (if it already exists in the container image) expecting it to be backed by a persistent volume, but in fact, is only backed by the container rootfs, which is ephemeral. We probably have not seen this issue manifest in the wild because the volume not existing or mounter being nil should never happen, and also the application would probably see a path/file does not exist error first. What you expected to happen: If we can't mount all of the user's requested volumes into the container, we should fail to start the container. /assign /sig storage node /cc