jiebi/CodeConvo huggingface dataset:
Change:
var _ = SIGDescribe("Deployment", func() { var ns string var c clientset.Interface <ins> var dc dynamic.Interface </ins> ginkgo.AfterEach(func() { failureTrap(c, ns)

Discussion:
[x] Original approval issue: [x] Test pr: [x] Two weeks soak end date: 19 November 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still some remaining Deployment endpoints which are untested. a Deployment with a static label the Deployment with a new Label and updated data the Deployment to ensure it's patched all Deployments in all Namespaces find the Deployment(1) ensure that the Deployment is found and is patched Namespaced Deployment(1) via a Collection with a LabelSelector Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 5 points* This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
BobyMcbobs commented in original Issue: Unsure if the endpoint replaceAppsV1NamespacedDeploymentStatus is able to be hit. When this endpoint is attempted to be updated the data after retrieving the update resource doesn't reflect the values in the update
/assign
When using the appv1.Deployment structure instead of maps of interfaces to build the structure in a patch of the Deployment, this error comes up. Still in progress yment-static":"true"}: does not match template , spec.selector: Invalid value: "null": field is immutable]
replaceAppsV1NamespacedDeploymentStatus to test. Increase cover by 1 Endpoint
/reopen PR reverted by due to flaky test
Reopened this issue. <detailsIn response to : /reopen PR reverted by due to flaky test 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
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
/reopen Soaking, ready for promotion 19 November 2020
Reopened this issue. <detailsIn response to : /reopen Soaking, ready for promotion 19 November 2020 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
/remove-lifecycle stale
/triage accepted
/merged
Change:
${image_service_endpoint_args}  --port="$KUBELET_PORT" >"${KUBELET_LOG}" 2>&1 & KUBELET_PID=$! <ins> # Quick check that kubelet is running. if ps -p $KUBELET_PID > /dev/null ; then echo "kubelet ( $KUBELET_PID ) is running." else cat ${KUBELET_LOG} ; exit 1 fi </ins> else # Docker won't run a container with a cidfile (container id file) # unless that file does not already exist; clean up an existing

Discussion:
Problem Local-up-cluster will start normally even if the hyperkube kubelet startup command fails. Solution Ensure local-up-cluster fail-fast if things are broke or if individual daemons dont start
Change:
netutils "k8s.io/utils/net" ) <ins> const ( UnprivilegedUserToken = "unprivileged-user" ) </ins> // Config is a struct of configuration directives for NewControlPlaneComponents. type Config struct { // If nil, a default is used, partially filled configs will not get populated.

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/kind flake <!-- Please assign a SIG using: /sig SIG-NAME --/sig api-machinery
/assign I want to take a try
2 but actual 0 till timeout resource services, expected 2, actual 0 error waiting or ResourceQuota status: timed out waiting for the condition time later, actual state became 2 Seems polls a ResourceQuota status with timeout 10s may be not enough, we should enlarge it into 300s, that is poll for 300s timeout instead of 10s.
/triage accepted
Change:
package apps_test import ( <del> "testing" </del> . "github.com/onsi/ginkgo" <ins> . "github.com/onsi/ginkgo/config" . "github.com/onsi/ginkgo/types" </ins> . "github.com/onsi/gomega" <ins> "fmt" "testing" </ins> ) func TestApps(t *testing.T) { RegisterFailHandler(Fail) <del> RunSpecs(t, "Apps Suite") </del> <ins> RunSpecsWithDefaultAndCustomReporters(t, "Apps Suite", []Reporter{newlineReporter{}}) </ins> } <ins> // Print a newline after the default newlineReporter due to issue // https://github.com/jstemmer/go-junit-report/issues/31 type newlineReporter struct{} func (newlineReporter) SpecSuiteWillBegin(config GinkgoConfigType, summary *SuiteSummary) {} func (newlineReporter) BeforeSuiteDidRun(setupSummary *SetupSummary) {} func (newlineReporter) AfterSuiteDidRun(setupSummary *SetupSummary) {} func (newlineReporter) SpecWillRun(specSummary *SpecSummary) {} func (newlineReporter) SpecDidComplete(specSummary *SpecSummary) {} // SpecSuiteDidEnd Prints a newline between "35 Passed | 0 Failed | 0 Pending | 0 Skipped" and "--- PASS:" func (newlineReporter) SpecSuiteDidEnd(summary *SuiteSummary) { fmt.Printf("n") } </ins>

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind flake What happened: TestApps always failed Anything else we need to know?: https://k8s- https://k8s- /sig testing
my pr appear same problem. i will investigate the cause later.
/sig cli
/assign
GitHub didn't allow me to assign the following users: zjj2wry. Note that only can be assigned. <detailsIn response to : /assign 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
fails when run by . Stress testing runs 1000 times locally without any errors. https://k8s-
Hit this again here https://k8s-
this is odd... the test output actually shows TestApps succeeding in that run:
Happened again: https://k8s- The messages were interleaved . was appended at the end. I think that threw off.
By the looks of test grid, it looks like it's been failing consistently in both presubmit and postsubmit builds: https://k8s- https://k8s- The logs are happy, the junit output is not. Maybe it has something to do with the fact that ginkgo is used to run the test cases? It's used for TestOpenapi tests as well. There was an issue on those tests failing for what looks like the same reason Looks like they were fixed by /kind bug /priority failing-test
cc
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. If the required changes are not made within 6 days, the issue will be moved out of the v1.8 milestone. priority: Must specify exactly one of [, , ]. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Change:
make -C "${KUBE_ROOT}" WHAT=vendor/k8s.io/code-generator/cmd/import-boss <del> packages=("k8s.io/kubernetes/pkg/..." "k8s.io/kubernetes/cmd/..." "k8s.io/kubernetes/plugin/..." "k8s.io/kubernetes/test/e2e/framework/...") </del> <ins> packages=( "k8s.io/kubernetes/pkg/..." "k8s.io/kubernetes/cmd/..." "k8s.io/kubernetes/plugin/..." "k8s.io/kubernetes/test/e2e/framework/..." "k8s.io/kubernetes/test/integration/..." ) </ins> for d in staging/src/k8s.io/*/; do if [ -d "$d" ]; then packages+=("./vendor/${d#"staging/src/"}...")

Discussion:
What happened: Integration tests import e2e test code today and the dependency makes two drawbacks. It is hard to move test/e2e/framework into staging () Need to run integration tests always even if PRs are just changing e2e test code This PR is for removing this dependency from integration tests. Target dependencies Following files are importing e2e test code from integration tests: [x] () [x] () [x] () and we need to put file for blocking such dependency anymore.
/sig testing /area code-organization
/remove-kind bug
/assign
for /assign
Change:
func InitMultiVolumeTestSuite() TestSuite { return &multiVolumeTestSuite{ tsInfo: TestSuiteInfo{ <del> name: "multiVolume", </del> <ins> name: "multiVolume [Slow]", </ins> testPatterns: []testpatterns.TestPattern{ testpatterns.FsVolModePreprovisionedPV, testpatterns.FsVolModeDynamicPV,

Discussion:
created a spread sheet of the slowest running tests for the pull-kubernetes-gce job. cc discussion on slack: spreadsheet: pie chart of test durations from SIGs: ! it seems appropriate to evaluate the state of the tests and reduce these runtimes. possibly move tests to periodic by marking them as [Slow]. /assign /kind design /area test (?)
/remove-kind bug
Are pull jobs the right place to be calculating the time? Or should be be counting in CI instead?
pull is the one timing out, so probably?
Looking at some of the top slowness:: subPath should fail for new directories when readOnly specified in the volumeSource: This test case is no longer defined in master HostPathType: This test case has not been checked in yet and is trying to be in a PR PersistentVolumes-local StatefulSet with pod affinity should use volumes spread across nodes when pod has anti-affinity: This test is already marked as slow in master
Created This should address most of the top slow storage tests
Change:
}) } <del> newVM := compute.VirtualMachine{ Location: vm.Location, </del> <ins> newVM := compute.VirtualMachineUpdate{ </ins> VirtualMachineProperties: &compute.VirtualMachineProperties{ HardwareProfile: vm.HardwareProfile, StorageProfile: &compute.StorageProfile{

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Instead of using the VM CreateOrUpdate () function of the Azure Go SDK, use the VM Update function () in the azureclient () Why is this needed: Currently, the Azure Cloud Provider is using the VM CreateOrUpdate call when e.g. detach/attaching disks to a VM. In some scenarios, this will re-create a VM that was deleted by an external application. This can lead to orphaned VMs or blocked resources. The Update function will only update an existing VM and will fail if the VM does not exist.
/sig azure
/assign
/sig cloud-provider
Could you describe more about the scenarios? Have you noticed such issues? I wonder adding etags to the API call could help to prevent this?
If you have an application that maintains your K8s clusters, e.g. takes care of OS update/patching. If the application wants to patch the OS of a worker node, it would drain the node first. If draining times out, it will go ahead and delete the VM anyway. But K8s might still be detaching disks. These detach operations, because they use CreateOrUpdate, will recreate the VM. Is there a reason why you would want to create a VM i.e. why CreateOrUpdate is required and Update would not work? AFAIK, Azure Compute RP does not support etags.
that sounds reasonable, thanks change to use function would be safer since it's only detach/attach disk operation. I will do that.
thanks for the information. Reasonable enough. /assign
/milestone v1.16
BTW, the reason why we only use func in the beginning is that Azure Compute go sdk did not provide a func at that time...
Great. Thanks!
Change:
t.Errorf("unexpected error: %v", err) } <del> expectedOut := []string{"Unschedulable", "true", "holder"} </del> <ins> expectedOut := []string{"Unschedulable", "true", "holder", `Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource           Requests     Limits --------           --------     ------ cpu                1 (25%)      2 (50%) memory             1Gi (8%)     2Gi (16%) ephemeral-storage  0 (0%)       0 (0%) hugepages-1Gi      0 (0%)       0 (0%) hugepages-2Mi      512Mi (25%)  512Mi (25%)`} </ins> for _, expected := range expectedOut { if !strings.Contains(out, expected) { t.Errorf("expected to find %q in output: %q", expected, out)

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: scheduler doesn't assign pod because 'not enough resource: hugepages-1Gi',but the node info show it has enough resource. describe node What you expected to happen: the pod was in normal status like pending and running How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: It was change default hugepage size to 1Gi and hugepages=36 numastat was show there has enough hugepage also proc/meminfo was show there has enough resource other info 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 node
cc do you have thoughts here? I see huge pages and think of you :)
Hmm. Are you sure that there are no other pods using huge page memory ? To me, it looks like the node has (huge page @ 1GiB) memory, you are requsting , but is already used. Can you verify that by listing the pods on the node, and check if some of them are using huge page memory already?
Also, the OS will report that no huge pages are in use as long as no processes have started using the hugepages. Eg. when a pod requesting with is assigned to a node, k8s will then mark the s with huge page memory it as "used". The cgroup controller (if hugetlb cgroup is mounted) will then set the usage limit to . Before the pod actually starts using the huge page memory, the OS will report that no huge page memory is used. When a process inside the pod maps with huge page memory via eg. , the OS will see that the memory is in used. If the process tries to map more than the requested amount, the map will fail (given that the hugetlb cgroup is mounted). To verify if the hugetlb cgroup is mounted, run .

If mounted, it will retrun something like this:
I’m so sorry that there actually has a other pod using hugepagei only see node info available hugepage. so i close the issuethanks a lot
No problem I think this issue is a symptom that something should be done to make it easier to understand. I will look into it.
Change:
RestartPolicy: v1.RestartPolicyAlways, Containers: []v1.Container{ { <del> Name:    "busybox-container", Image:   busyboxImage, </del> <ins> Name:  "busybox-container", Image: busyboxImage, SecurityContext: &v1.SecurityContext{ Capabilities: &v1.Capabilities{ Add: []v1.Capability{"CAP_NET_RAW"}, }, }, </ins> Command: getRestartingContainerCommand("/test-empty-dir-mnt", 0, numRestarts, "echo 'some bytes' >/outside_the_volume.txt; ping -c 1 google.com; echo 'hello world' >> /test-empty-dir-mnt/file;"), Resources: v1.ResourceRequirements{ Limits: v1.ResourceList{

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: While trying to run the node conformance tests with CRIO, the test I noticed failures like on the logs of the test containers. This happens because CRIO doesn't ship with capability enabled by default. Since only this test in requires it, we should add this capability only in this test and not runtime wide. Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: CRIO doesn't ship with by default. Anything else we need to know:
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 node
Change:
<del> /* Copyright 2016 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package workqueue import ( "testing" "time" "k8s.io/client-go/pkg/api/v1" ) func TestNoMemoryLeak(t *testing.T) { timedQueue := NewTimedWorkQueue() timedQueue.Add(&TimedWorkQueueItem{Object: &v1.Pod{}, StartTime: time.Time{}}) item, _ := timedQueue.Get() timedQueue.Add(item) // The item should still be in the timedQueue. timedQueue.Done(item) item, _ = timedQueue.Get() timedQueue.Done(item) if len(timedQueue.Type.processing) != 0 { t.Errorf("expect timedQueue.Type.processing to be empty!") } } </del>

Discussion:
The TimedWorkQueue object appears to lack a critical feature of the original WorkOueue, namely that similar items are aggregated together. By adding the time member to to the key type, it ensures that (time, item) pairs are unique-- you can add the same item multiple times as long as the time differs. This removes the guarantee that two goroutines wouldn't process the same item at the same time.
Iirc, the timed queue feeds a regular queue, so the guarantee still holds
Sorry, I was thinking of the delaying queue, which does key correctly
I'm going to remove timed workqueue. It's used to gather metrics for queues used in the garbage collector. This feature is supported by a regular workqueue now.
Change:
if err != nil && !apierrors.IsConflict(err) && !apierrors.IsNotFound(err) { klog.V(3).Infof("Error deleting Secret: %v", err) } <ins> } else if ttl > 0 { tc.queue.AddAfter(o, ttl) </ins> } }

Discussion:
What happened: kube-controller-manager with enabled option --controllers=,tokencleaner is not removing newly created tokens. It works only after kube-controller-manager restart or after editing secret with token. What you expected to happen: It should remove all expired tokens from kube-system namespace, without restarting or touching secrets. How to reproduce it (as minimally and precisely as possible): enable tokencleaner in kube-controller-manager start controller manager create bootstrap token, you can use script wait 5 minutes token is still there restart kube-controller-manager OR edit newly created token token should be gone after a while Anything else we need to know?: It could be related with Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-12-03T20:56:12Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Do you see the following log ? thanks
no errors at all
/sig auth
Change:
} By("creating the pod") <del> pod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(pod) </del> <ins> var podClient *framework.PodClient podClient = f.PodClient() pod = podClient.Create(pod) </ins> By("waiting for pod running") <del> err = framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) </del> <ins> err := framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, framework.PodStartShortTimeout) </ins> Expect(err).NotTo(HaveOccurred(), "while waiting for pod to be running") By("creating a file in subpath")

Discussion:
Which jobs are failing: All new tests introduced for api change Which test(s) are failing: New alpha subpathExpr tests [Feature:VolumeSubpathEnvExpansion][NodeAlphaFeature:VolumeSubpathEnvExpansion] Existing tests are working fine and the whole suite works correctly in the gce suite https://k8s- Since when has it been failing: 21st February 2019 (since merge of PR) Testgrid link: https://k8s- Reason for failure: Investigation shows that node e2e tests use a different framework pod creation pattern Doing some comparisons of tests that work and those that don't reveals differences in the standard client set as and the existing ones which do work go through the intermediate which uses The version has an additional function specifically for node tests
/sig storage
/sig node /sig test
/assign
/cc
/sig test
Change:
$(warning ***** finding all +k8s:conversion-gen tags) endif CONVERSION_DIRS := $(shell                                 <del> grep '^// *+k8s:conversion-gen=' $(ALL_K8S_TAG_FILES)  </del> <ins> grep --color=never '^// *+k8s:conversion-gen=' $(ALL_K8S_TAG_FILES)  </ins> | cut -f1 -d:                                      | xargs -n1 dirname                                | sort -u                                         

Discussion:
Using the grep from OSX, fails when GREPOPTIONS/GREPCOLOR is set as shown below (). Workaround : unset GREPOPTIONS/GREPCOLOR Note that using GNU grep using brew install will show that GREPOPTIONS shows immediately that GREP_OPTIONS may be interfering with make ()
oh, here's badly manged conversion-
Will look, thanks. For make-related bugs, please @ me directly.
Will do. thanks
This breaks building kubernetes inside Alpine Linux:
I'm pressing more and more on the idea that the only supported build is the dockerized build. Trying to accomodate every random environment is just too taxing. , Marc Villacorta wrote:
I agree with We can support the stuff in to run on mac to get you dockerized but everything else is only supported in there. I've worked around a few BSD/OSX things in but it isn't fun. We should try to keep that stuff isolated.
I agree, with the usual caveat that we need to be doing all of the build in one container with as little as possible happening outside. OS X tends to have old and broken versions of important programs, which is terrible. We discussed setting up CI for it but it's not going to happen in the near term. Alpine/Busybox purposefully omit features from their versions for good reasons, but it's still more work to support than it's worth.
Ok, I will re-think my workflow.
How did you find yourself building in Alpine, in I may ask? , Marc Villacorta wrote:
nothing is forcing me to use Alpine I just like the distro. I run stuff on CoreOS and my aim is to solve the build-deliver-run pipeline with a single small container. By the way, I have the problem installing the GNU package :-)