jiebi/CodeConvo huggingface dataset:
Change:
sig-auth-serviceaccount-admission-controller-migration 3/9 /sig auth /assign
/triage accepted
last green run was on first red run was on delta: looks like did a fair amount of refactoring around the upgrade tests, possibly in
did the upgrade tests run successfully after that refactor?
looks like the coredns version naming change to be prefixed with v in
Sorry to make the done . It is similar to .
looks like it is still failing due to the refactoring
/assign

Discussion:
fi echo "== Fetching the latest installed CoreDNS version ==" <del> NEW_COREDNS_VERSION=$("${KUBE_ROOT}"/cluster/kubectl.sh -n kube-system get deployment coredns -o=jsonpath='{$.spec.template.spec.containers[:1].image}' | cut -d ":" -f 2) </del> <ins> NEW_COREDNS_VERSION=$("${KUBE_ROOT}"/cluster/kubectl.sh -n kube-system get deployment coredns -o=jsonpath='{$.spec.template.spec.containers[:1].image}' | sed -r 's/.+:v?(.+)/1/') </ins> case "$(uname -m)" in x86_64*)

} echo "Fetching the previously installed CoreDNS version" <del> CURRENT_COREDNS_VERSION=$("${KUBE_ROOT}/cluster/kubectl.sh" -n kube-system get deployment coredns -o=jsonpath='{$.spec.template.spec.containers[:1].image}' | cut -d ":" -f 2) </del> <ins> CURRENT_COREDNS_VERSION=$("${KUBE_ROOT}/cluster/kubectl.sh" -n kube-system get deployment coredns -o=jsonpath='{$.spec.template.spec.containers[:1].image}' | sed -r 's/.+:v?(.+)/1/') </ins> COREDNS_DEPLOY_RESOURCE_VERSION=$("${KUBE_ROOT}/cluster/kubectl.sh" -n kube-system get deployment coredns -o=jsonpath='{$.metadata.resourceVersion}') master_upgrade=true
Change:
<!-- 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 --When attempting to upgrade kubernetes using kubeadm upgrade apply, kubeadm fails to parse an etcd imagetag containing build metadata in the form of as a valid semver. An example upgrade produces an error similar to: Note this will occur even if the etcd version is unchanged. The +` character. This pattern is used to support custom kubernetes images, for instance kube-apiserver:v1.20.4+patch.0 will be converted to imagetag v1.20.4_patch.0 when running make quick-release-images. Add the following to kubeadm- Install kubernetes. Then upgrade kubernetes with kubeadm upgrade apply. I have tested a fix for this issue and will PR shortly. Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: kubeadm Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cluster-lifecycle
/area kubeadm
/triage accepted

Discussion:
"fmt" "os" "path/filepath" <ins> "strings" </ins> "time" "github.com/pkg/errors"

// or the kubeadm preferred one for the desired Kubernetes version var desiredEtcdVersion *version.Version if cfg.Etcd.Local.ImageTag != "" { <del> desiredEtcdVersion, err = version.ParseSemantic(cfg.Etcd.Local.ImageTag) </del> <ins> desiredEtcdVersion, err = version.ParseSemantic( convertImageTagMetadataToSemver(cfg.Etcd.Local.ImageTag)) </ins> if err != nil { return true, errors.Wrapf(err, "failed to parse tag %q as a semantic version", cfg.Etcd.Local.ImageTag) }

return "", err } <del> return image.TagFromImage(pod.Spec.Containers[0].Image), nil </del> <ins> return convertImageTagMetadataToSemver(image.TagFromImage(pod.Spec.Containers[0].Image)), nil } // convertImageTagMetadataToSemver converts imagetag in the format of semver_metadata to semver+metadata func convertImageTagMetadataToSemver(tag string) string { // Container registries do not support `+` characters in tag names. This prevents imagetags from // correctly representing semantic versions which use the plus symbol to delimit build metadata. // Kubernetes uses the convention of using an underscore in image registries to preserve // build metadata information in imagetags. return strings.Replace(tag, "_", "+", 1) </ins> }
Change:
When master opens up for , we need to add this back in: /sig node
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
note to self / 1.21 and 1.22 release notes team -- let's make sure the PR body on the original PR is copied over to the new PR. will think that the old release note and documentation has been covered in 1.21, but we will (I will update this comment with link) manually override it to not show up in 1.21 release notes.

Discussion:
// owner: @derekwaynecarr // alpha: v1.20 <ins> // beta: v1.22 </ins> // // Enables kubelet support to size memory backed volumes SizeMemoryBackedVolumes featuregate.Feature = "SizeMemoryBackedVolumes"

DisableAcceleratorUsageMetrics:                 {Default: true, PreRelease: featuregate.Beta}, HPAContainerMetrics:                            {Default: false, PreRelease: featuregate.Alpha}, RootCAConfigMap:                                {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.22 <del> SizeMemoryBackedVolumes:                        {Default: false, PreRelease: featuregate.Alpha}, </del> <ins> SizeMemoryBackedVolumes:                        {Default: true, PreRelease: featuregate.Beta}, </ins> ExecProbeTimeout:                               {Default: true, PreRelease: featuregate.GA}, // lock to default and remove after v1.22 based on KEP #1972 update KubeletCredentialProviders:                     {Default: false, PreRelease: featuregate.Alpha}, GracefulNodeShutdown:                           {Default: true, PreRelease: featuregate.Beta},
Change:
<!-- 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 --kube-proxy panics when a LoadBalancer service is created after a deployment it is associated with is created and the pods are fully running. kube-proxy does not panic. 1) Create 2 Windows nodes 2) Create a deployment, ensuring that the pods are scheduled on different nodes: 3) Wait for the pods to go into the state. kube-proxy will not crash if the pods are not fully deployed 4) Create a LoadBalancer service for the deployment 5) At this point kube-proxy should have crashed. If not, delete and recreate the LoadBalancer, this should trigger the panic. The kube-proxy exe was run as: Stdout/err shows: Full kube-proxy logs: Kubernetes version (use ): 1.20 Cloud provider or hardware configuration: AWS OS (e.g: ): Windows server 2019 Kernel (e.g. ): 10.0..1817 Install tools: OpenShift 4.7.3 Network plugin and version (if this is a network-related bug): Hybrid OVN Others:
/sig windows
are you aware of anything happening here?
I am taking a look at this.
/triage accepted

Discussion:
func (ep *endpointsInfo) Cleanup() { Log(ep, "Endpoint Cleanup", 3) <del> if ep.refCount != nil { </del> <ins> if !ep.GetIsLocal() && ep.refCount != nil { </ins> *ep.refCount-- // Remove the remote hns endpoint, if no service is referring it

} else { // We only share the refCounts for remote endpoints ep.refCount = proxier.endPointsRefCount.getRefCount(newHnsEndpoint.hnsID) <ins> *ep.refCount++ </ins> } ep.hnsID = newHnsEndpoint.hnsID <del> *ep.refCount++ </del> Log(ep, "Endpoint resource found", 3) }
Change:
When using a AWS EBS PV or on-line volume with a partition on a Nitro machine, the volume is available as NVMe device. Kubelet is not able to format & mount the partition: It seems to me that AWS EBS volume plugin does not support partitions at all. The partition is mounted. Using an in-line volume with this pod:
/sig storage /sig cloud-provider /area provider/aws
/triage accepted

Discussion:
) const ( <del> diskPartitionSuffix = "" checkSleepDuration  = time.Second </del> <ins> diskPartitionSuffix     = "" nvmeDiskPartitionSuffix = "p" checkSleepDuration      = time.Second </ins> ) // AWSDiskUtil provides operations for EBS volume.

if err != nil { klog.Warningf("error looking for nvme volume %q: %v", volumeID, err) } else if nvmePath != "" { <ins> if partition != "" { nvmePath = nvmePath + nvmeDiskPartitionSuffix + partition } </ins> devicePaths = append(devicePaths, nvmePath) } }
Change:
[x] test approval issue : [X] test pr : [x] two weeks soak end date : 7 June 2021 [x] test promotion pr : kubernetes/kubernetes According to this APIsnoop query, there are still some remaining ReplicaSet endpoints which are untested. Create a Daemonset List all DaemonSets DeleteCollection of DaemonSetss Varify the DaemonSets have been deleted Using an existing conformance test as a template for a which validates that two new endpoints are hit. example endpoint | useragent -------------------------------------------|
createAppsV1NamespacedDaemonSet | (linux/amd64) kubernetes/$Format -- [sig-apps] Daemon set [Serial] should list and delete a collection of DaemonSets deleteAppsV1CollectionNamespacedDaemonSet | (linux/amd64) kubernetes/$Format -- [sig-apps] Daemon set [Serial] should list and delete a collection of DaemonSets listAppsV1DaemonSetForAllNamespaces | (linux/amd64) kubernetes/$Format -- [sig-apps] Daemon set [Serial] should list and delete a collection of DaemonSets listAppsV1NamespacedDaemonSet | (linux/amd64) kubernetes/$Format -- [sig-apps] Daemon set [Serial] should list and delete a collection of DaemonSets readAppsV1NamespacedDaemonSet | (linux/amd64) kubernetes/$Format -- [sig-apps] Daemon set [Serial] should list and delete a collection of DaemonSets (5 rows) If a test with these calls gets merged, test coverage will go up by 2 points This test is also created with the goal of conformance promotion. /sig apps /sig testing /sig architecture /area conformance
/triage accepted For Release 1.22
/open
/reopen
Reopened this issue. <detailsIn response to : /reopen </details

Discussion:
and deletecollection. CronJob/status MUST support get, update and patch.' release: v1.21 file: test/e2e/apps/cronjob.go <ins> - testname: DaemonSet, list and delete a collection of DaemonSets codename: '[sig-apps] Daemon set [Serial] should list and delete a collection of DaemonSets [Conformance]' description: When a DaemonSet is created it MUST succeed. It MUST succeed when listing DaemonSets via a label selector. It MUST succeed when deleting the DaemonSet via deleteCollection. release: v1.22 file: test/e2e/apps/daemon_set.go </ins> - testname: DaemonSet-FailedPodCreation codename: '[sig-apps] Daemon set [Serial] should retry creating failed daemon pods [Conformance]'

checkDaemonSetPodsLabels(listDaemonPods(c, ns, label), hash) }) <del> ginkgo.It("should list and delete a collection of DaemonSets", func() { </del> <ins> /* Release: v1.22 Testname: DaemonSet, list and delete a collection of DaemonSets Description: When a DaemonSet is created it MUST succeed. It MUST succeed when listing DaemonSets via a label selector. It MUST succeed when deleting the DaemonSet via deleteCollection. */ framework.ConformanceIt("should list and delete a collection of DaemonSets", func() { </ins> label := map[string]string{daemonsetNameLabel: dsName} labelSelector := labels.SelectorFromSet(label).String()
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-integration-master I can't seem to find a match for beyond that? Most likely related to as it was merged during that set of commits Example Spyglass link: /cc /sig apps /priority critical-urgent /milestone v1.21
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
/assign
FYI: the error message is a red herring and isn't the real reason why this test is failing. When the integration tests are run with instead of , the mutation detector is also started, which catches a bug in the job controller where we modify the shared cache. This root cause isn't present in the logs, but you can reproduce this bug with the following command: Then apply the job controller patch in and re-run the test, you'll see that the test passes. You'll also notice that passes with/without the bug fix patch when run with . cc
Test is back on green. Thanks !

Discussion:
} return false, err } <del> job := *sharedJob </del> <ins> // make a copy so we don't mutate the shared cache job := *sharedJob.DeepCopy() </ins> // if job was finished previously, we don't want to redo the termination if IsJobFinished(&job) {

wantReason string } testCases := []struct { <del> short       bool </del> featureGate bool create      step update      step

// Exhaustively test all combinations other than trivial true->true and // false->false cases. { <del> short:       true, </del> featureGate: true, create:      step{flag: false, wantActive: 2}, update:      step{flag: true, wantActive: 0, wantStatus: v1.ConditionTrue, wantReason: "Suspended"},

for _, tc := range testCases { name := fmt.Sprintf("feature=%v,create=%v,update=%v", tc.featureGate, tc.create.flag, tc.update.flag) t.Run(name, func(t *testing.T) { <del> if testing.Short() && !tc.short { t.Skip("skipping expensive subtest") } </del> defer featuregatetesting.SetFeatureGateDuringTest(t, feature.DefaultFeatureGate, features.SuspendJob, tc.featureGate)() closeFn, restConfig, clientSet, ns := setup(t, "suspend")
Change:
<!-- 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 --I wanted to run an integration test and use the option of to pass parameters to the program being tested. I could not find a way to do so. I tried but this failed because those args were followed by in the actual program invocation (see for the reason). I expected there to be a way. I expected it to be documented. Kubernetes version (use ): current and many recent releases 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 testing
/priority important-soon /triage accepted
/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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale just needs a rebase and another poke at assigned reviewers
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten

Discussion:
make -C "${KUBE_ROOT}" test  WHAT="${WHAT:-$(kube::test::find_integration_test_dirs | paste -sd' ' -)}"  GOFLAGS="${GOFLAGS:-}"  <del> KUBE_TEST_ARGS="--alsologtostderr=true ${KUBE_TEST_ARGS:-} ${SHORT:--short=true} --vmodule=${KUBE_TEST_VMODULE}"  </del> <ins> KUBE_TEST_ARGS="--alsologtostderr=true ${SHORT:--short=true} --vmodule=${KUBE_TEST_VMODULE} ${KUBE_TEST_ARGS:-}"  </ins> KUBE_TIMEOUT="${KUBE_TIMEOUT}"  KUBE_RACE=""
Change:
From After , Multi-AZ Clusters tests in 1.19 and 1.20 started timing out as createBalancedPodForNodes is extremely inefficient in scale: for each node (out of 5k), it lists all pods in a cluster serially (each list takes ~5s), which translates to ~7 hours. Optimizing this function by listing pods once and then in memory by Spec.NodeName /kind bug /priority critical-urgent /sig scheduling
/triage accepted
/assign
/reopen Looks that ComputeCPUMemFraction took only 12 minutes, but it stuck later, on It is scheduling one pod per each node: Which is waiting 5s to be ready: 5k nodes * 5s = ~7h
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
/assign Can you do the pod creations in parallel?
Yes, good idea. I'll update to do that

Discussion:
"encoding/json" "fmt" "math" <ins> "sync" </ins> "time" "github.com/onsi/ginkgo"

"k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels" <ins> "k8s.io/apimachinery/pkg/util/errors" </ins> "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" clientset "k8s.io/client-go/kubernetes"

} } <ins> errChan := make(chan error, len(nodes)) var wg sync.WaitGroup </ins> // we need the max one to keep the same cpu/mem use rate ratio = math.Max(maxCPUFraction, maxMemFraction) for _, node := range nodes {

}, }, } <del> err := testutils.StartPods(cs, 1, ns, string(uuid.NewUUID()), *initPausePod(f, *podConfig), true, framework.Logf) </del> <ins> wg.Add(1) go func() { defer wg.Done() err := testutils.StartPods(cs, 1, ns, string(uuid.NewUUID()), *initPausePod(f, *podConfig), true, framework.Logf) if err != nil { errChan <- err } }() } wg.Wait() close(errChan) var errs []error for err := range errChan { </ins> if err != nil { <del> return cleanUp, err </del> <ins> errs = append(errs, err) </ins> } } <ins> if len(errs) > 0 { return cleanUp, errors.NewAggregate(errs) } </ins> nodeNameToPodList = podListForEachNode(cs) for _, node := range nodes {
Change:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Since March 25th 2021, mostly windows jobs but a few others: 22 ci-kubernetes-e2e-windows-gce-2004 25 ci-kubernetes-e2e-windows-gce-20h2 17 ci-kubernetes-e2e-windows-containerd-gce 12 ci-kubernetes-e2e-windows-gce-2019 10 ci-kubernetes-kind-conformance-parallel-ipv6 5 ci-kubernetes-kind-e2e-parallel 4 ci-kubernetes-e2e-gci-gce-alpha-enabled-default Kubernetes e2e suite.[sig-apps] ReplicaSet Replace and Patch tests [Conformance] links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig windows /sig apps /kind flake
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
it's started failing consistently in Windows Dockershim
looks like there were updates to this tests which may have caused issues for Windows: was merged on the 24th and we started seeing flakes the day after
a 30 second time out that is running waiting for the pods to come up. from The windows nodes are still pulling the image at the 30 second timeout. Test failes at 10.11.31: You can see the image is still being pulled.
the pod for was finished pulling but hadn't started:
same for
It is definitely a timing issue for Windows (due to slower pull times) and looks to be a timing issue even on linux though it happens fewer times. We could increase the time out... I noticed it doesn't look like we have a consistent timeout for pods starting across tests.
Another option would be to use the which has a longer timeout (5 min) and is used earlier in the tests. Once running check the values on the replica set
/milestone v1.21

Discussion:
_, err = f.ClientSet.AppsV1().ReplicaSets(ns).Patch(context.TODO(), rsName, types.StrategicMergePatchType, []byte(rsPatch), metav1.PatchOptions{}) framework.ExpectNoError(err, "failed to patch ReplicaSet") <del> ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) </del> <ins> ctx, cancel := context.WithTimeout(context.Background(), 5*time.Minute) </ins> defer cancel() _, err = watchtools.Until(ctx, rsList.ResourceVersion, w, func(event watch.Event) (bool, error) { if rset, ok := event.Object.(*appsv1.ReplicaSet); ok {