jiebi/CodeConvo huggingface dataset:
Change:
package v1beta1 import ( <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" )

Discussion:
no explanation for metadata filed of NodeMetrics/PodMetrics, code: should be like $ kubectl explain NodeMetrics KIND: NodeMetrics VERSION: DESCRIPTION: NodeMetrics sets resource usage metrics of a node. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. usage <map[string]string-required- The memory usage is the memory working set. window <string-required- and $ kubectl explain PodMetrics KIND: PodMetrics VERSION: DESCRIPTION: PodMetrics sets resource usage metrics of a pod. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: containers <[]Object-required- Metrics for all containers are collected within the same time window. kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. window <string-required- able to see the explanation for metadata filed of NodeMetrics/PodMetrics Kubernetes Version: v1.22.0-rc.0+
/sig instrumentation
/kind documentation /assign /triage accepted
Change:
"//vendor/github.com/miekg/dns:go_default_library", "//vendor/github.com/onsi/ginkgo:go_default_library", "//vendor/github.com/onsi/gomega:go_default_library", <ins> "//vendor/github.com/pkg/errors:go_default_library", </ins> "//vendor/google.golang.org/api/compute/v1:go_default_library", "//vendor/k8s.io/utils/net:go_default_library", ],

Discussion:
What happened: The iperf tests were written a while ago but i think havent been updated. They measure bandwidth over multiple pods, but they probably should also have a test which reports individual pod's bandwidth between one pod over a SEP. They should pretty print a table so its easy to see exactly what is going on with the bandwidth They should use iperf3 (need to check that) Maybe we should have permutations for udp and tcp? The current output is something like: What you expected to happen: That running the tests would result in a table such as those that you can get from iperf3, i.e. How to reproduce it: run the e2es on any cluster, Environment: Kubernetes version (use ): master, any version
/sig network
/assign
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I've taken a first pass at this , working on resolving a couple issues then we can circle back to determine how else it could be improved!
Cool c/p the new test output so we can compare when u get a chance
ah yess. much better then what we have now.
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:
<del> 1.29 </del> <ins> 1.29-1 </ins>

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- [sig-windows] [Feature:Windows] GMSA Kubelet [Slow] kubelet GMSA support when creating a pod with correct GMSA credential specs passes the credential specs down to the Pod's containers [sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support works end to end ** pause image using in image was transitioned to the official pause image which no longer has in the image related to /sig windows /triage accepted
Change:
t.Fatalf("unexpected response: %v %t %#v", err, singular, test.Infos) } <del> info := test.Infos[1] if info.Name != "redis-master" || info.Namespace != "test" || info.Object == nil { </del> <ins> info := test.Infos[0] if _, ok := info.Object.(*api.ReplicationController); !ok || info.Name != "redis-master" || info.Namespace != "test" { t.Errorf("unexpected info: %#v", info) } info = test.Infos[1] if _, ok := info.Object.(*api.Pod); !ok || info.Name != "nginx" || info.Namespace != "test" { </ins> t.Errorf("unexpected info: %#v", info) } }

Discussion:
It works when I pipe but not with filename.
broke in this commit cc
Did you try to add an extension .json to the file? We filter for file extensions
ahhh ok. so working as intended. it used to autodetect :( ... thanks
That was unintended. The file extensions should only be used for deciding which files in a directory to process. For a single file, any extension should be allowed. We don't actually infer the content type from the extensions. For stdin and http sources, for instance, there are no extensions. cc
Fix is pretty straightforward (ignore file extensions when dealing with single file); I have it working with manual test, just adding unit test. Will send shortly.
Thanks, but this is v1.0-post, so no rush
Change:
path string } <ins> func NewFileStore(path string) (CheckpointStore, error) { if err := ensurePath(path); err != nil { return nil, err } return &FileStore{path: path}, nil } </ins> func (fstore *FileStore) Write(key string, data []byte) error { if err := validateKey(key); err != nil { return err } <del> if _, err := os.Stat(fstore.path); err != nil { // if directory already exists, proceed if err = os.MkdirAll(fstore.path, 0755); err != nil && !os.IsExist(err) { return err } </del> <ins> if err := ensurePath(fstore.path); err != nil { return err </ins> } tmpfile := filepath.Join(fstore.path, fmt.Sprintf("%s%s%s", tmpPrefix, key, tmpSuffix)) if err := ioutil.WriteFile(tmpfile, data, 0644); err != nil {

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: Using to start a cluster with only one node and found that there are some error logs in kubelet as following: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know:
cc
/cc
Seems caused by my env due to I cannot access gcr due to the proxy failed, will continue to check...
We should create the checkpoint directory when creating the checkpoint store, or else the list failed error will be quite spammy before a container is created.
Will push a fix soon.
Change:
cd easy-rsa-master/easyrsa3 ./easyrsa init-pki > /dev/null 2>&1 <del> ./easyrsa --batch build-ca nopass > /dev/null 2>&1 </del> <ins> ./easyrsa --batch "--req-cn=$cert_ip@`date +%s`" build-ca nopass > /dev/null 2>&1 </ins> if [ $use_cn = "true" ]; then ./easyrsa build-server-full $cert_ip nopass > /dev/null 2>&1 cp -p pki/issued/$cert_ip.crt "${cert_dir}/server.cert" > /dev/null 2>&1

Discussion:
When you generate your second cluster, suddenly you'll find that nothing works from browsers. The ca/cert pairs we make reuse serial numbers. Firefox says: Chrome just refuses to show anything, which made this hard to debug. We generate the ca & cert here: Action items: Every CA we make should be unique, even within the same (e.g.) GCE project/ip address. Every cert we make should have a unique serial number. easyrsa docs don't make it immediately obvious how to accomplish this.
running build-ca in --batch mode wipes out the existing pki, which restarts the indexing at 0 if the ca already exists, shouldn't we just skip build-ca?
I will happily merge a PR with that change! I only understand this stuff well enough to figure out what's wrong... ;)
Actually--if that is a/the problem, then running kube- should bork my cluster, no? But actually it does seem to work. So I suspect that the problem is deeper than that, like we generate the same ca deterministically (or some important component thereof) when kube- runs? Like all of the browsers on my desktop now completely refuse to talk to any kubernetes master because of this.
Ah, it looks like we end up with this in all certs: ... I think we want to add a arg to the call to uniquify the certificate authority each time it's generated
That sounds like it's probably the problem. Thanks!
fixes this.
Change:
CURRENT_VERSION=${step} echo "${CURRENT_VERSION}/${CURRENT_STORAGE}" > "${DATA_DIRECTORY}/${VERSION_FILE}" fi <del> if [ "$(echo ${CURRENT_VERSION} | cut -c1-2)" = "3." -a "${CURRENT_STORAGE}" = "etcd2" -a "${TARGET_STORAGE}" = "etcd3" ]; then </del> <ins> if [ "$(echo ${CURRENT_VERSION} | cut -c1-2)" = "3." -a "${CURRENT_VERSION}" = "${step}" -a "${CURRENT_STORAGE}" = "etcd2" -a "${TARGET_STORAGE}" = "etcd3" ]; then </ins> # If it is the first 3.x release in the list and we are migrating # also from 'etcd2' to 'etcd3', do the migration now. echo "Performing etcd2 -> etcd3 migration"

Discussion:
At the very least it should be clear when (timestamp) the migration started and finished.

If in line line is executed also for step 2.2.1 if the tool failed during first run of upgrade. I guess we should also check for the step and compare it to version.
Change:
local portable_tarball_name="${RELEASE_TARS}/kubernetes-test-portable.tar.gz" kube::release::create_tarball "${portable_tarball_name}" "${release_stage}/.." <del> if [[ "${KUBE_BUILD_MONDO_TEST_TARBALL}" =~ [yY] ]]; then kube::log::status "Building tarball: test mondo (deprecated by KEP sig-testing/20190118-breaking-apart-the-kubernetes-test-tarball)" local platform for platform in "${KUBE_TEST_PLATFORMS[@]}"; do local test_bins=("${KUBE_TEST_BINARIES[@]}") if [[ "${platform%/*}" == "windows" ]]; then test_bins=("${KUBE_TEST_BINARIES_WIN[@]}") fi mkdir -p "${release_stage}/platforms/${platform}" # This fancy expression will expand to prepend a path # (${LOCAL_OUTPUT_BINPATH}/${platform}/) to every item in the # test_bins array. cp "${test_bins[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/platforms/${platform}" done for platform in "${KUBE_TEST_SERVER_PLATFORMS[@]}"; do mkdir -p "${release_stage}/platforms/${platform}" # This fancy expression will expand to prepend a path # (${LOCAL_OUTPUT_BINPATH}/${platform}/) to every item in the # KUBE_TEST_SERVER_BINARIES array. cp "${KUBE_TEST_SERVER_BINARIES[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/platforms/${platform}" done cat <<EOF > "${release_stage}/DEPRECATION_NOTICE" The mondo test tarball containing binaries for all platforms is DEPRECATED as of Kubernetes 1.14. Users of this tarball should migrate to using the platform-specific tarballs in combination with the "portable" tarball which contains scripts, test images, and other manifests. For more details, please see KEP sig-testing/20190118-breaking-apart-the-kubernetes-test-tarball. EOF kube::release::clean_cruft local package_name="${RELEASE_TARS}/kubernetes-test.tar.gz" kube::release::create_tarball "${package_name}" "${release_stage}/.." fi </del> } # This is all the platform-independent stuff you need to run/install kubernetes.

Discussion:
What happened: On 2019-02-22 was merged with an indication that the mondo test tarball noted as deprecated as per But it did not include a timeline for eventual removal. What you expected to happen: It's been 7 months now. We should formalize a plan for removal. /sig testing /sig release /kind cleanup /priority important-soon
Enhancement tracking issue ref:
removes the deprecated mondo test tarball.
Change:
API rule violation: names_match,k8s.io/apimachinery/pkg/apis/meta/v1,MicroTime,Time API rule violation: names_match,k8s.io/apimachinery/pkg/apis/meta/v1,StatusCause,Type API rule violation: names_match,k8s.io/apimachinery/pkg/apis/meta/v1,Time,Time <del> API rule violation: names_match,k8s.io/apimachinery/pkg/runtime,RawExtension,Raw </del> API rule violation: names_match,k8s.io/apimachinery/pkg/runtime,Unknown,ContentEncoding API rule violation: names_match,k8s.io/apimachinery/pkg/runtime,Unknown,ContentType API rule violation: names_match,k8s.io/apimachinery/pkg/runtime,Unknown,Raw

Discussion:
The Service Catalog includes the type in . The openapi schema generated for it is wrong. It has two problems: it includes the field, which is marked as required it doesn't allow additional properties to be included under it Is this a BUG REPORT or FEATURE REQUEST?: BUG REPORT /kind bug What happened: If the Service Catalog openapi schema is exposed to kubectl (this currently requires a few tweaks and a patch), it reports validation errors when creating a ServiceInstance resource. What you expected to happen: The schema should allow to include arbitrary properties and not require the property to be included. How to reproduce it (as minimally and precisely as possible): not easy at the moment (I'll add instructions later if I'm unable to fix this myself) Anything else we need to know?: I'd like to tackle this problem myself, but I need guidance. Should openapi-gen handle this automatically for all occurences of RawExtension, or should each field of type be json-tagged individually? Environment: Kubernetes version (use ):
I've heard you're the goto guy for the openapi-gen. Please help? :)
/sig api-machinery
OK, I've found I can specify a custom schema for RawExtension the way it's done in Time and MicroTime. The remaining problem is how to specify that the RawExtension object can be of any type. Using is not supported currently - if I use it in the schema, the API server dies with:
/assign /cc
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
We've just hit this. /remove-lifecycle rotten /lifecycle frozen
hitting this
According to this: the raw extension can define its openapi type as: or alternatively what do you think?

do you still work on this or you want me to send a PR?
Would changing the definition of RawExtension to this help the situation? (adding ) I noticed that this removes Raw from the openapi defintion of it, without changing how it is marshalled or unmarshalled (since we have custom functions for that) I'll try making a PR for this
Change:
select { case <-c: return <del> case <-time.After(2 * time.Second): </del> <ins> case <-time.After(wait.ForeverTestTimeout): </ins> t.Fatalf("Timeout while waiting for the plugin registration status") } }

Discussion:
What happened: A race condition in the plugin watcher might happen when a is created, started and immediately stopped and cleaned up. If executed several times, the unit test will expose this issue. The PR addressed part of the problem by serializing the handling of CREATE and DELETE events. However, a race might still happen in the function. describes in detail the problem. How to reproduce it (as minimally and precisely as possible): /sig storage /sig node
/assign
Change:
# Use eval to preserve embedded quoted strings. local goflags goldflags gogcflags <del> eval "goflags=(${KUBE_GOFLAGS:-})" goldflags="${KUBE_GOLDFLAGS:-} $(kube::version::ldflags)" gogcflags="${KUBE_GOGCFLAGS:-}" </del> <ins> eval "goflags=(${GOFLAGS:-})" goldflags="${GOLDFLAGS:-} $(kube::version::ldflags)" gogcflags="${GOGCFLAGS:-}" </ins> local use_go_build local -a targets=()

Discussion:
We should just use GOFLAGS
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig contributor-experience
/assign
Change:
import ( "time" <ins> "k8s.io/apimachinery/pkg/api/errors" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" "k8s.io/apimachinery/pkg/runtime/schema"

Discussion:
Kubernetes version (use ): Kubernetes HEAD Environment: Cloud provider or hardware configuration: linux OS (e.g. from /etc/os-release): Kernel (e.g. ):NAME=Fedora25 What happened: apiserver panic What you expected to happen: No panic How to reproduce it (as minimally and precisely as possible): Testcase is going to be sent as a PR
Fixed by
Change:
updateExisting: true, verifyResult:   true, }, <del> { name:        "unexpected errors for create should be returned", errOnCreate: apierrors.NewUnauthorized(""), errExpected: true, }, { name:           "update existing show report error if unexpected error for update is returned", errOnUpdate:    apierrors.NewUnauthorized(""), updateExisting: true, errExpected:    true, }, </del> } for _, tt := range tests { t.Run(tt.name, func(t2 *testing.T) {

Discussion:
What happened: Running fails consistently with timeout errors What you expected to happen: Unit tests should complete without any errors. If this was a configuration problem (e.g. unsupported go version), then I should see a meaningful error rather than just a timeout error. How to reproduce it (as minimally and precisely as possible): Run Anything else we need to know?: This issue has been present in my system for months. Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: OS (e.g: ): Ubuntu 20.04 LTS (Focal Fossa) Kernel (e.g. ): Linux desktop 5.4.0-37-generic -Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others: go version go1.13.12 linux/amd64 (snap)
/sig testing
/assign
Issues targeted at the specific problematic packages and responsible SIGs will be more effective in getting this addressed
/remove-sig testing Unless we expect some broad testing change (like reconfiguring go test) this isn't SIG testing. This is SIG storage, node, and cluster lifecycle
/sig node /sig cluster-lifecycle /sig storage tagged the right sigs, though per-package issues are far more likely to drive getting this fixed
fix for cmd/kubeadm/app/phases/uploadconfig:
I'm going to open two more issues for the other two packages and work on them
sounds good, in that case please close this one.
New issues for reconciler and csi packages: ,
Closing. This problem has come up in the past, the solution is to just increase the timeout. I missed this the first time I read the doc.
Change:
}, }, } <del> pod = e2epod.NewPodClient(f).CreateSync(pod) </del> <ins> logRotationPod = e2epod.NewPodClient(f).CreateSync(pod) ginkgo.DeferCleanup(e2epod.NewPodClient(f).DeleteSync, logRotationPod.Name, metav1.DeleteOptions{}, time.Minute) }) ginkgo.It("should be rotated and limited to a fixed amount of files", func(ctx context.Context) { </ins> ginkgo.By("get container log path") <del> framework.ExpectEqual(len(pod.Status.ContainerStatuses), 1) id := kubecontainer.ParseContainerID(pod.Status.ContainerStatuses[0].ContainerID).ID </del> <ins> framework.ExpectEqual(len(logRotationPod.Status.ContainerStatuses), 1, "log rotation pod should have one container") id := kubecontainer.ParseContainerID(logRotationPod.Status.ContainerStatuses[0].ContainerID).ID </ins> r, _, err := getCRIClient() <del> framework.ExpectNoError(err) </del> <ins> framework.ExpectNoError(err, "should connect to CRI and obtain runtime service clients and image service client") </ins> resp, err := r.ContainerStatus(context.Background(), id, false) framework.ExpectNoError(err) logPath := resp.GetStatus().GetLogPath()

Discussion:
Device Plugin [Feature:DevicePluginProbe][NodeFeature:DevicePluginProbe][Serial] DevicePlugin [Serial] [Disruptive] Can schedule a pod that requires a device It appears a bit flaky on testgrid, but more recently been failing more often No response example - No response /sig node
/cc
/triage accepted /assign /priority important-soon
I ran this test locally 15 times back to back and did not run into this failure. The test passed locally. I suspect this to be a case where pod cleanup is not happening properly. In this test, we are relying on the number of PodResources and based on the error it looks like we have an addtional pod running other than the two expected pods (device plugin pod and test pod requesting device) but can't be 100% sure because we don't have enough logs to support that claim. Going to add more logs to expose output obtained from the podresource API endpoint.