jiebi/CodeConvo huggingface dataset:
Code change:
"    Driver:t%vn"+ "    FSType:t%vn"+ "    SecretRef:t%vn"+ <del> "    ReadOnly:t%vn", </del> <ins> "    ReadOnly:t%vn"+ </ins> "    Options:t%vn", flex.Driver, flex.FSType, flex.SecretRef, flex.ReadOnly, flex.Options) }

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: when i create PersistentVolume, yaml like that: than describe it, got : What you expected to happen: Like that: How to reproduce it (as minimally and precisely as possible): What's said in Anything else we need to know?: Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig storage
Already got PR to fix this. /assign
Code change:
return cmdutil.AddSourceToErr(fmt.Sprintf("retrieving modified configuration from:n%vnfor:", info), info.Source, err) } <ins> // Print object only if output format other than "name" is specified printObject := len(output) > 0 && !shortOutput </ins> if err := info.Get(); err != nil { if !errors.IsNotFound(err) { return cmdutil.AddSourceToErr(fmt.Sprintf("retrieving current configuration of:n%vnfrom server for:", info), info.Source, err)

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: Bug Report /kind bug What happened: Applying a file that has no changes compared to current will output something like , which muddles the output when using What you expected to happen: Using the -o flag should suppress the unchanged messages in stdout to prevent output from being muddled How to reproduce it (as minimally and precisely as possible): Given the file Will result in proper yaml being generated as expected Run again, and is outputted to stdout, and is invalid yaml Anything else we need to know?: I do need to check whether this still affects the most recent version kubectl Environment: Kubernetes version (use ): 1.8.6 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Darwin Install tools: Others:
confirmed on latest stable version (1.9.2)
Reiterating the mentions to trigger a notification: <detailsIn response to : confirmed on latest stable version (1.9.2) 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
I have a solution to this, still waiting on my company to look over the agreement
Code change:
// Both names occurred in practice. goleak.IgnoreTopFunction("k8s.io/kubernetes/vendor/gopkg.in/natefinch/lumberjack%2ev2.(*Logger).millRun"), goleak.IgnoreTopFunction("gopkg.in/natefinch/lumberjack%2ev2.(*Logger).millRun"), <ins> // If there is an error during connection shutdown, SPDY keeps a // goroutine around for ten minutes, which gets reported as a leak // (the goroutine is cleaned up after the ten minutes). // // https://github.com/kubernetes/kubernetes/blob/master/vendor/github.com/moby/spdystream/connection.go#L732-L744 // // Ignore this reported leak. goleak.IgnoreTopFunction("github.com/moby/spdystream.(*Connection).shutdown"), </ins> ) stop, err := startEtcd(nil)

Related discussion:
text: master-blocking: integration-master- This has been occasionally flaking for some time. Recent Failures: Another leak was fixed at /sig api-machinery /sig testing
/retitle [Flaking Test] integration-master (goroutine leak detection)
Some server is not stopping gracefully on that test
Similar reason:
Its either not terminating gracefully or there is a request that isn't being being served in a timely manner, because I also see a bunch of goroutines waiting on the netpoller.
/triage accepted (for SIG api-machinery)
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accepted (for SIG api-machinery) 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
I don't think this would be a release blocker, still can you confirm whether this would block the upcoming alpha 1 release cut?
Another failure:
Hey , The deadline for the alpha 1 release cut has been delayed to Monday, June 10 and we are still waiting for confirmation of this issue. Do you think this will be a release blocker?
/assign
/assign
integration test flake, we believe this PR fixes it: I'm not marking this fixed because it also mentions a integration test flake.
Code change:
// GetObjectMetricReplicas calculates the desired replica count based on a target metric utilization (as a milli-value) // for the given object in the given namespace, and the current replica count. <del> func (c *ReplicaCalculator) GetObjectMetricReplicas(currentReplicas int32, targetUtilization int64, metricName string, namespace string, objectRef *autoscaling.CrossVersionObjectReference) (replicaCount int32, utilization int64, timestamp time.Time, err error) { </del> <ins> func (c *ReplicaCalculator) GetObjectMetricReplicas(currentReplicas int32, targetUtilization int64, metricName string, namespace string, objectRef *autoscaling.CrossVersionObjectReference, selector labels.Selector) (replicaCount int32, utilization int64, timestamp time.Time, err error) { </ins> utilization, timestamp, err = c.metricsClient.GetObjectMetric(metricName, namespace, objectRef) if err != nil { return 0, 0, time.Time{}, fmt.Errorf("unable to get metric %s: %v on %s %s/%s", metricName, objectRef.Kind, namespace, objectRef.Name, err)

Related discussion:
text: metric definition { "type": "Object", "object": { "target": { "kind": "Service", "name": "prometheus-exporter" }, "metricName": "PercentUtilization", "targetValue": "20" } } which should handle as and doesn't check Pod state.
I think proper handling of unready pods is a difficult problem that will require significant work. I suspect we may find out we need to start distinguishing pods that are booting up from pods that are 'broken' and it took us quite a while to solve analogous problem with nodes in Cluster Autoscaler (to be clear: I don't know if we will have to do that, that's just my intuition for now). That being said I agree the formula in GetObjectMetricReplicas will generally lead to scaling-up too much if the pod takes longer to initialize then backoff period in HPA (3 minutes). Assume it takes pod 4 minutes to boot up and we're currently running 2 pods. Metric value is 20 and target is 10. In this case: scales-up to 4 pods (20/10 utilization 2 pods). are starting up, they're not doing anything yet. 3 minutes later HPA scales-up to 8 pods (20/10 utilization 4 pods). If we only counted ready pods the scale-up in 3 would not occur, because the desired replicas would still be 4 (20/10 * 2). My intuition would be that this is the expected behavior of HPA. Also if there is no space in the cluster we will just keep scaling-up until we hit max replicas. The only case where current behavior would be more correct than filtering out unready pods in this formula is if someone uses a metric that is calculated based on total number of replicas. Do we advertise that as the right way to use HPA? If we add to Object metrics in 1.11 this usage pattern will stop making sense. To sum up - I think we will need to change the formula to only count ready pods at some point. I can see how current behavior could be a problem in any use-case except the one described in paragraph above. I'm inclined to agree with and provide some way to change the behavior in 1.10 (a flag or an annotation?), treating it as a bug fix.
Code change:
// GetObjectMetricReplicas calculates the desired replica count based on a target metric utilization (as a milli-value) // for the given object in the given namespace, and the current replica count. <del> func (c *ReplicaCalculator) GetObjectMetricReplicas(currentReplicas int32, targetUtilization int64, metricName string, namespace string, objectRef *autoscaling.CrossVersionObjectReference) (replicaCount int32, utilization int64, timestamp time.Time, err error) { </del> <ins> func (c *ReplicaCalculator) GetObjectMetricReplicas(currentReplicas int32, targetUtilization int64, metricName string, namespace string, objectRef *autoscaling.CrossVersionObjectReference, selector labels.Selector) (replicaCount int32, utilization int64, timestamp time.Time, err error) { </ins> utilization, timestamp, err = c.metricsClient.GetObjectMetric(metricName, namespace, objectRef) if err != nil { return 0, 0, time.Time{}, fmt.Errorf("unable to get metric %s: %v on %s %s/%s", metricName, objectRef.Kind, namespace, objectRef.Name, err)

Related discussion:
text: WDYT
Ah, yeah, I missed that it was object metrics before. I'm not entirely convinced we need a flag here -- it might just make sense to bring Object metrics in line with all the other metrics types. On the other hand, there's a subtlety here -- the other metric types don't quite ignore unready pods -- they just ignore the metrics from unready pods, which causes a heavy bias in the direction of not scaling, but an overwhelming spike can still cause scaling. That behavior is not as achievable using object metrics. I'm inclined to just ignore that subtlety, though, and say that object metrics should ignore unready pods entirely.
I think this is what we should do long term. I was worried about breaking someone who relies on targetValue + averaged metric to get effect similar to targetAverageValue and though about providing something for transitional period, but if you're ok with it I'd rather just change it as you say.
I think it's safe to change as-is -- that feature's still in beta, and it's not an API change, so it shouldn't just hard-break anyone. Plus, we've change stuff like this before (when we did the initial resource metrics change).
As said, we are more than ready to help with the fix/test if required. This since this is a major blocking for us in the implementation of the HPA in our side
is anyone actively working on implementing this? If not, I'm happy to. I think I have a fairly clear picture of the change we need to make and will likely have time early this week to get it done.
(Also, from the conversation above, to we want to tag this as a release blocker for 1.10)?
I probably won't be able to work on this before the end of this week. Happy to do a review if you jump in and implement it.
I don't think this qualifies as a release blocking bug (but I'm willing to have someone try and convince me otherwise ;-)). There doesn't seem to be any behavior here that's explicitly broken -- it's just sub-optimal in some use cases. I'd definitely like to address this in 1.11, though.
it's not release blocker, but to share our experience ;).
Code change:
// GetObjectMetricReplicas calculates the desired replica count based on a target metric utilization (as a milli-value) // for the given object in the given namespace, and the current replica count. <del> func (c *ReplicaCalculator) GetObjectMetricReplicas(currentReplicas int32, targetUtilization int64, metricName string, namespace string, objectRef *autoscaling.CrossVersionObjectReference) (replicaCount int32, utilization int64, timestamp time.Time, err error) { </del> <ins> func (c *ReplicaCalculator) GetObjectMetricReplicas(currentReplicas int32, targetUtilization int64, metricName string, namespace string, objectRef *autoscaling.CrossVersionObjectReference, selector labels.Selector) (replicaCount int32, utilization int64, timestamp time.Time, err error) { </ins> utilization, timestamp, err = c.metricsClient.GetObjectMetric(metricName, namespace, objectRef) if err != nil { return 0, 0, time.Time{}, fmt.Errorf("unable to get metric %s: %v on %s %s/%s", metricName, objectRef.Kind, namespace, objectRef.Name, err)

Related discussion:
text: without this feature we cannot use HPA as is and we need to figure out how to build/run fork (which can be challenging because everything inside controller-manager). also we are planning to upgrade to 1.10 quickly, but not sure for 1.11 (e.g. we are two versions behind now).
Sounds like a plan :) Will try and get this done tomorrow morning!
- I submitted a pr for this - would love your eyes on it so you can see if you think it meets your use case :)
/assign
GitHub didn't allow me to assign the following users: mattjmcnaughton. Note that only and repo collaborators can be assigned. <detailsIn response to : /assign 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
I checked the code and it seems good to me. About the comment about scaling down if the readyPods<CurrentPods, we should be fine since our metric is already not including the pods that are not ready.
Is there any advance in this ticket? I'm wondering if this made it to k8s 1.10 or if we need to wait for k8s 1.11?
The PR is lgtm-ed and it will merge once the code freeze is lifted. Meaning it will go to 1.11. To get it into 1.10 you would need to get approval for milestone from (sig-autoscaling lead).
Code change:
&& clean-install $BUILD_DEPS  ca-certificates  libjemalloc1  <del> liblz4-1  </del> ruby  && echo 'gem: --no-document' >> /etc/gemrc  && gem install --file Gemfile  && apt-get purge -y --auto-remove  -o APT::AutoRemove::RecommendsImportant=false  $BUILD_DEPS  <del> && rm -rf /tmp/*  /var/lib/apt/lists/*  /usr/lib/ruby/gems/*/cache/*.gem  /var/log/*  /var/tmp/*  </del> <ins> && clean-apt  </ins> # Ensure fluent has enough file descriptors && ulimit -n 65536

Related discussion:
text: <!-- 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?: What happened: [root EFK]# kubectl logs -f fluentd-es-jrsf7 -n kube-system /var/lib/gems/2.1.0/gems/ffi- block in ffilib': Could not open library '': cannot open shared object file: No such file or directory. (LoadError) Could not open library '': cannot open shared object file: No such file or directory. Could not open library 'libsystemd-': cannot open shared object file: No such file or directory. Could not open library 'libsystemd-': libsystemd- cannot open shared object file: No such file or directory from /var/lib/gems/2.1.0/gems/ffi-map' from /var/lib/gems/2.1.0/gems/ffi- ffilib' from /var/lib/gems/2.1.0/gems/systemd-journal-<module:Native' from /var/lib/gems/2.1.0/gems/systemd-journal- &lt;module:Id128' from /var/lib/gems/2.1.0/gems/systemd-journal-<module:Systemd' from /var/lib/gems/2.1.0/gems/systemd-journal- &lt;top (required)' fromrequire' from require' from /var/lib/gems/2.1.0/gems/systemd-journal-<top (required)' from require' fromrequire' from /var/lib/gems/2.1.0/gems/systemd-journal- &lt;top (required)' fromrequire' from rescue in require' fromrequire' from /var/lib/gems/2.1.0/gems/fluent-plugin-systemd- &lt;top (required)' fromrequire' from require' from /var/lib/gems/2.1.0/gems/fluentd-block in tryloadplugin' from /var/lib/gems/2.1.0/gems/fluentd- each' from /var/lib/gems/2.1.0/gems/fluentd-tryloadplugin' from /var/lib/gems/2.1.
Code change:
&& clean-install $BUILD_DEPS  ca-certificates  libjemalloc1  <del> liblz4-1  </del> ruby  && echo 'gem: --no-document' >> /etc/gemrc  && gem install --file Gemfile  && apt-get purge -y --auto-remove  -o APT::AutoRemove::RecommendsImportant=false  $BUILD_DEPS  <del> && rm -rf /tmp/*  /var/lib/apt/lists/*  /usr/lib/ruby/gems/*/cache/*.gem  /var/log/*  /var/tmp/*  </del> <ins> && clean-apt  </ins> # Ensure fluent has enough file descriptors && ulimit -n 65536

Related discussion:
text: 0/gems/fluentd- newimpl' from /var/lib/gems/2.1.0/gems/fluentd-newinput' from /var/lib/gems/2.1.0/gems/fluentd- addsource' from /var/lib/gems/2.1.0/gems/fluentd-block in configure' from /var/lib/gems/2.1.0/gems/fluentd- each' from /var/lib/gems/2.1.0/gems/fluentd-configure' from /var/lib/gems/2.1.0/gems/fluentd- configure' from /var/lib/gems/2.1.0/gems/fluentd-runconfigure' from /var/lib/gems/2.1.0/gems/fluentd- runconfigure' from /var/lib/gems/2.1.0/gems/fluentd-block in start' from /var/lib/gems/2.1.0/gems/fluentd- call' from /var/lib/gems/2.1.0/gems/fluentd-mainprocess' from /var/lib/gems/2.1.0/gems/fluentd- start' from /var/lib/gems/2.1.0/gems/fluentd-<top (required)' from require' fromrequire' from /var/lib/gems/2.1.0/gems/fluentd-0.12.39/bin/fluentd:5:in &lt;top (required)' from /usr/local/bin/fluentd:23:inload' from /usr/local/bin/fluentd:23:in &lt;main' What you expected to happen: fluentd-es run success How to reproduce it (as minimally and precisely as possible): kubectl create -f fluentd-es- the image is google-containers/fluentd-elasticsearch:v2.0.0 Anything else we need to know?
Code change:
&& clean-install $BUILD_DEPS  ca-certificates  libjemalloc1  <del> liblz4-1  </del> ruby  && echo 'gem: --no-document' >> /etc/gemrc  && gem install --file Gemfile  && apt-get purge -y --auto-remove  -o APT::AutoRemove::RecommendsImportant=false  $BUILD_DEPS  <del> && rm -rf /tmp/*  /var/lib/apt/lists/*  /usr/lib/ruby/gems/*/cache/*.gem  /var/log/*  /var/tmp/*  </del> <ins> && clean-apt  </ins> # Ensure fluent has enough file descriptors && ulimit -n 65536

Related discussion:
text: : Environment: Kubernetes version (use ):Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-21T08:23:22Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-21T08:08:00Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release):centos 7.3 Kernel (e.g. ):Linux node-21.46 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x86_64 GNU/Linux Install tools: Others:
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
Yup, the situation with fluentd on the system with systemd is very sloppy. There's a hack to make it works sometimes, but it seems that it doesn't work. I'll look into it
/sig instrumentation /assign
Facing same issue.
Code change:
&& clean-install $BUILD_DEPS  ca-certificates  libjemalloc1  <del> liblz4-1  </del> ruby  && echo 'gem: --no-document' >> /etc/gemrc  && gem install --file Gemfile  && apt-get purge -y --auto-remove  -o APT::AutoRemove::RecommendsImportant=false  $BUILD_DEPS  <del> && rm -rf /tmp/*  /var/lib/apt/lists/*  /usr/lib/ruby/gems/*/cache/*.gem  /var/log/*  /var/tmp/*  </del> <ins> && clean-apt  </ins> # Ensure fluent has enough file descriptors && ulimit -n 65536

Related discussion:
text: Environment Details:kubectl version Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} OS (e.g. from /etc/os-release):Centos 7 (Core) Kernel (e.g. uname -a): Linux xxxx 3.10.0-327.el7.x8664 Error for reference /var/lib/gems/2.1.0/gems/ffi- block in ffilib': Could not open library '': cannot open shared object file: No such file or directory. (LoadError) Could not open library '': cannot open shared object file: No such file or directory. Could not open library 'libsystemd-': cannot open shared object file: No such file or directory. Could not open library 'libsystemd-': libsystemd- cannot open shared object file: No such file or directory from /var/lib/gems/2.1.0/gems/ffi-map' from /var/lib/gems/2.1.0/gems/ffi- ffilib' from /var/lib/gems/2.1.0/gems/systemd-journal-<module:Native' from /var/lib/gems/2.1.0/gems/systemd-journal- &lt;module:Id128' from /var/lib/gems/2.1.0/gems/systemd-journal-<module:Systemd' from /var/lib/gems/2.1.0/gems/systemd-journal- &lt;top (required)' fromrequire' from require' from /var/lib/gems/2.1.0/gems/systemd-journal-<top (required)' from require' fromrequire' from /var/lib/gems/2.1.
Code change:
&& clean-install $BUILD_DEPS  ca-certificates  libjemalloc1  <del> liblz4-1  </del> ruby  && echo 'gem: --no-document' >> /etc/gemrc  && gem install --file Gemfile  && apt-get purge -y --auto-remove  -o APT::AutoRemove::RecommendsImportant=false  $BUILD_DEPS  <del> && rm -rf /tmp/*  /var/lib/apt/lists/*  /usr/lib/ruby/gems/*/cache/*.gem  /var/log/*  /var/tmp/*  </del> <ins> && clean-apt  </ins> # Ensure fluent has enough file descriptors && ulimit -n 65536

Related discussion:
text: 0/gems/systemd-journal- &lt;top (required)' fromrequire' from rescue in require' fromrequire' from /var/lib/gems/2.1.0/gems/fluent-plugin-systemd- &lt;top (required)' fromrequire' from require' from /var/lib/gems/2.1.0/gems/fluentd-block in tryloadplugin' from /var/lib/gems/2.1.0/gems/fluentd- each' from /var/lib/gems/2.1.0/gems/fluentd-tryloadplugin' from /var/lib/gems/2.1.0/gems/fluentd- newimpl' from /var/lib/gems/2.1.0/gems/fluentd-newinput' from /var/lib/gems/2.1.0/gems/fluentd- addsource' from /var/lib/gems/2.1.0/gems/fluentd-block in configure' from /var/lib/gems/2.1.0/gems/fluentd- each' from /var/lib/gems/2.1.0/gems/fluentd-configure' from /var/lib/gems/2.1.0/gems/fluentd- configure' from /var/lib/gems/2.1.0/gems/fluentd-runconfigure' from /var/lib/gems/2.1.0/gems/fluentd- runconfigure' from /var/lib/gems/2.1.0/gems/fluentd-block in start' from /var/lib/gems/2.1.0/gems/fluentd- call' from /var/lib/gems/2.1.0/gems/fluentd-mainprocess' from /var/lib/gems/2.1.0/gems/fluentd- start' from /var/lib/gems/2.1.0/gems/fluentd-<top (required)' from require' fromrequire' from /var/lib/gems/2.1.0/gems/fluentd-0.12.39/bin/fluentd:5:in &lt;top (required)' from /usr/local/bin/fluentd:23:inload' from /usr/local/bin/fluentd:23:in &lt;
Code change:
&& clean-install $BUILD_DEPS  ca-certificates  libjemalloc1  <del> liblz4-1  </del> ruby  && echo 'gem: --no-document' >> /etc/gemrc  && gem install --file Gemfile  && apt-get purge -y --auto-remove  -o APT::AutoRemove::RecommendsImportant=false  $BUILD_DEPS  <del> && rm -rf /tmp/*  /var/lib/apt/lists/*  /usr/lib/ruby/gems/*/cache/*.gem  /var/log/*  /var/tmp/*  </del> <ins> && clean-apt  </ins> # Ensure fluent has enough file descriptors && ulimit -n 65536

Related discussion:
text: main'
You can solve it temporary by removing I'm working on the solution
A solution here might be to base fluentd-es off an image with journald supporting XZ and LZ4 compression. I'm looking :)
Thanks
Code change:
"k8s.io/kubernetes/test/e2e/storage/utils" imageutils "k8s.io/kubernetes/test/utils/image" admissionapi "k8s.io/pod-security-admission/api" <ins> "github.com/onsi/ginkgo/v2" "github.com/onsi/gomega" </ins> ) // Validate PV/PVC, create and verify writer pod, delete the PVC, and validate the PV's

Related discussion:
text: [X] test approval issue : [X] test pr : [x] two weeks soak end date : 11 Sept 2023 [x] test promotion pr : [x] remove endpoint from According to following APIsnoop query, there are two PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 13 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 13 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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