jiebi/CodeConvo huggingface dataset:
Code change:
if limitedMode { limitedNum-- } <ins> if len(msg.log) > 0 { isNewLine = msg.log[len(msg.log)-1] == eol[0] } else { isNewLine = true } </ins> } }

Related discussion:
text: If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <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
/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
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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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 /reopen will fix it.
Reopened this issue. <detailsIn response to : /remove-lifecycle rotten /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
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
Code change:
if limitedMode { limitedNum-- } <ins> if len(msg.log) > 0 { isNewLine = msg.log[len(msg.log)-1] == eol[0] } else { isNewLine = true } </ins> } }

Related discussion:
text: 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]:
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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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 .
Code change:
if limitedMode { limitedNum-- } <ins> if len(msg.log) > 0 { isNewLine = msg.log[len(msg.log)-1] == eol[0] } else { isNewLine = true } </ins> } }

Related discussion:
text: If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I received a bug report about this issue. The root cause is that the buffer reads up to a new line. If the line is greater than 4096 bytes and '--timestamps' is turrned on the kubelet will write the timestamp and the partial log line. We will need to refactor the ReadLogs function to allow for a partial line read.
Code change:
func exportCustomMetricFromService(f *framework.Framework, consumerName string, metricValue int) *common.ResourceConsumer { serviceAnnotations := map[string]string{ "prometheus.io/scrape": "true", <del> "prometheus.io/path":   "/Metrics", </del> <ins> "prometheus.io/path":   "/metrics", </ins> "prometheus.io/port":   "8080", } return common.NewMetricExporter(consumerName, f.Namespace.Name, nil, serviceAnnotations, metricValue, f.ClientSet, f.InternalClientset, f.ScalesGetter)

Related discussion:
text: <!-- 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: Used the endpoint /BumpMetric to create fake metrics for Prometheus. When I tried to curl /metrics I got the following response: Bad request. Not a POST request What you expected to happen: I expected to see something like this: # HELP info message. # TYPE gauge 0. How to reproduce it (as minimally and precisely as possible): Following the docs, after having it running inside kubernetes: Anything else we need to know?: Looks like introduced this by mistake. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig testing
Code change:
args: args, // PodStart is used as default because waiting for a pod is the // most common operation. <del> timeout:  TestContext.timeouts.PodStart, interval: TestContext.timeouts.Poll, </del> <ins> timeout:      TestContext.timeouts.PodStart, interval:     TestContext.timeouts.Poll, consistently: consistently, </ins> } }

Related discussion:
text: In and , I started seeing these flakes. The job in question has not been very flaky before so this is odd. In and , I started seeing these flakes. The job "Job should not create pods when created in suspend state" is the one that is flaking. Triage says a few days ago. No response No response /sig apps
Did some digging and I did not see any changes that could account for an increase of flakiness in the job controller code. There was a change made to the e2e tests: The logs say: The code is pretty simple so I wonder if we are hitting a case where sometimes the suspend condition is not set and we fail. Maybe we could add a consistent call here?
/triage accepted /priority important-soon
/cc
/reopen /assign do you mind monitoring the CI state for 1 or 2 days to confirm your PR really fixed it ?
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
It makes sense to me.
cc I think this issue has been fixed. Can we close it?
/close Thanks for the fix. The test is not flaky now.
Closing this issue. <detailsIn response to : 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
Code change:
// +groupName=samplecontroller.k8s.io // Package v1alpha1 is the v1alpha1 version of the API. <del> package v1alpha1 </del> <ins> package v1alpha1 // import "k8s.io/sample-controller/pkg/apis/samplecontroller/v1alpha1" </ins>

Related discussion:
text: Look at one of the directories under (Please don't pick more than one directory for one PR as it will cause issues for reviewers) Find all the files named (example find -name ) See the following link it has a this tells tools how this package needs to be imported. So we should ensure that each has an import Add a description appropriate to the package (similar to the one below) Look through sub directories and see if there are any other important directories that are likely to be used by outside users and add a Why are we doing this? We perfer to use vanity urls instead of directly using to refer to code, so this helps ensure that tools honor our wish. See It would be good to have some package level documentation since these directories under staging/ are meant to be for use by folks outside of kubernetes github org. /good-first-issue
/kind documentation /sig architecture
currently working my through Not going to use / assign since there could be a number of PRs for this issue.
/lifecycle active /good-first-issue edit: hmm..
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /lifecycle active /good-first-issue 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
May I try on
IIUC this means that there needs to be a even at the root of the repo? Then how does work? :thinking:
Hi , can I make a PR for this directory ?
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 .
Code change:
// +groupName=samplecontroller.k8s.io // Package v1alpha1 is the v1alpha1 version of the API. <del> package v1alpha1 </del> <ins> package v1alpha1 // import "k8s.io/sample-controller/pkg/apis/samplecontroller/v1alpha1" </ins>

Related discussion:
text: /lifecycle rotten
I guess this is still not done, was supposed to partially fix this issue. /reopen
Reopened this issue. <detailsIn response to : I guess this is still not done, was supposed to partially fix this issue. 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 /area code-organization
Code change:
# Arguments: a list of kubernetes packages to build. # Expected variables: ${build_args} should be set to an array of Go build arguments. # In addition, ${package} and ${platform} should have been set earlier, and if <del> # ${build_with_coverage} is set, coverage instrumentation will be enabled. </del> <ins> # ${KUBE_BUILD_WITH_COVERAGE} is set, coverage instrumentation will be enabled. </ins> # # Invokes Go to actually build some packages. If coverage is disabled, simply invokes # go install. If coverage is enabled, builds covered binaries using go test, temporarily # producing the required unit test files and then cleaning up after itself. # Non-covered binaries are then built using go install as usual. kube::golang::build_some_binaries() { <del> if [[ -n "${build_with_coverage:-}" ]]; then </del> <ins> if [[ -n "${KUBE_BUILD_WITH_COVERAGE:-}" ]]; then </ins> local -a uncovered=() for package in "$@"; do if kube::golang::is_instrumented_package "${package}"; then

Related discussion:
text: /kind cleanup /sig testing /priority important-longterm This is a followup issue to address the "standard build globals" nit on At the very least I think we shouldn't capture our custom env var. Also think it'd be worth documenting the assumed variables in a list, similar to
cc
/assign
Code change:
# See the License for the specific language governing permissions and # limitations under the License. <del> # The line below points to debian:jessie as of 2019-10-23. The SHA should be # kept in sycn with debian_jessie definition in the WORKSPACE file. FROM debian@sha256:e25703ee6ab5b2fac31510323d959cdae31eebdf48e88891c549e55b25ad7e94 </del> <ins> # The line below points to distroless/base as of 2019-11-15. The SHA should be # kept in sycn with distroless_base definition in the WORKSPACE file. FROM gcr.io/distroless/base@sha256:7fa7445dfbebae4f4b7ab0e6ef99276e96075ae42584af6286ba080750d6dfe5 </ins> COPY kubemark /kubemark

Related discussion:
text: There are CVEs happening in different images - we already migrated Kubmeark from busybox in , but we should go one step further and migrate the base image to distroless. There are some things that would need to be changed mentioned here: /sig scalability
Can I work on this? /assign
/remove-help
- sure that would be great.
Hi based on the discussion in , the kubemark image has dependency on and maybe more other utilities. So it seems impossible to migrate the base image to distroless? Or do we need something like debian-hyperkube-base?
The mount one we may get rid of - basically we should be able to switch to FakeMounter:
Code change:
hash := hash(podUpdate.nodeName()) select { case <-stopCh: <ins> tc.podUpdateQueue.Done(item) </ins> break case tc.podUpdateChannels[hash%workers] <- podUpdate: } <ins> tc.podUpdateQueue.Done(item) </ins> } }(stopCh)

Related discussion:
text: We're seeing an issue with large memory growth in NoExecuteTaintManager when pods with tolerations are rapidly created/deleted. The item to the workqueue contains the full pod objects received from the informer: That means those pod objects are retained until they are processed. Additionally, it looks like the processing loop never removed the keys from the workqueue when it was done. It also means that multiple updates for the same pod result in multiple items in the workqueue, rather than enqueuing the pod to be processed once, like other controllers do. Simplifying this controller to enqueue pod updates only by name/namespace, and operate on the latest pod obtained from the store (like other controllers do) would speed up the processing and relieve the memory burden of the workqueue. /sig scheduling /cc
/assign
Thanks for finding this Jordan - looking into your fixes.
the memory issue was fixed by /close
Code change:
<del> { "apiVersion": "v1beta3", "kind": "ResourceQuota", "metadata": { "name": "quota" }, "spec": { "hard": { "memory": "1Gi", "cpu": "20", "pods": "10", "services": "5", "replicationcontrollers":"20", "resourcequotas":"1", "secrets":"10", "persistentvolumeclaims":"10" } } } </del>

Related discussion:
text: Resource quota example is missing readme. Was it once there and was accidentally deleted?
I wrote something up in Origin repo I need to repurpose for Kubernetes. Sent from my iPhone
Code change:
return nil } <ins> // applyFSGroup applies the volume ownership it derives its logic // from https://github.com/kubernetes/kubernetes/issues/66323 // 1) if fstype is "", then skip fsgroup (could be indication of non-block filesystem) // 2) if fstype is provided and pv.AccessMode == ReadWriteOnly and !c.spec.ReadOnly then apply fsgroup func (c *csiMountMgr) applyFSGroup(fsType string, fsGroup *int64) error { if fsGroup != nil { if fsType == "" { glog.V(4).Info(log("mounter.SetupAt WARNING: skipping fsGroup, fsType not provided")) return nil } accessModes := c.spec.PersistentVolume.Spec.AccessModes if c.spec.PersistentVolume.Spec.AccessModes == nil { glog.V(4).Info(log("mounter.SetupAt WARNING: skipping fsGroup, access modes not provided")) return nil } if !hasReadWriteOnce(accessModes) { glog.V(4).Info(log("mounter.SetupAt WARNING: skipping fsGroup, only support ReadWriteOnce access mode")) return nil } if c.readOnly { glog.V(4).Info(log("mounter.SetupAt WARNING: skipping fsGroup, volume is readOnly")) return nil } err := volume.SetVolumeOwnership(c, fsGroup) if err != nil { return err } glog.V(4).Info(log("mounter.SetupAt fsGroup [%d] applied successfully to %s", *fsGroup, c.volumeID)) } return nil } </ins> // isDirMounted returns the !notMounted result from IsLikelyNotMountPoint check func isDirMounted(plug *csiPlugin, dir string) (bool, error) { mounter := plug.host.GetMounter(plug.GetPluginName())

Related discussion:
text: It would be a 1.12.
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Approved for 1.12
Based on previous post, this is a summary: If then is not applied (because it could be an indication of a nonblock fs, or error) Done is provided if fstype is invalid Done if fstype is valid and then apply fsgroup logic else ignore fsGroup Done
- any updates on ?
Waiting for a review and approval.
you have a outstanding comment on the PR. Can you please answer that?
How does this approach relate to inline CSI volumes? There's no PersistentVolume involved, and hence no way to specify an access mode. , but my driver ignores it (always using tmpfs). I considered having my CSI driver read the mounting pod's spec to see if it has a security context with "fsGroup" set, since that detail is not supplied to the driver, as . My goal is to have the volume mounted with the files on it readable by the container's user, but there's no way for my driver to know who that user will be. Am I supposed to just use 0444 for the ownership bits, to allow everyone to read the files?
Code change:
resources: {} terminationMessagePath: "/dev/termination-log" imagePullPolicy: IfNotPresent <del> capabilities: {} </del> securityContext: capabilities: {} privileged: false

Related discussion:
text: Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Vagrant OS (e.g. from /etc/os-release): CoreOS Kernel (e.g. ):Install tools: Vagrant & Others: What happened: What you expected to happen: Success How to reproduce it (as minimally and precisely as possible): Followed instructions at Tried to run Received: Anything else do we need to know: From googling, it seems several of the fields in the config are for when using OpenShift origin. But creating the replication controller is a prerequisite to launching OpenShift Origin. Chicken & egg problem.
Code change:
} } if len(unknownLabels) > 0 { <del> // TODO(liggitt): in 1.16, return an error klog.Warningf("unknown 'kubernetes.io' or 'k8s.io' labels specified with --node-labels: %v", unknownLabels.List()) klog.Warningf("in 1.16, --node-labels in the 'kubernetes.io' namespace must begin with an allowed prefix (%s) or be in the specifically allowed set (%s)", strings.Join(kubeletapis.KubeletLabelNamespaces(), ", "), strings.Join(kubeletapis.KubeletLabels(), ", ")) </del> <ins> return fmt.Errorf("unknown 'kubernetes.io' or 'k8s.io' labels specified with --node-labels: %vn--node-labels in the 'kubernetes.io' namespace must begin with an allowed prefix (%s) or be in the specifically allowed set (%s)", unknownLabels.List(), strings.Join(kubeletapis.KubeletLabelNamespaces(), ", "), strings.Join(kubeletapis.KubeletLabels(), ", ")) </ins> } return nil

Related discussion:
text: xref In 1.16: change the metadata-proxy addon to use change the kube-proxy addon to use change the masq-agent addon to use stop setting , , and in kube-up
Hey I'm trying to start to contribute to kubernetes and this seem to be an easy task. Can I help with this one?
Code change:
ginkgo.By("updating the pod") podClient.Update(pod.ObjectMeta.Name, func(pod *v1.Pod) { <del> pod.ObjectMeta.Annotations = map[string]string{"mysubpath": "mypath"} </del> <ins> if pod.ObjectMeta.Annotations == nil { pod.ObjectMeta.Annotations = make(map[string]string) } pod.ObjectMeta.Annotations["mysubpath"] = "mypath" </ins> }) ginkgo.By("waiting for pod running")

Related discussion:
text: In our Tanzu Supervisor Cluster k8s setup, we observe that the "should verify that a failing subpath expansion can be modified during the lifecycle of a container" conformance test fails. The root-cause seems to be that the test is updating the pod annotations, thereby resulting in removing the other annotations present in the pod object. Removing the custom annotations that we use causes the test to fail during pod deletion. Should this test perhaps use Patch instead of Update so that the annotations are merged and not replaced? Thanks ginkgo.By("updating the pod") podClient.Update(pod.ObjectMeta.Name, func(pod *v1.Pod) { pod.ObjectMeta.Annotations = map[string]string{"mysubpath": "mypath"} })
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 storage /sig conformance I personally agree that it should not remove existing annotations, but better ask the test owners
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig storage /sig conformance I personally agree that it should not remove existing annotations, but better ask the test owners 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
May I request the original author to weigh in on this? Thank you.
I dont have any issues with the code change to a merge but what would bother me is that conformance tests are being altered by outside influences which doesnt seem particularly right. I think this would be for the sig storage owners to decide
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