jiebi/CodeConvo huggingface dataset:
Change:
}) // Checks whether the output split by line contains the required elements. <del> func checkOutput(output string, required [][]string) { </del> <ins> func checkOutputReturnError(output string, required [][]string) error { </ins> outputLines := strings.Split(output, "n") currentLine := 0 for _, requirement := range required {

Discussion:
https://k8s- replica set controller maybe?
The rc seems to be updated almost a second after the failure. Maybe the test needs to retry
And the real log for the failure is
/assign flakes PRs at least once a day The can filter down to focus on a single test:
For when you have some time.
Reassign to you
Output of has been change in 1.6. That's why upgrade tests are failing. But I'm not sure why it is not failing 100% from the triage board. Do you know why? Output of 1.5 or earlier: Output in 1.6 or later:
The timeout is now. Is it reasonable to give it a little more time?
That timeout waits for the pods to run based on the API server. The rc controller is using its own cache so it may lag a bit before it actually updates the rc status. The test needs to retry for some time if the output we get back from describe does not match.
In other word, should also have its own retries.
SGTM. Going to send a fix today.
FYI, this test continues to flake PRs at least once per day:
should it show up in
Hm, this seems to fail in the upgrade tests. this failure seems to be related to an image name change as you already pointed out before. Mind finding what changed the test to use that image and fix the image name?
It is actually the key name has been changed in the key-value pair, not the value. As I pointed out in before expected key: now expected key:
Hm, this is unfortunate. These kubectl tests should really be unit tests.
the 24 hr test history is largely focused on failures right now, and this is highlighting flakes specifically (aka which tests are both passing and failing at the same commit the most often). Please follow the reports I'm sending to kubernetes-dev and related sigs. Also you can generate this info yourself using PS: also try out for finding failures (I'm sending out a separate email highlighting the biggest sources of failure). PPS: we are in the process of creating infrastructure to automate creating these reports, but automation never works as well as a fellow human asking for attention.
We still need to patch the release-1.4 and release-1.5 branch to make the upgrade tests passing.

I will send PRs later this week.
We didn't fix
The change mentioned in was introduced in 1.6. The change covers describer and kubectl e2e test. After discussing with we think we are not going to backport the changes to 1.4 and 1.5, instead we are going to skip the tests in version skew cases. WDYT?
should fix this issue
looks like the PR is resolved, should we close?
Please wait until fix to be cherrypick into 1.4.
Sure! Which PR is this?
Is it possible to cherrypick to 1.4 by just changing the milestone to 1.4?
no you need to create a new PR with the target branch of 1.4
Ready to close?
Yup. /close
Change:
// trigger a new deployment framework.Logf("%02d: triggering a new rollout for deployment %q", i, deployment.Name) deployment, err = e2edeployment.UpdateDeploymentWithRetries(c, ns, deployment.Name, func(update *appsv1.Deployment) { <del> newEnv := v1.EnvVar{Name: "A", Value: fmt.Sprintf("%d", i)} </del> <ins> newEnv := v1.EnvVar{Name: fmt.Sprintf("A%d", i), Value: fmt.Sprintf("%d", i)} </ins> update.Spec.Template.Spec.Containers[0].Env = append(update.Spec.Template.Spec.Containers[0].Env, newEnv) randomScale(update, i) })

Discussion:
Seen in the KIND e2e test: a) maybe we shouldn't log this more than 1x per second or something? b) maybe the error could make it clearer that the problem is the user's data? c) maybe we could fix the test triggering this? /sig api-machinery /wg apply Logs that I saw this in:
The 'duplicate entries for key' error came from validatingObjectWalker#visitListItems.
/assign
Yeah, they have multiple environment variables with the same name. I don't think that should be an error though ...
/cc
At the same time, it's not really useful to have multiple times the same variable and is probably a recipe for trouble.
It's definitely user error. Spamming apiserver logs about it doesn't help things, though.
I don't want to hide it, it's really not supposed to happen :-) it's not really user-data though. The fact that the error triggers here rather than in the actual validation means that there is a discrepancy between our validation and the regular validation. That's probably a problem that we have to fix. In that specific example, we can see that Kubernetes allows multiple environment variable with the same name, while we have assumed that it's not OK. It's a very legitimate error and we have to think about it to fix it. I think the test is relevant, and people out there are doing that. We could consider doing ratcheting if we want to stop allowing multiple variables, but I don't think that's how we want to fix that problem.
For history: should fix that.
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
We've definitely improved that, maybe let's close it for now.
/reopen We still see this happening. Kube users get nervous, I would too. Please fix the root cause.
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
Change:
Name:         "vol1", VolumeSource: v1.VolumeSource{NFS: &v1.NFSVolumeSource{Server: "localhost", Path: "/somepath", ReadOnly: false}}, } <del> doTestPlugin(t, volume.NewSpecFromVolume(vol)) </del> <ins> doTestPlugin(t, volume.NewSpecFromVolume(vol), "localhost:/somepath") } func TestIPV6VolumeSource(t *testing.T) { vol := &v1.Volume{ Name:         "vol1", VolumeSource: v1.VolumeSource{NFS: &v1.NFSVolumeSource{Server: "0:0:0:0:0:0:0:1", Path: "/somepath", ReadOnly: false}}, } doTestPlugin(t, volume.NewSpecFromVolume(vol), "[0:0:0:0:0:0:0:1]:/somepath") } func TestIPV4VolumeSource(t *testing.T) { vol := &v1.Volume{ Name:         "vol1", VolumeSource: v1.VolumeSource{NFS: &v1.NFSVolumeSource{Server: "127.0.0.1", Path: "/somepath", ReadOnly: false}}, } doTestPlugin(t, volume.NewSpecFromVolume(vol), "127.0.0.1:/somepath") </ins> } func TestPluginPersistentVolume(t *testing.T) {

Discussion:
In bare-metal IPv6 environment, any pod consuming storage resource is not able to run. The storage should be consumable, and the pod should become in status. Running the in a bare-metal IPv6 configurations. I have replaced the cloud-based storage resource with a mounted to a folder on my localhost. Steps alongside logs are below :- $kubectl get svc $kubectl describe svc nfs-server $kubectl describe pv nfs $kubectl get pod -w $kubectl get pod -w $kubectl describe pod nfs-busybox-6r96h I have built the master branch to make sure it was not fixed up to this moment.
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 storage
/sig storage /tirage accepted /assign
Change:
} wg.Done() }() <del> wg.Add(1) </del> } wg.Wait() <del> if len(nameToNodeInfo) != len(nodeList.Items) { </del> <ins> if len(nm.nameToNodeInfo) != len(nodeList.Items) { </ins> return errors.New("all nodes not mapped to respective vSphere") } return nil

Discussion:
Command run: vSphere intree volume test suite occasionally failed with the following error: The test suite should always pass. We may have a chance to hit this by running ` No response binary version: 1.27.4 </details<detailsvsphere </details<details</details<details</details<details</details<details</details
/assign
/sig testing storage ?
/triage accepted
Change:
set -o nounset set -o pipefail <del> # As of go 1.6, the vendor experiment is enabled by default. export GO15VENDOREXPERIMENT=1 #### HACK #### # Sometimes godep just can't handle things. This lets use manually put # some deps in place first, so godep won't fall over. preload-dep() { org="$1" project="$2" sha="$3" # project_dir ($4) is optional, if unset we will generate it if [[ -z ${4:-} ]]; then project_dir="${GOPATH}/src/${org}/${project}.git" else project_dir="${4}" fi echo "**HACK** preloading dep for ${org} ${project} at ${sha} into ${project_dir}" git clone "https://${org}/${project}" "${project_dir}" > /dev/null 2>&1 pushd "${project_dir}" > /dev/null git checkout "${sha}" popd > /dev/null } </del> KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "${KUBE_ROOT}/hack/lib/init.sh"

Discussion:
Didn't see an issue for this. Godep recently updated its version to v80. This broke several builds that directly godep, grabbing latest. /kind bug cc Example https://k8s- Here are some examples where we grab master:
We have helpers to grab godep. We should use them everywhere.
/cc
/assign
Change:
scheme  ObjectScheme decoder runtime.Decoder lock    sync.RWMutex <del> objects map[schema.GroupVersionResource][]runtime.Object </del> <ins> objects map[schema.GroupVersionResource]map[types.NamespacedName]runtime.Object </ins> // The value type of watchers is a map of which the key is either a namespace or // all/non namespace aka "" and its value is list of fake watchers. // Manipulations on resources will broadcast the notification events into the

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: I used to fake a clientset to test my code. I found that it became very slow to init the clientset with a big number of objects when I was trying to simulate a large scale cluster, and the time seemed exponential increasing. For example: Initializing a clientset with: 5000 objects took 300ms objects took 2.58s objects took 11.82s objects took 54.64s. It's because the fake clientset used a slice to store each kind of objects, so it's quite slow to init the clientset with massive objects because it checked existence of an object by traversing all objects and comparing with them before adding one, which leads to O(n^2) time complexity. What you expected to happen: The fake clientset is very useful for development, it should have a reasonable time complexity to allow developers to use it for large scale scenario. How to reproduce it (as minimally and precisely as possible): Run this code: You would see the time spent on each operation, like: Anything else we need to know?: Environment: Kubernetes version (use ): 1.15.0-1.18.0 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:
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
I had PR that uses map to store objects, which can reduce the init time to a reasonable value (tens of ms for objects). /assign
Change:
} if allowed := annotations[seccomp.AllowedProfilesAnnotationKey]; allowed != "" { for _, p := range strings.Split(allowed, ",") { <ins> if p == seccomp.AllowAny { continue } </ins> allErrs = append(allErrs, apivalidation.ValidateSeccompProfile(p, fldPath.Key(seccomp.AllowedProfilesAnnotationKey))...) } }

Discussion:
It should be possible to create a PodSecurityPolicy with zero restrictions. This was the intent with the (a.k.a. "AllowAny") allowed seccomp profile, but it is rejected during the validation phase. /kind bug
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/auth: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Change:
} hash := cur.Labels[apps.DefaultDaemonSetUniqueLabelKey] <del> if ds.DeletionTimestamp != nil || !dsc.expectations.SatisfiedExpectations(dsKey) { </del> <ins> if !dsc.expectations.SatisfiedExpectations(dsKey) { </ins> // Only update status. return dsc.updateDaemonSetStatus(ds, hash) }

Discussion:
/kind bug /priority critical-urgent What happened: In I'm removing all the reapers, unfortunately when invoking foreground deletion on a DaemonSet the delete operation hangs and controller indefinitely tries to manage a removed DS. What you expected to happen: A foreground deletion properly removes DaemonSet and all its dependents. How to reproduce it (as minimally and precisely as possible): Invoke a delete operation against kube API (without using command). Anything else we need to know?: This behavior makes it so that none of the consumers of the API is not able to remove the DS controller due to present in the DS reaper. A working fix that passed the tests with the aforementioned PR is in but I'm not 100% it's correct. This is an issue that needs fixing before 1.11 goes out. /assign /sig apps /cc
fyi
I filed to fix it. As mentioned in the PR, this is because the DaemonSet controller races with garbage collector when it tries to update DaemonSet status of the DaemonSet being deleted. Here's what happens when hangs: /something performs a foreground deletion on a DaemonSet finalizer and DeletionTimestamp are both set history objects (ControllerRevisions) and pods are being deleted by garbage collector; meanwhile, DaemonSet controller tries to update DaemonSet status. Updating DaemonSet status requires constructing DaemonSet history objects, to figure out current revision and which pods do/don't belong to current revision updating DaemonSet status, DaemonSet controller tries to create a DaemonSet history object that matches current DaemonSet spec collector then tries to delete that DaemonSet history object. And repeat. Because we can't make DaemonSet pods be deleted before DaemonSet history objects (DaemonSet history objects don't own DaemonSet pods!), we cannot reliably calculate DaemonSet status without history objects anyways. Therefore, we don't update DaemonSet status for DaemonSet being deleted. Note that the reason why the kubectl delete hack works is because it forces DaemonSet pods to be removed before history objects.
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed.

: Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
<ins> This directory forms the base of the main SaltStack configuration. The place to start with any SaltStack configuration is [top.sls](top.sls). However, unless you are particularly keen on reading Jinja templates, the following tables break down what configurations run on what providers. (NB: The [_states](_states/) directory is a special directory included by Salt for `ensure` blocks, and is only used for the [docker](docker/) config.) Key: M = Config applies to master, n = config applies to nodes Config                                              | GCE   | Vagrant | AWS | Azure ----------------------------------------------------|-------|---------|-----|------ [cadvisor](cadvisor/)                               | M n   | M n     | M n | M n [debian-auto-upgrades](debian-auto-upgrades/)       | M n   | M n     | M n | M n [docker](docker/)                                   | M n   | M n     | M n |   n [etcd](etcd/)                                       | M     | M       | M   | M [fluentd-es](fluentd-es/) (pillar conditional)      | M n   | M n     | M n | M n [fluentd-gcp](fluentd-gcp/) (pillar conditional)    | M n   | M n     | M n | M n [generate-cert](generate-cert/)                     | M     | M       | M   | M [kube-addons](kube-addons/)                         | M     | M       | M   | M [kube-apiserver](kube-apiserver/)                   | M     | M       | M   | M [kube-controller-manager](kube-controller-manager/) | M     | M       | M   | M [kube-proxy](kube-proxy/)                           |   n   |   n     |   n |   n [kube-scheduler](kube-scheduler/)                   | M     | M       | M   | M [kubelet](kubelet/)                                 | M n   | M n     | M n |   n [logrotate](logrotate/)                             | M n   |   n     | M n | M n [monit](monit/)                                     | M n   | M n     | M n | M n [nginx](nginx/)                                     | M     | M       | M   | M [openvpn-client](openvpn-client/)                   |       |         |     |   n [openvpn](openvpn/)                                 |       |         |     | M [sdn](sdn/) (Vagrant only)                          |   n   | M n     |   n | [static-routes](static-routes/) (vsphere only)      |       |         |     | [base](base.sls)                                    | M n   | M n     | M n | M n [kube-client-tools](kube-client-tools.sls)          | M     | M       | M   | M </ins>

Discussion:
We need to document all the configuration derived by Salt. Ideally this would be a markdown doc that we kept as live documentation within the project. The main reasons to bother: It's hard right now for anyone approaching the directory to get a big picture view of what's is going on, especially across providers. If we ever want to do something disciplined w.r.t. upgrade between (non-dev) versions, we're probably going to need a place to look for the state of the world. Decreasing the velocity with which people can add to Salt configuration will encourage people to delete more Salt configuration. cc
Change:
reportedLevels       []uint64 reportedCPURequests  []resource.Quantity reportedPodReadiness []v1.ConditionStatus <ins> reportedPodPhase     []v1.PodPhase </ins> scaleUpdated         bool statusUpdated        bool eventCreated         bool

Discussion:
/kind bug What happened: HPA fails to launch additional pods due to pods in evicted state, even with utilization significantly over target. What you expected to happen: When HPA pods reach the target utilization, new pods should be allocated and provisioned. How to reproduce it (as minimally and precisely as possible): Launch a HPA, let the pods fill the disk on the host which will trigger evictions due to "Pod The node was low on resource: [DiskPressure]", HPA will exceed target and not allocate additional pods. Anything else we need to know?: Seems related to and though those are not specific to HPA. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): cos-stable-57-9202-64-0 kernel commit id Kernel (e.g. ):Linux gke-prod1-use1b-v2--35s4 4.4.70+ SMP Mon Sep 18 12:43:08 PDT 2017 x86_64 Intel(R) Xeon(R) CPU @ 2.30GHz GenuineIntel GNU/Linux
/sig scheduling
Are there any workarounds while we wait for a fix? We have ran into this on a 1.8.4 GKE cluster.
/sig autoscaling /remove-sig scheduling
I am thinking of fixing this by excluding pods with Phase=Failed from the unreadyPods that are taken into account. It seems the right thing to do as they will not become running again. Do you see any issues?
that seems decent -- anything that will never be running again should not be factored into our calculations.
/status approved-for-milestone Adding to milestone -- if the HPA isn't functioning in the case of evictions, that seems like a decently severe HPA bug.
oops, missing priority was my fault, moving back into milestone: /priority critical-urgent /remove-priority important-soon
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues.

Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details