jiebi/CodeConvo huggingface dataset:
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 --What happened: When using Internal Standard LoadBalancer on Azure, although VMSS instances have been to LB backend address pools, the VMSS itself is not . Hence, if customer upgrades these VMSS instances to latest model, the backend address pool would be lost and hence the LoadBalancer services would be broken. What you expected to happen: Azure VMSS is also to internal SLB backend address pool automatically. 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig cloud-provider /kind bug /priority critical-urgent /area provider-azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : <!-- 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: 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: /kind bug /priority critical-urgent /area 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
Can you share some insights when this could be get fixed?

Discussion:
} func (ss *scaleSet) ensureVMSSInPool(service *v1.Service, nodes []*v1.Node, backendPoolID string, vmSetName string) error { <ins> klog.V(2).Infof("ensureVMSSInPool: ensuring VMSS with backendPoolID %s", backendPoolID) </ins> vmssNamesMap := make(map[string]bool) // the standard load balancer supports multiple vmss in its backend while the basic sku doesn't

continue } // in this scenario the vmSetName is an empty string and the name of vmss should be obtained from the provider IDs of nodes <del> vmssName, resourceGroupName, err := getVmssAndResourceGroupNameByVMProviderID(node.Spec.ProviderID) </del> <ins> resourceGroupName, vmssName, err := getVmssAndResourceGroupNameByVMProviderID(node.Spec.ProviderID) </ins> if err != nil { klog.V(4).Infof("ensureVMSSInPool: found VMAS node %s, will skip checking and continue", node.Name) continue

vmssNamesMap[vmSetName] = true } <ins> klog.V(2).Infof("ensureVMSSInPool begins to update VMSS %v with backendPoolID %s", vmssNamesMap, backendPoolID) </ins> for vmssName := range vmssNamesMap { vmss, err := ss.getVMSS(vmssName, azcache.CacheReadTypeDefault) if err != nil {
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 --Which jobs are flaking: pull-kubernetes-integration Which test(s) are flaking: runkubectlapplytests Testgrid link: Reason for failure: A test has a precondition that no pods should be up, but, previous test's deployment did not fully delete. As a result precondition check fails. Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig testing
Pasting the failed tests' output, for easy reference:
Found one more flake test, due to same reason. Checking for more.

Discussion:
# Pre-Condition: namepace does not exist and no POD exists output_message=$(! kubectl get namespace multi-resource-ns 2>&1 "${kube_flags[@]:?}") kube::test::if_has_string "${output_message}" 'namespaces "multi-resource-ns" not found' <del> kube::test::get_object_assert pods "{{range.items}}{{${id_field:?}}}:{{end}}" '' </del> <ins> kube::test::wait_object_assert pods "{{range.items}}{{${id_field:?}}}:{{end}}" '' </ins> # First pass, namespace is created, but pod is not (since namespace does not exist yet). output_message=$(! kubectl apply -f hack/testdata/multi-resource-1.yaml 2>&1 "${kube_flags[@]:?}") kube::test::if_has_string "${output_message}" 'namespaces "multi-resource-ns" not found'
Change:
Found in local testing. Looks like it's coming from:
/area conformance
/sig testing

Discussion:
"time" "github.com/davecgh/go-spew/spew" <ins> "github.com/pkg/errors" </ins> apps "k8s.io/api/apps/v1" "k8s.io/api/core/v1"

return fmt.Errorf("deployment %q failed to create new replica set", deploymentName) } if err != nil { <del> return fmt.Errorf("error waiting for deployment %q (got %s / %s) and new replica set %q (got %s / %s) revision and image to match expectation (expected %s / %s): %v", deploymentName, deployment.Annotations[deploymentutil.RevisionAnnotation], deployment.Spec.Template.Spec.Containers[0].Image, newRS.Name, newRS.Annotations[deploymentutil.RevisionAnnotation], newRS.Spec.Template.Spec.Containers[0].Image, revision, image, err) </del> <ins> if deployment == nil { return errors.Wrapf(err, "error creating new replica set for deployment %q ", deploymentName) } deploymentImage := "" if len(deployment.Spec.Template.Spec.Containers) > 0 { deploymentImage = deployment.Spec.Template.Spec.Containers[0].Image } newRSImage := "" if len(newRS.Spec.Template.Spec.Containers) > 0 { newRSImage = newRS.Spec.Template.Spec.Containers[0].Image } return fmt.Errorf("error waiting for deployment %q (got %s / %s) and new replica set %q (got %s / %s) revision and image to match expectation (expected %s / %s): %v", deploymentName, deployment.Annotations[deploymentutil.RevisionAnnotation], deploymentImage, newRS.Name, newRS.Annotations[deploymentutil.RevisionAnnotation], newRSImage, revision, image, err) </ins> } return nil }
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Comment on the scope of --etcd-servers-overrides option in the generated documentation Why is this needed: The documentation does not say if the --etcd-servers-overrides option for kube-apiserver does support CRDs.
/sig docs
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
/lifecycle frozen
The doc could be clarified, but the following suggest the answer is no support for CRs unless recently:
Yes, indeed I think it should be at least clarified in the docs.

Discussion:
fs.StringSliceVar(&s.EtcdServersOverrides, "etcd-servers-overrides", s.EtcdServersOverrides, ""+ "Per-resource etcd servers overrides, comma separated. The individual override "+ <del> "format: group/resource#servers, where servers are URLs, semicolon separated.") </del> <ins> "format: group/resource#servers, where servers are URLs, semicolon separated. "+ "Note that this applies only to resources compiled into this server binary. ") </ins> fs.StringVar(&s.DefaultStorageMediaType, "storage-media-type", s.DefaultStorageMediaType, ""+ "The media type to use to store objects in storage. "+
Change:
The docs for the Watch interface are a little ambiguous: "If an error occurs or Stop() is called, this channel will be closed, in which case the watch should be completely cleaned up." That can be read two ways: When the channel is closed, the watch is already completely cleaned up When the channel is closed, the caller must call Stop() to clean up resources. If it's the first, can I suggest we rephrase to "If an error occurs or Stop() is called, this channel will be closed. It is not required to call Stop() to free resources when the channel has been closed." If it's the second, can I suggest we rephrase to "If an error occurs or Stop() is called, this channel will be closed. On observing the closed channel, the caller must call Stop() to free resources." /sig apimachinery
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : The docs for the Watch interface are a little ambiguous: </details
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : The docs for the Watch interface are a little ambiguous: </details
/assign Mike would you be interested in taking a look?
OK, I will take a look.

Discussion:
Stop() // Returns a chan which will receive all the events. If an error occurs <del> // or Stop() is called, this channel will be closed, in which case the // watch should be completely cleaned up. </del> <ins> // or Stop() is called, the implementation will close this channel and // release any resources used by the watch. </ins> ResultChan() <-chan Event }
Change:
Currently, (best-effort) watch bookmarks are sent just right before the given watch is supposed to timeout: In we're adjusting how the size of watch cache is determined and make it dynamic and more duration-oriented (rather than based on some magic constants) - we're targeting to always keep 5 minutes of history in watch cache. With that change, we should get back to our bookmark policy: change it to (additionally to right before timeout) also send bookmarks every N seconds (setting N to slightly less than expected watch cache history period, so slightly less than X minutes we will use there) scale-test this change (to see if it doesn't introduce non-negligible overhead) if so permanently introduce this change /sig scalability api-machinery
/cc
/cc
/cc
I'm reverting as it broke bookmarks. I'm going to fix and re-submit for review hopefully later this week.

Discussion:
// adds a watcher to the bucket, if the deadline is before the start, it will be // added to the first one. func (t *watcherBookmarkTimeBuckets) addWatcher(w *cacheWatcher) bool { <del> nextTime, ok := w.nextBookmarkTime(t.clock.Now()) if !ok { return false } </del> <ins> nextTime := w.nextBookmarkTime(t.clock.Now()) </ins> bucketID := nextTime.Unix() t.lock.Lock() defer t.lock.Unlock()

} } <del> func (c *cacheWatcher) nextBookmarkTime(now time.Time) (time.Time, bool) { // For now we return 2s before deadline (and maybe +infinity is now already passed this time) // but it gives us extensibility for the future(false when deadline is not set). </del> <ins> // bookmarkHeartbeatFrequency defines how frequently bookmarks should be // under regular conditions. const bookmarkHeartbeatFrequency = time.Minute func (c *cacheWatcher) nextBookmarkTime(now time.Time) time.Time { // We try to send bookmarks: // (a) roughly every minute // (b) right before the watcher timeout - for now we simply set it 2s before //     the deadline // The former gives us periodicity if the watch breaks due to unexpected // conditions, the later ensures that on timeout the watcher is as close to // now as possible - this covers 99% of cases. heartbeatTime := now.Add(bookmarkHeartbeatFrequency) </ins> if c.deadline.IsZero() { <del> return c.deadline, false </del> <ins> return heartbeatTime } if pretimeoutTime := c.deadline.Add(-2 * time.Second); pretimeoutTime.Before(heartbeatTime) { return pretimeoutTime </ins> } <del> return c.deadline.Add(-2 * time.Second), true </del> <ins> return heartbeatTime </ins> } func getEventObject(object runtime.Object) runtime.Object {
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 --Which jobs are flaking: Which test(s) are flaking: CSI mock volume storage capacity exhausted, late binding, with topology Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/assign
According to , there really are extra calls to and that shouldn't be there: The current theory is that this might be related to kubelet assuming that a CSI driver does real mounts, something that the mock driver (and potentially other) CSI drivers don't do. A fix for that is pending in That this test runs into this randomly is caused by the test doing more strict checking of CSI calls than other tests. The flaky test failures could be avoided by relaxing that checking, but that won't fix the underlying issue.
I'm not sure I would pin it on the mount check yet. The broader question is why is MountVolume() getting called twice after the first one returns success.
is it due that, the timeout of CSI transaction or call is very low where CSI driver takes more time than this timeout?

Discussion:
createVolume := "CreateVolume" deleteVolume := "DeleteVolume" <del> publishVolume := "NodePublishVolume" </del> <ins> // publishVolume := "NodePublishVolume" </ins> unpublishVolume := "NodeUnpublishVolume" <del> stageVolume := "NodeStageVolume" </del> <ins> // stageVolume := "NodeStageVolume" </ins> unstageVolume := "NodeUnstageVolume" // These calls are assumed to occur in this order for <del> // each test run. </del> <ins> // each test run. NodeStageVolume and // NodePublishVolume should also be deterministic and // only get called once, but sometimes kubelet calls // both multiple times, which breaks this test // (https://github.com/kubernetes/kubernetes/issues/90250). // Therefore they are temporarily commented out until // that issue is resolved. </ins> deterministicCalls := []string{ createVolume, <del> stageVolume, publishVolume, </del> <ins> // stageVolume, // publishVolume, </ins> unpublishVolume, unstageVolume, deleteVolume,

lateBinding:    test.lateBinding, enableTopology: test.topology, <del> // Not strictly necessary, but without it, the external-attacher takes two minutes to detach // the volume?! Looks like a bug. </del> <ins> // Not strictly necessary, but runs a bit faster this way // and for a while there also was a problem with a two minuted delay // due to a bug (https://github.com/kubernetes-csi/csi-test/pull/250). </ins> disableAttach:  true, registerDriver: true, }
Change:
With the feature gate disabled, kube-controller-manager accepts a argument, but with enabled, it only accepts and and rejects . This blocks moving dual-stack to beta, since switching the feature gate to on-by-default would break existing single-stack clusters using . /cc /sig network /priority important-soon
let me tag too, IIRC he implemented it and may be is more familiar with this
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved

Discussion:
} var nodeCIDRMaskSizeIPv4, nodeCIDRMaskSizeIPv6 int <del> if utilfeature.DefaultFeatureGate.Enabled(features.IPv6DualStack) { </del> <ins> if dualStack { </ins> // only --node-cidr-mask-size-ipv4 and --node-cidr-mask-size-ipv6 supported with dual stack clusters. // --node-cidr-mask-size flag is incompatible with dual stack clusters. nodeCIDRMaskSizeIPv4, nodeCIDRMaskSizeIPv6, err = setNodeCIDRMaskSizesDualStack(ctx.ComponentConfig.NodeIPAMController) } else { // only --node-cidr-mask-size supported with single stack clusters. <del> // --node-cidr-mask-size-ipv4 and --node-cidr-mask-size-ipv6 flags are incompatible with dual stack clusters. </del> <ins> // --node-cidr-mask-size-ipv4 and --node-cidr-mask-size-ipv6 flags are incompatible with single stack clusters. </ins> nodeCIDRMaskSizeIPv4, nodeCIDRMaskSizeIPv6, err = setNodeCIDRMaskSizes(ctx.ComponentConfig.NodeIPAMController) }
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: https://k8s- Reason for failure: Anything else we need to know: /cc /milestone v1.19 /priority important-soon /sig network
Ref:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
my fu points me to this commit [] Fix multiple conversion tests that belongs to this PR , that seems related can you confirm if that PR is causing this test to fail? (should we gate on this test?)
Yes, that PR is related to the failure. The test utility is trying to convert extensions/v1beta1 data read from various files directly to a go type. This was never a valid thing to do, and happened to silently succeed because the two structs had an identical structure. This is exactly the type of bug was designed to flush out
the correct fix is to update the test/e2e/testing- files to
/assign
It was my PR that broke this - I can also fix that.
Thanks, o it was the commit that was good but the test that was wrong :upsidedownface: , At least I got right the commit :sweat_smile:
is out for review (talked with offline, he was aware that I'll send that out)

Discussion:
<del> apiVersion: extensions/v1beta1 </del> <ins> apiVersion: networking.k8s.io/v1beta1 </ins> kind: Ingress metadata: name: echomap

<del> apiVersion: extensions/v1beta1 </del> <ins> apiVersion: networking.k8s.io/v1beta1 </ins> kind: Ingress metadata: name: multiple-certs

<del> apiVersion: extensions/v1beta1 </del> <ins> apiVersion: networking.k8s.io/v1beta1 </ins> kind: Ingress metadata: name: hostname spec: backend: serviceName: hostname <del> servicePort: 80 </del>  No newline at end of file <ins> servicePort: 80 </ins>

<del> apiVersion: extensions/v1beta1 </del> <ins> apiVersion: networking.k8s.io/v1beta1 </ins> kind: Ingress metadata: name: pre-shared-cert

<del> apiVersion: extensions/v1beta1 </del> <ins> apiVersion: networking.k8s.io/v1beta1 </ins> kind: Ingress metadata: name: static-ip
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 --Cert path was generated with wrong slashes What happened: Paths generated with path and not filepath do not work always work on windows. will in general work, however volume guid paths will not This issue is related to rancher/k3s
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

Discussion:
"io/ioutil" "math/big" "net" <del> "path" </del> <ins> "path/filepath" </ins> "strings" "time"

maxAge := time.Hour * 24 * 365          // one year self-signed certs baseName := fmt.Sprintf("%s_%s_%s", host, strings.Join(ipsToStrings(alternateIPs), "-"), strings.Join(alternateDNS, "-")) <del> certFixturePath := path.Join(fixtureDirectory, baseName+".crt") keyFixturePath := path.Join(fixtureDirectory, baseName+".key") </del> <ins> certFixturePath := filepath.Join(fixtureDirectory, baseName+".crt") keyFixturePath := filepath.Join(fixtureDirectory, baseName+".key") </ins> if len(fixtureDirectory) > 0 { cert, err := ioutil.ReadFile(certFixturePath) if err == nil {
Change:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /cc /milestone v1.19 /priority critical-urgent /sig testing
You must be a member of the GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your and have them propose you as an additional delegate for this responsibility. <detailsIn response to : Which jobs are failing: Up W0501 09:18:22.072] scp: /var/log/konnectivity- No such file or directory W0501 09:18:22.072] scp: No such file or directory W0501 09:18:22.072] scp: No such file or directory W0501 09:18:22.073] scp: *: No such file or directory W0501 09:18:22.075] ERROR: () [/usr/bin/scp] exited with return code [1]. /milestone v1.19 /priority critical-urgent /sig testing 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
/milestone v1.19
/assign

Discussion:
software-properties-common  lsb-release <ins> # focal repo for docker is not yet available, so we use bonic for now # https://github.com/kubernetes/kubernetes/issues/90709 release=$(lsb_release -cs) if [ "$release" == "focal" ]; then release="bionic"; fi </ins> # Add the Docker apt-repository curl -fsSL https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")/gpg  | apt-key add - add-apt-repository  "deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")  <del> $(lsb_release -cs) stable" </del> <ins> $release stable" </ins> # Install Docker apt-get update && 

software-properties-common  lsb-release <ins> # focal repo for docker is not yet available, so we use bonic for now # https://github.com/kubernetes/kubernetes/issues/90709 release=$(lsb_release -cs) if [ "$release" == "focal" ]; then release="bionic"; fi </ins> # Add the Docker apt-repository (as we install containerd from there) curl -fsSL https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")/gpg  | apt-key add - add-apt-repository  "deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")  <del> $(lsb_release -cs) stable" </del> <ins> $release stable" </ins> # Install containerd from Docker repo apt-get update &&