jiebi/CodeConvo huggingface dataset:
Change:
for _, sample := range samples { count := int64(sample.Value) operation := string(sample.Metric["operation_name"]) <ins> metricPluginName := string(sample.Metric["volume_plugin"]) if len(pluginName) > 0 && pluginName != metricPluginName { continue } </ins> result.latencyMetrics[operation] = count } case "storage_operation_status_count":

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:
{UpdatePodFailure, simpleSetFn}, {UpdateSetStatusFailure, simpleSetFn}, {PodRecreateDeleteFailure, simpleSetFn}, <ins> {NewRevisionDeletePodFailure, simpleSetFn}, </ins> } for _, testCase := range testCases {

Discussion:
It was found during a review that stateful set status might not be correctly updated when new revision is being rolled out and API error occurs when deleting a pod. The status should be updated correctly Not easy to reproduce, but should be possible with this unit test No response_ <details</details<details</details<details</details<details</details<details</details<details</details
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 apps
Change:
github.com/xlab/handysort => github.com/xlab/handysort v0.0.0-20150421192137-fb3537ed64a1 github.com/xordataexchange/crypt => github.com/xordataexchange/crypt v0.0.3-0.20170626215501-b2862e3d0a77 go.etcd.io/bbolt => go.etcd.io/bbolt v1.3.3 <del> go.etcd.io/etcd => go.etcd.io/etcd v0.0.0-20191023171146-3cf2f69b5738 </del> <ins> go.etcd.io/etcd => go.etcd.io/etcd v0.0.0-20191023171146-3cf2f69b5738 // 3cf2f69b5738 is the SHA for git tag v3.4.3 </ins> go.mongodb.org/mongo-driver => go.mongodb.org/mongo-driver v1.1.2 go.opencensus.io => go.opencensus.io v0.21.0 go.uber.org/atomic => go.uber.org/atomic v1.3.2

Discussion:
What would you like to be : From looking at our gomod deps we seem to have drifted out of date again and we should update - Why is this needed: Bug fixes, feature adds, validation. /cc
Also cc:
we currently use which is the same as go does not allow referring to a module using a v2+ semver tag unless the module name ends with
opened to add an explanatory comment in our file, which is the best we can do until etcd renames its module to follow semantic import versioning, which requires changing every package import reference
what about v3.3.10+incompatible && the other older etcd deps?
not vendored/linked/used (can verify no code from that dependency is even present in ), just in our graph, so included in replace / directives
uhhh that's weird, we need to dump viper for component config, but no one wanted todo that work.
Change:
if realPath != "" { // Only create the symlink when container log path is specified and log file exists. <ins> // Delete possibly existing file first if err = ds.os.Remove(path); err == nil { glog.Warningf("Deleted previously existing symlink file: %q", path) } </ins> if err = ds.os.Symlink(realPath, path); err != nil { return fmt.Errorf("failed to create symbolic link %q to the container log file %q for container %q: %v", path, realPath, containerID, err)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I have a transient local disk mounted under /var/lib/docker in order to take advantage of faster IO on Azure VMs. This means that all that data is lost when a reboot occurs, but the rest of the data outside that mountpoint persists. After the reboot, the existing pods are relaunched, and kubelet is unable to create the log file symlinks because they already exist, but they are pointing to an invalid place, that container no longer exists. Here are the relevant log lines: The old symlinks are there: What you expected to happen: The correct symlinks should overwrite the old ones. How to reproduce it (as minimally and precisely as possible): Erase /var/lib/docker between reboots with existing pods. Anything else we need to know?: No. Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-06-30T17:46:00Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: Azure VMs OS (e.g. from /etc/os-release): Container Linux by CoreOS 1409.6.0 (Ladybug) Kernel (e.g. ): Linux node-2-vm 4.11.9-coreos SMP Thu Jul 6 00:54:42 UTC 2017 x86_64 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list .

The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
I think this falls under
Reiterating the mentions to trigger a notification: <detailsIn response to : I think this falls under 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:
framework.KubeDescribe("DynamicProvisioner", func() { It("should create and delete persistent volumes [Slow]", func() { <del> // added until the GKE startup includes storage.k8s.io/v1beta1 framework.SkipIfProviderIs("gke") </del> framework.SkipUnlessProviderIs("openstack", "gce", "aws", "gke") By("creating a StorageClass")

Discussion:
pull-kubernetes-local-e2e pull-kubernetes-local-e2e.Overall 02-01 and ` No response /sig testing
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
that's not the reason for failure, we don't exit non-zero on this. This job is running and is failing tests.
But what about this one , all tests pass but it fails because a running process is not terminated, i believe is the docker process. I think we are hit by thus the proposed solution to try to send SIG Term wait 30 seconds and if not successfully terminated try to kill the docker process.
/assign
is the PR which I mentioned in the SIG meeting, It introduced the timeout of 30 seconds as a remedy, but unfortunately issue re-appeared.
This job is running , all test passed but failed again for same issue
/assign
wasn't enough to fix this :-( , i checked with , attempts to fix this.
/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
Change:
framework.KubeDescribe("DynamicProvisioner", func() { It("should create and delete persistent volumes [Slow]", func() { <del> // added until the GKE startup includes storage.k8s.io/v1beta1 framework.SkipIfProviderIs("gke") </del> framework.SkipUnlessProviderIs("openstack", "gce", "aws", "gke") By("creating a StorageClass")

Discussion:
We need to revert when the gke control plane is updated. This should be merged AFTER gke is ready. I think may have been merged too early. I'm doing an issue instead of a pull in case a bot did the merge.
This hasn't been touched in 5d, but is listed as blocking v1.4. Where are we on this?
am I good to re-enable the dynamic provisioning test?
can you help answer for ?
I think we're ok to re-enable this.
Opened to re-enable the test. I don't know of a way for me to trigger the gke tests on the pull before merging
Trying something i spotted for kubemark -
Change:
}) } } <ins> func TestCreateServiceWithNamespace(t *testing.T) { svcName := "test-service" ns := "test" tf := cmdtesting.NewTestFactory().WithNamespace(ns) defer tf.Cleanup() tf.ClientConfigVal = &restclient.Config{} ioStreams, _, buf, _ := genericclioptions.NewTestIOStreams() cmd := NewCmdCreateServiceClusterIP(tf, ioStreams) cmd.Flags().Set("dry-run", "client") cmd.Flags().Set("output", "jsonpath={.metadata.namespace}") cmd.Flags().Set("clusterip", "None") cmd.Run(cmd, []string{svcName}) if buf.String() != ns { t.Errorf("expected output: %s, but got: %s", ns, buf.String()) } } </ins>

Discussion:
I'm writing a small bash script which generates some k8s resources in a namespace (other than ). When using to generate a service, the yaml which is generated does not include the defined namespace. I've also tried to move around the argument to the beginning (i.e. , but that doesn't work as well. Generated yaml should include the , when it's defined as an option. Kubernetes version (use ): Cloud provider or hardware configuration: n/a (not really important) OS (e.g: ): Kernel (e.g. ): Install tools: kubectl Network plugin and version (if this is a network-related bug): n/a Others: /sig cli
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 cli
/assign
Change:
}, Status: corev1.PersistentVolumeClaimStatus{}, }, <del> expectedElements: []string{"nDataSource:n  Name:      srcpvcn  Kind:      PersistentVolumeClaim"}, </del> <ins> expectedElements: []string{"nDataSource:n  Kind:      PersistentVolumeClaimn  Name:      srcpvc"}, </ins> }, { name: "snapshot-datasource",

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: Miss APIGroup of DataSource. What you expected to happen: kubectl describe pvc should also describe the apigroup 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:
/assign
/sig storage
Change:
} func (o *Options) Complete() error { <del> if len(o.ConfigFile) == 0 { glog.Warning("WARNING: all flags other than --config are deprecated. Please begin using a config file ASAP.") </del> <ins> if len(o.ConfigFile) == 0 && len(o.WriteConfigTo) == 0 { glog.Warning("WARNING: all flags other than --config, --write-config-to, and --cleanup are deprecated. Please begin using a config file ASAP.") </ins> o.applyDeprecatedHealthzAddressToConfig() o.applyDeprecatedHealthzPortToConfig() o.applyDeprecatedAlgorithmSourceOptionsToConfig() } <ins> if len(o.ConfigFile) > 0 { if c, err := o.loadConfigFromFile(o.ConfigFile); err != nil { return err } else { o.config = c } } // Apply algorithms based on feature gates. // TODO: make configurable? algorithmprovider.ApplyFeatureGates() </ins> return nil }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: We face But there is no way to generate default config file How to reproduce it (as minimally and precisely as possible): Environment: Kubernetes version 1.9.2
I'll take a look it /sig scheduling
/assign
Hi, same issue with controller-manager
Any updates here? , and don't have this flag. Is it even will be supported?
/cc
if not set, component should be use default value; why we'd like to dump all default config?
Because the documentation on the config file format is either nonexistent or difficult to find. If the program itself can generate a template, that fulfills (most of) the need for documentation of the format.
+1 for this, from my expirence, add an option to write the default config is really helpful.
/assign
also in 1.10
Deprecating all flags, prompting folks to use config files in advance is great, except when there's no documentation nor example anywhere. That means that we can't actually migrate to the new settings, and I can't seem to find clear alpha/beta/stable status for the new config file spec, nor timeline for the removal. It is also pretty confusing that the scheduler expects us to use a config file, but the controller-manager does not?
This issue indeed applies to kube-controller-manager. And there should already had deprecation policy.
According to , the flag will be available in . Since I can't find any reference online to an example config file, perhaps one could be provided or linked to here?
will you be able to pick my patch and generate a config file? I do not get my devbox handy so can only post here until Monday.
Change:
cluster/gce/configure-vm.sh:  cloud_config: ${CLOUD_CONFIG} cluster/gce/configure-vm.sh:  env-to-grains "runtime_config" cluster/gce/configure-vm.sh:  kubelet_api_servers: '${KUBELET_APISERVER}' <del> cluster/gce/coreos/node-helper.sh:# cloud_config yaml file should be passed </del> cluster/gce/gci/configure-helper.sh:      reconcile_cidr="false" cluster/gce/gci/configure-helper.sh:  local api_servers="--master=https://${KUBERNETES_MASTER_NAME}" cluster/gce/gci/configure-helper.sh:  local reconcile_cidr="true" cluster/gce/gci/configure-helper.sh:  sed -i -e "s@{{pillar['allow_privileged']}}@true@g" "${src_file}" cluster/gce/trusty/configure-helper.sh:  sed -i -e "s@{{pillar['allow_privileged']}}@true@g" "${src_file}" cluster/gce/util.sh:    local node_ip=$(gcloud compute instances describe --project "${PROJECT}" --zone "${ZONE}"  <del> cluster/juju/layers/kubernetes/reactive/k8s.py:    cluster_name = 'kubernetes' </del> cluster/juju/layers/kubernetes/reactive/k8s.py:    check_call(split(cmd.format(kubeconfig, cluster_name, server, ca))) cluster/juju/layers/kubernetes/reactive/k8s.py:    check_call(split(cmd.format(kubeconfig, context, cluster_name, user))) cluster/juju/layers/kubernetes/reactive/k8s.py:    client_key = '/srv/kubernetes/client.key' <ins> cluster/juju/layers/kubernetes/reactive/k8s.py:    cluster_name = 'kubernetes' </ins> cluster/juju/layers/kubernetes/reactive/k8s.py:    tlslib.client_key(None, client_key, user='ubuntu', group='ubuntu') cluster/lib/logging.sh:      local source_file=${BASH_SOURCE[$frame_no]} cluster/lib/logging.sh:  local source_file=${BASH_SOURCE[$stack_skip]}

Discussion:
seems to have broken the kubernetes service when using : With this patch: Without it: Tested with v 1.3.2.
Looks like we don't like explicitly don't want to allow 127.0.0.1 loopback address here -
Change:
}) ginkgo.BeforeEach(func() { <ins> if err := lookEmitSignalCommand(); err != nil { e2eskipper.Skipf("skipping test because: %v", err) return } </ins> ginkgo.By("Wait for the node to be ready") waitForNodeReady() })

Discussion:
Failing on cri-o serial job. Looks like the dbus command isn't available for graceful shutdown tests that aren't running on Ubuntu. /assign /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon
/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
hmm, is this still issue? The testgrid job is still failing even after the fix appears to be merged? !
Please take a look when you get a chance, the error still seems to be that dbus-send is unavailable... /cc
oops... I forgot to add this to the other
Change:
"testing" "time" <del> v1 "k8s.io/api/core/v1" </del> <ins> "k8s.io/api/core/v1" </ins> apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" "k8s.io/apimachinery/pkg/types" <ins> "k8s.io/apimachinery/pkg/util/intstr" </ins> utilfeature "k8s.io/apiserver/pkg/util/feature" "k8s.io/client-go/informers" "k8s.io/client-go/kubernetes/fake"

Discussion:
Hello , I have saw the commit , can we check the for enqueue to serivce cotnroller work queue? basecause of, In many case for Public Cloud, We always abstract a set for health checks , such as TargetGroup in AWS, instanceGroup in aliyun. We can map to such a collection of instance. If the service controller to check the targetgroup changes, the traffic pass-through pod is easier to implement. In most cases, the instance that in same group has an associated port for external services, and service controller set a target port if which not set in service yaml file. On the other handWe only lose some other performance of service controller. and Implementing targetgroup mapping to targetport depends on the cloud provider. What do you think? /sig cloud-provider /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
return nil, fmt.Errorf("attempt to adopt revision owned by %v", owner) } // Use strategic merge patch to add an owner reference indicating a controller ref <del> return rh.client.Apps().ControllerRevisions(parent.GetNamespace()).Patch(revision.GetName(), </del> <ins> return rh.client.AppsV1beta1().ControllerRevisions(parent.GetNamespace()).Patch(revision.GetName(), </ins> types.StrategicMergePatchType, []byte(fmt.Sprintf( `{"metadata":{"ownerReferences":[{"apiVersion":"%s","kind":"%s","name":"%s","uid":"%s","controller":true,"blockOwnerDeletion":true}],"uid":"%s"}}`, parentKind.GroupVersion().String(), parentKind.Kind,

Discussion:
The statefulset controller and controller history implementations should be migrated off of the Apps client (deprecated) and onto the AppsV1BetaClient. Currently there is no user facing issue caused by the use of the deprecated resource, but we should maintain good code hygiene.
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 .
/assign kow3ns
/assign kow3ns
/cc
/assign
Change:
gvr("flowcontrol.apiserver.k8s.io", "v1beta1", "prioritylevelconfigurations"): { Stub:             `{"metadata": {"name": "conf2"}, "spec": {"type": "Limited", "limited": {"assuredConcurrencyShares":3, "limitResponse": {"type": "Reject"}}}}`, ExpectedEtcdPath: "/registry/prioritylevelconfigurations/conf2", <del> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta2", "PriorityLevelConfiguration"), </del> <ins> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta3", "PriorityLevelConfiguration"), </ins> }, // --

Discussion:
adds new version for in 1.26. For 1.26, we are setting the storage version to because vN-1 understands that level. In 1.27, we should change the storage version from to .
/sig api-machinery
/cc
/cc
/triage accepted
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]: