jiebi/CodeConvo huggingface dataset:
Change:
func TestPersistentVolumeRecycler(t *testing.T) { _, s := framework.RunAMaster(t) <del> defer s.Close() </del> <ins> // TODO: Uncomment when fix #19254 // defer s.Close() </ins> deleteAllEtcdKeys() // Use higher QPS and Burst, there is a test for race condition below, which

Discussion:
http://pr- is another failure.
Also seen in http://pr-
Again. Not assigned to anyone, so I am sending to for routing
Again: Is there anyone working on this? I will spend some time looking into this.
I think that the name of this issue is misleading - the issue seems to be unrelated to etcd_watcher Basically, if you look into this part of log: So it seems that, the WaitGroup that is problematic is in httptest.Server. So my feeling is that we are simply talking to a server that is already being close and this is ~roughly duplicate of We should just find where exactly the problem is and try to work-around it.
I think this is exactly what we had before. I will send a PR with the fix today.
Change:
image:    "foo.azurecr.us/bar/image:version", expected: "foo.azurecr.us", }, <ins> { image:    "foo.azurecr.my.cloud/bar/image:version", expected: "foo.azurecr.my.cloud", }, </ins> } for _, test := range tests { <del> if loginServer := parseACRLoginServerFromImage(test.image); loginServer != test.expected { </del> <ins> if loginServer := provider.parseACRLoginServerFromImage(test.image); loginServer != test.expected { </ins> t.Errorf("function parseACRLoginServerFromImage returns "%s" for image %s, expected "%s"", loginServer, test.image, test.expected) } }

Discussion:
What happened: An aks-engine cluster with a user assigned managed service cluster identity fails to authenticate to azure container registries in private clouds when the proper (acrpull) azure role assignments are in place and when there are no image pull secrets. What you expected to happen: The cluster should be able to authenticate and pull from an ACR hosted in the same azure cloud without needing additional pull secrets when the cluster identity has the proper acrpull azure role assignment, no matter which azure cloud it is operating in. How to reproduce it (as minimally and precisely as possible): Assume you have a private azure cloud where every url ends with "". That would mean the ACR suffix would be . Let's pretend you have an ACR at and you try to deploy a pod in your cluster referencing the image . This will fail to pull when you have no image pull secrets. Anything else we need to know?: The problem stems from the following lines where expected ACR suffix domains are hardcoded: Environment: Kubernetes version (use ): 1.16.9 Cloud provider or hardware configuration: Azure private OS: ubuntu 16.0.4 Network plugin and version: Azure CNI
/sig provider-azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig provider-azure 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
/area provider/azure /sig cloud-provider
It looks like we may be able to obtain the acr suffix from the azure environment:
there is a security issue here: if we support self defined ACR domain, e.g. , then service principal secret could be sent to that remote server. The reason why we use hardcoded domains is that we could always make sure the following 4 domains are owned by Azure:
Change:
// headersForConfig extracts any http client logic necessary for the provided // config. <del> func headersForConfig(c *restclient.Config) (http.Header, error) { </del> <ins> func headersForConfig(c *restclient.Config, url *url.URL) (http.Header, error) { </ins> extract := &extractRT{} rt, err := restclient.HTTPWrappersForConfig(c, extract) if err != nil { return nil, err } <del> if _, err := rt.RoundTrip(&http.Request{}); err != nil { </del> <ins> if _, err := rt.RoundTrip(&http.Request{URL: url}); err != nil { </ins> return nil, err } return extract.Header, 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!--What happened: When I did e2e conformance test with log level 5, it completely passed! When I did e2e conformance test with log level 8, it just failed. The only thing I did is just leveling up from log level 5 to 8. But, I've got this error message. What you expected to happen: test would be completely passed and just get more verbose log Environment: local cluster <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig testing
Nice report. I confirmed this issue happens on my local environment also like:
Change:
framework.Skipf("Environment does not support getting controller-manager metrics - skipping") } <ins> ginkgo.By("Getting plugin name") defaultClass, err := c.StorageV1().StorageClasses().Get(defaultScName, metav1.GetOptions{}) framework.ExpectNoError(err, "Error getting default storageclass: %v", err) pluginName := defaultClass.Provisioner </ins> controllerMetrics, err := metricsGrabber.GrabFromControllerManager() framework.ExpectNoError(err, "Error getting c-m metrics : %v", err) <del> storageOpMetrics := getControllerStorageMetrics(controllerMetrics) </del> <ins> storageOpMetrics := getControllerStorageMetrics(controllerMetrics, pluginName) </ins> pvc, err = c.CoreV1().PersistentVolumeClaims(pvc.Namespace).Create(pvc) framework.ExpectNoError(err)

Discussion:
Which jobs are flaking: () () Which test(s) are flaking: Reason for failure: Timeout: Anything else we need to know: This test flaking about 10% of the time in this job. /sig storage /kind flake /priority important-soon cc
/remove-kind failing-test
/assign
I noticed one issue with the test is that it's not filtering metrics by plugin name. So it will just count the last plugin's metric. I'm not sure if the metrics collected are in any sorted order or not. If not, then when you have a suite that runs multiple plugins, then you might be pulling from the wrong metric.
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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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
/reopen
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
/remove-lifecycle rotten
still very prevalent in sig-release dashboards
I have pushed which should hopefully fix this.
Also PR against 1.17 branch -
Change:
plugin.host = host plugin.syncNetworkConfig() <ins> // start a goroutine to sync network config from confDir periodically to detect network config updates in every 5 seconds go wait.Forever(plugin.syncNetworkConfig, defaultSyncConfigPeriod) </ins> return nil }

Discussion:
What happened: When Node's iops is full, the Node status becomes to be NotReady. The NotReady message is "Container runtime is not ready". After our troubleshoot, we found func in cni package costs more then 30s, then the runtime status health check is failed : What you expected to happen: Node should still be in Ready status when iops is full. Because the CNI config files does not change. How to reproduce it (as minimally and precisely as possible): Run an application to fill disk IO bandwidth, then the Node becomes to be NotReady. Anything else we need to know?: Nothing yet. Environment: Runtime is dockershim. Other environment is no need to pay attention.
/assign /sig-node
/sig node /sig network
Change:
return acc.GetResourceVersion(), nil } <ins> func TestNoopChangeCreationTime(t *testing.T) { client, closeFn := setup(t) defer closeFn() ssBytes := []byte(`{ "apiVersion": "v1", "kind": "ConfigMap", "metadata": { "name": "myconfig", "creationTimestamp": null, "resourceVersion": null }, "data": { "key": "value" } }`) obj, err := client.CoreV1().RESTClient().Patch(types.ApplyPatchType). Namespace("default"). Param("fieldManager", "apply_test"). Resource("configmaps"). Name("myconfig"). Body(ssBytes). Do(context.TODO()). Get() if err != nil { t.Fatalf("Failed to create object: %v", err) } require.NoError(t, err) // Sleep for one second to make sure that the times of each update operation is different. time.Sleep(1200 * time.Millisecond) newObj, err := client.CoreV1().RESTClient().Patch(types.ApplyPatchType). Namespace("default"). Param("fieldManager", "apply_test"). Resource("configmaps"). Name("myconfig"). Body(ssBytes). Do(context.TODO()). Get() if err != nil { t.Fatalf("Failed to create object: %v", err) } require.NoError(t, err) require.Equal(t, obj, newObj) } </ins> // TestNoSemanticUpdateAppleSameResourceVersion makes sure that APPLY requests which makes no semantic changes // will not change the resource version (no write to etcd is done) //

Discussion:
Sending a patch built from a typed client to SSA will force a write to etcd (and bump resourceVersion) since creationTimestamp is serialized to null. This is a follow-up of which doesn't solve the issue properly. Sending a no-op SSA request with creationTimestamp to null shouldn't do anything Kubectl apply an object with creationTimestamp null twice and see that it updates the object. Probably something like this would cause it:
/sig api-machinery /wg api-expression /triage accepted /assign /priority important-soon
Change:
"sync" ) <del> // WellKnownRegions is the complete list of regions known to the AWS cloudprovider </del> <ins> // wellKnownRegions is the complete list of regions known to the AWS cloudprovider </ins> // and credentialprovider. <del> var WellKnownRegions = [...]string{ </del> <ins> var wellKnownRegions = [...]string{ </ins> // from `aws ec2 describe-regions --region us-east-1 --query Regions[].RegionName | sort` "ap-northeast-1", "ap-northeast-2",

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?: From /kind cleanup What happened: 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cloud-provider /assign
Change:
#   KUBE_MANIFESTS_TAR function find-release-tars() { SERVER_BINARY_TAR=$(find-tar kubernetes-server-linux-amd64.tar.gz) <ins> if [[ -z "${SERVER_BINARY_TAR}" ]]; then exit 1 fi </ins> if [[ "${NUM_WINDOWS_NODES}" -gt "0" ]]; then NODE_BINARY_TAR=$(find-tar kubernetes-node-windows-amd64.tar.gz) fi

Discussion:
What happened: If doesn't exist in $KUBEROOT/output/release-tars, the script doesn't prompt for downloading from external release URL, but just move on util an error is thrown instead. What you expected to happen: If the tarball does not exist, it should be able to download from external release URL. How to reproduce it (as minimally and precisely as possible): remove the tarball from $KUBEROOT/output/release-tars run Anything else we need to know?: The script has everything there, but there is a minor issue has caused the script move on silently after the close the child function. Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): all Install tools: Network plugin and version (if this is a network-related bug): Others:
/assign
tagging with the appropriate sigs, but please mind that kube-up is deprecated and should not be used in the wild. please move to a different tool for cluster creation, like kubeadm, kops, minikube, kind, cluster-api etc. /sig cluster-lifecycle testing
Change:
return err } e2elog.Logf("HugePages_Total is set to %v", numHugePages) <del> if numHugePages == 50 { </del> <ins> if numHugePages == 5 { </ins> return nil } <del> return fmt.Errorf("expected hugepages %v, but found %v", 50, numHugePages) </del> <ins> return fmt.Errorf("expected hugepages %v, but found %v", 5, numHugePages) </ins> } // releaseHugePages releases all pre-allocated hugepages

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: -tests Since when has it been failing: Unsure Testgrid link: Reason for failure: Unable to pre allocate 50x2MiB huge pages, probably due to memory pressure caused by kernel level caching. If requesting an substantial amount of huge page memory (like the tests), it is recommended to to it as early after boot as possible, or by using the kernel cmd line. Eg. this one: Anything else we need to know: will fix this issue, but in awaiting for that, we can just decrease the page count in the tests.
/sig node /cc derekwaynecarr
I think the reason of railure should be because a single hugepage of x86 is 2MiB as and a single page is 4KiB, not 2KiB.
Yes, is correct. Thanks for catching the typo :smile:
Looks like we still have some flakes in the huge page test, even tho the test now only requests of huge page memory. Happens way less frequently than previously tho. This is probably because the kernel is caching a lot of stuff, making it hard for the kernel to fix it. Ill do some testing with dropping the caches (no user facing stuff will happen, only kernel level) before trying to pre allocate huge pages. /reopen
Reopened this issue. <detailsIn response to : Looks like we still have some flakes in the huge page test, even tho the test now only requests of huge page memory. Happens way less frequently than previously tho. 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
/close
Closing this issue. <detailsIn response to : /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:
<ins> # Copyright 2017 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. FROM BASEIMAGE # The samba-common, cifs-utils, and nfs-common packages depend on # ucf, which itself depends on /bin/bash existing. # It doesn't seem to actually need bash, however. RUN ln -s /bin/sh /bin/bash RUN echo CACHEBUST>/dev/null && clean-install  iptables  ebtables  ethtool  ca-certificates  conntrack  util-linux  socat  git  jq  nfs-common  glusterfs-client  cifs-utils  ceph-common COPY cni-bin/bin /opt/cni/bin </ins>

Discussion:
I'm pretty sure that building the hyperkube images takes longer than building kubernetes itself now. At least a large part of this seems to be that we download and install ~172 extra debian packages several times (once for each arch). <details</detailsNot sure how to improve this - maybe better caching? Do we actually want to install these extra packages? Should we use a better base image than ? cc
cc (not really sure who "owns" hyperkube, if anyone)
The hyperkube binary is one thing. I think the image ends up being big as we drag in so much stuff. I wasn't involved in creating the docker image so I can't comment. Ideally this thing would be slim and would have minimal external dependencies. Fixing this starts with mapping why we have each of those deps imported.
I actually have written a such patch in my local env, but I never uploaded. It removed the docker and docker-multinode-specific stuff and all the unused deps. Also, we will come one step closer once is in. Should I submit the patch so you can take a look at it?
sure!
This needs to be triaged as a release-blocker or not for 1.5
punting to v1.6.
The main problem here is that we're installing huge packages for supporting some volume types: git nfs-common glusterfs-client cifs-utils With containerized volume mounters we'll get rid of that.
When it comes to local rebuilding, should help here. As I've already noted in the PR, maybe we should make CACHEBUST=0 the default for all hack/dev- scripts. This would at least ease development and testing.
can this be closed? or moved to 1.7?
should this be in v1.7? is there an appropriate sig to own this?
cries nope, not v1.7. I'm still not sure who owns hyperkube.
Everyone and no one I suppose. Yeah, agree it's sad.
/sig release guess we're saying sig-release owns hyperkube under the general guise of "cutting bits" until/unless there is a better home for it
Yeah, hyperkube definitely belongs to sig-release as it hasn't been owned by a sig so far...
Change:
import ( "io/ioutil" "os" <ins> "os/user" </ins> "path/filepath" "strings" "testing"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT What happened: TestNsenterExistsFile test is failing during make test What you expected to happen: The test should have passed. How to reproduce it (as minimally and precisely as possible): git clone run make test Anything else we need to know?: Fail logs: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others:
/sig storage
If you run the test with root user, It will fail. I have make a fix:
thanks for the patch .. its working.
Change:
assert.Equal(t, machineInfo, &cadvisorapi.MachineInfo{ NumCores:       4, MemoryCapacity: 1.6e+10, <del> MachineID:      "somehostname"}) </del> <ins> MachineID:      "somehostname", SystemUUID:     "E6C8AC43-582B-3575-4E1F-6DA170888906"}) </ins> } func TestWinVersionInfo(t *testing.T) {

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: The windows kubelet does not set .status.nodeInfo.systemUUID on the node object. What you expected to happen: The windows kubelet sets the systemUUID from How to reproduce it (as minimally and precisely as possible): Start the windows kubelet and check for UUID: Anything else we need to know?: This will affect users running the out-of-tree vsphere CCM since that depends on the systemUUID, unlike the in-tree version. Also, looks like cAdvisor is the component responsible for providing the systemUUID so let me know if this issue needs to be moved to that repo. Environment: Kubernetes version (use ): Verified on 1.13.1 and 1.14 Cloud provider or hardware configuration: None OS (e.g: ): Windows Server 2019
/sig windows /sig vmware
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
/remove-lifecycle stale
Change:
<ins> # Copyright 2018 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. .PHONY: manifest-tool MANIFEST_TOOL_DIR := $(shell mktemp -d) export PATH := $(MANIFEST_TOOL_DIR):$(PATH) MANIFEST_TOOL_VERSION := v0.7.0 space := space += comma := , prefix_linux = $(addprefix linux/,$(strip $1)) join_platforms = $(subst $(space),$(comma),$(call prefix_linux,$(strip $1))) manifest-tool: curl -sSL https://github.com/estesp/manifest-tool/releases/download/$(MANIFEST_TOOL_VERSION)/manifest-tool-linux-amd64 > $(MANIFEST_TOOL_DIR)/manifest-tool chmod +x $(MANIFEST_TOOL_DIR)/manifest-tool </ins>

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 feature This issue if for tracking the work related to pushing manifest list for kubernetes images(infra and test) List of images for which manifest need to be created: - [x] kubernetes to use manifest pause image - [x] dns - - - - - [ ] dashboard [x] Manifest images for k8s release images -
/assign
/cc
/sig cluster-lifecycle
/sig testing
/area test-infra /sig release
/reopen
I'd add dashboard to this as well, based off the issue at
can you provide a status update on this issue? I'd really want this fully working in v1.10... :)
I've created one more PR for pushing manifest for few more images, reference - I'll try my best to push into v1.10 release
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 stale
/remove-lifecycle stale
/remove-lifecycle rotten
A problem related to manifests and was addressed here:
An update of this issue would be welcomed to track the status of all affected images, since I think at least some of the linked issues have progressed.
/sig testing
all the k8s core images are now fat manifest, hence closing this task. Will create a separate task for creating manifest for ecosystem images(e.g dashboard, metric-server etc...)
did you have a issue open tracking other images? I noticed today that kube-addon-manager (cluster/addons/addon-manager) is multi-arch but not using a manifest list yet.