jiebi/CodeConvo huggingface dataset:
Code change:
return err } var ok bool <ins> // Handle filename input from stdin. The resource builder always returns an api.List // when creating resource(s) from a stream. if list, ok := obj.(*api.List); ok { if len(list.Items) > 1 { return cmdutil.UsageError(cmd, "%s specifies multiple items", filename) } obj = list.Items[0] } </ins> newRc, ok = obj.(*api.ReplicationController) if !ok { if _, kind, err := typer.ObjectVersionAndKind(obj); err == nil {

Related discussion:
text: attemting to run throws and error with ERROR: Error: - does not specify a valid ReplicationController
The documentation is a little ambiguous, as the second example suggests that - should work but the Synopsis section does not. Could you either fix the documentation or the command?
Calvin, can you post the contents of , and the schema of the original rc? There are some for the schema when providing a target from file, which may not be met.
running works, I was interpreting the error message that it though - was a rc
will work for any object schema file. I.e, that is the same command you use to create a podreplicationcontroller from file. The type being created is determined by the contents of the file. Looking back at the code, the error you saw indicates that does not contain a replicationcontroller spec. If you can create it, that must mean it's something else; can you post/link the contents?
yes I need to clean it up first
That looks like a valid rc spec, but the labels may be insufficient for rollingupdate. In order to do a rollingupdate you need to have a label to control the update. Typically this would be a "version" label. Example Basically the selector for the old and new rc must share at least one label key with a differing value. By the way, rollingupdate is currently getting a simplified version, which generates the new rc spec for you. This is wip that will be available in next week's GKE release. See
ah I see, I actually have a dynamic version in there so that will be easy to do thanks Jeff Lowdermilk wrote:
so with an updated config still does not work while does work with the first one still erroring out with so likely my missing selector issue was an unrelated issue
From your last comment, seems this is resolved. If you are still having trouble, lmk and I will reopen.
still not fixed because I can't do
I'm pretty sure that's a piping issue with the wrapper command that likely doesn't occur if you use kubectl directly. Try Note that steps 1,2 will be unnecessary with the next gcloud release; you will be able to use kubectl directly after creating a cluster.
With cloudsdk 0.9.60, standalone kubectl works by default with GKE clusters.
Code change:
return err } var ok bool <ins> // Handle filename input from stdin. The resource builder always returns an api.List // when creating resource(s) from a stream. if list, ok := obj.(*api.List); ok { if len(list.Items) > 1 { return cmdutil.UsageError(cmd, "%s specifies multiple items", filename) } obj = list.Items[0] } </ins> newRc, ok = obj.(*api.ReplicationController) if !ok { if _, kind, err := typer.ObjectVersionAndKind(obj); err == nil {

Related discussion:
text: The wrapper command is no longer needed and will be removed in a future release. Let me know if you have problems running against a GKE cluster.
I am running across this issue with a recent build of .
is still throwing errors with version 0.17 used directly (without wrapping)
Code change:
roleRef: kind: Role name: external-provisioner-cfg <ins> apiGroup: rbac.authorization.k8s.io </ins>

Related discussion:
text: xref: When running the GCE PD CSI Driver against all dynamic provisioning tests from this PR: We encounter the following test failures that need to be resolved: /kind bug /sig storage /cc
So it seems that the flag is getting passed all the way through to the driver and it is behaving as we would expect it to in terms of mounting. All the correct commands are being run: When exec-ing into the gce-pd-driver container we can observe that the mounted point is indeed read only. However, when viewed from the host node's perspective the mount is still read write. And therefore since the subpath folder is created by the host, the folder is still being created successfully which fails the test. This behavior suggests that is either not properly propagating the read only option on remount, or not properly remounting at all. I can't figure out how to "view mount events" if that's even possible, some help would be appreciated if anyone is aware of how to do that. That would help me narrrow down which of those two options is happening. I have also attempted (from inside the gce pd driver container) to unmount the point (successful) and bind mount it back with the readonly option directly (not using remount trick, still unsuccessful). Suggesting that maybe it is the that is not being mount propagated and not a problem with in particular. /cc
/assign
/milestone v1.13 /priority important-soon
Code change:
webhook_authn_config_volume="{"name": "webhookauthnconfigmount","hostPath": {"path": "/etc/gcp_authn.config"}}," fi <del> params+=" --authorization-mode=ABAC" </del> <ins> params+=" --authorization-mode=RBAC" </ins> local webhook_config_mount="" local webhook_config_volume="" if [[ -n "${GCP_AUTHZ_URL:-}" ]]; then

Related discussion:
text: Typically, the dns and dashboard is in crash loop. Ref cc
if you check the file, does it contain lines like ?
Previous comment is ref: from I'll copy that to container-linux as well.
Code change:
} func TestList(t *testing.T) { <ins> scheme := NewTestScheme() metav1.AddMetaToScheme(scheme) </ins> client := NewSimpleMetadataClient(scheme, newPartialObjectMetadata("group/version", "TheKind", "ns-foo", "name-foo"), newPartialObjectMetadata("group2/version", "TheKind", "ns-foo", "name2-foo"),

Related discussion:
text: Because of this scheme mutation, this leads to concurrent use of the same scheme to cause the program to panic. It would be ideal to do this in some concurrent safe manner or add a warning or similar
/sig api-machinery
/assign
/assign /triage accepted
Code change:
if err != nil { t.Errorf("test case %s failed: %v", tc.name, err) } <ins> watchError := tc.watcherError csiAttacher.waitSleepTime = 100 * time.Millisecond </ins> go func() { <ins> if watchError { errStatus := apierrs.NewInternalError(fmt.Errorf("we got an error")).Status() fakeWatcher.Error(&errStatus) return } </ins> fakeWatcher.Delete(attachment) }() err = csiAttacher.Detach(volumeName, types.NodeName(nodeName))

Related discussion:
text: A CSI plugin that the 1.10 controller manager can't detect (which could occur in a number of scenarios, such as when a rollout is being performed or a node is evacuated) seems to retry without backoff. In this case, I have a pod referencing a PVC -PV that references my CSI plugin, but no controller plugin running. The controller is probing every 100ms continuously for a single volume attachment. The controller should backoff. Have not tested with higher numbers of pods, but in a busy system this could cause the controller manager to burn CPU. Also, there isn't actually a great error telling the user why the probing is happening (I knew in this case, but an admin likely has no idea).
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /milestone v1.14 adding it to next milestone as per if it doesn't make it then it can be further moved
as KEP has been moved, unless an exception is made, /milestone v1.15
the linked kep above is unrelated to this issue. This is a bug and I don't think it needs an associated enhancement
sorry, got diverted by the comments on that KEP. /milestone v1.14
Hello from Bug Triage Shadow . I'd like to remind that code freeze is coming in 3 days (Friday, 8th March). Is this still planned to be fixed for 1.14?
We have not been tracking this for 1.14. /assign can you help triage and see if this is still an issue and if there is a quick fix?
I can't reproduce the issue, do you remember what you did? From the logs it seems that Watch channel consistently returns so new is called recursively (beware, 1.10 code, but it's very similar in master): Can it produce fairly stable 100ms delay between calls? Anyway, this is not usual code path, watcher does not return in most cases.
Code change:
if err != nil { t.Errorf("test case %s failed: %v", tc.name, err) } <ins> watchError := tc.watcherError csiAttacher.waitSleepTime = 100 * time.Millisecond </ins> go func() { <ins> if watchError { errStatus := apierrs.NewInternalError(fmt.Errorf("we got an error")).Status() fakeWatcher.Error(&errStatus) return } </ins> fakeWatcher.Delete(attachment) }() err = csiAttacher.Detach(volumeName, types.NodeName(nodeName))

Related discussion:
text: if I read the code correctly, such recursive must end up with timeout - caller does not care about return value and caller's watch probably won't return anything useful. Is there a reason why we don't return error? This will kick in exponential backoff in A/D controller.
clearing the milestone for tracking purposes to let the fix land in its own time /milestone clear
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
I found the error would happen when a pv is attahing(volumeattachment has created) and the csi-attacher is deleted at the same time. Then the log would print so frequently (because of recursion).
is this fixed by ?
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
Code change:
var watcher *fsnotify.Watcher var parse parseFunc var stop bool <ins> isNewLine := true </ins> found := true writer := newLogWriter(stdout, stderr, opts) msg := &logMessage{}

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! If the matter is security related, please disclose it privately via --What happened: Docker has a hardcoded 16K limit on log line length, which splits lines longer than that into multiple messages in the log file. in , however, doesn't account for this when is set to and prints the timestamp in front of every entry in the log file instead of every logical line. This leads to random timestamps appearing in the middle of log lines, potentially breaking the applications that parse these logs. What you expected to happen: inserts timestamps once per logical line, so original log data is preserved. Alternatively, allow API to request the logs in a sane format like JSON, which would allow merging the lines back and combining them with the timestamps more intelligently on the application side. How to reproduce it (as minimally and precisely as possible): Create : apiVersion: v1 kind: Pod metadata: name: log-lines spec: containers: name: main image: busybox command: ['sh', '-c', 'while sleep 1; do echo -n ; for i in $(seq 1 ); do echo -n A; done; echo ; done'] Start the pod with Fetch the logs with , or using the API () Observe random timestamps inserted in the middle of the log lines. Environment: Kubernetes version (use ):
Reiterating the mentions to trigger a notification: <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
I will work on it. /sig cli /remove-sig node
The logs are being corrupted by the API endpoint in kubelet, so shouldn't it be in scope of SIG node?
The log is not corrupted by k8s. The same log could be got using "docker container logs -t CONTAINERID" I think you should post your requirement to Docker.
Code change:
var watcher *fsnotify.Watcher var parse parseFunc var stop bool <ins> isNewLine := true </ins> found := true writer := newLogWriter(stdout, stderr, opts) msg := &logMessage{}

Related discussion:
text: Please refer following code Line 50 ~ 52 if config.Timestamps { logLine = append([]byte(msg.Timestamp.Format(jsonmessage.RFC3339NanoFixed)+" "), logLine...) }
kubelet doesn't rely on Docker when reading logs, it reads the files itself (see the code linked in the issue). I don't think Docker would change the forced line splitting (see for example), so this should be fixed in Kubernetes.
Your are right and kubelet read log file from host such as /var/log/pods/pods/NAMESPACEPOD-NAMExxx/....(JSON format) I will post a PR for it. /remove-sig cli /sig node
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
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
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
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
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 .
Code change:
var watcher *fsnotify.Watcher var parse parseFunc var stop bool <ins> isNewLine := true </ins> found := true writer := newLogWriter(stdout, stderr, opts) msg := &logMessage{}

Related discussion:
text: Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
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
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-contributor-experience at . /lifecycle rotten
I saw the attempt fixing this but it was scary (echo this comment: ). I suggested a way it may be improved. Also the proposed fix didn't introduce any e2e tests to validate that runtime behavior is not changed and runtimes keep the no-newline-on-splitted-log logic. are you or anybody on this thread are still interested to work on this? Please re-open if so. Meanwhile closing this ahead of bot doing it because the inactivity. /close
Closing this issue. <detailsIn response to : I saw the attempt fixing this but it was scary (echo this comment: ). I suggested a way it may be improved. Also the proposed fix didn't introduce any e2e tests to validate that runtime behavior is not changed and runtimes keep the no-newline-on-splitted-log logic. Instructions for interacting with me using PR comments are available .
Code change:
var watcher *fsnotify.Watcher var parse parseFunc var stop bool <ins> isNewLine := true </ins> found := true writer := newLogWriter(stdout, stderr, opts) msg := &logMessage{}

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:
var watcher *fsnotify.Watcher var parse parseFunc var stop bool <ins> isNewLine := true </ins> found := true writer := newLogWriter(stdout, stderr, opts) msg := &logMessage{}

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:
var watcher *fsnotify.Watcher var parse parseFunc var stop bool <ins> isNewLine := true </ins> found := true writer := newLogWriter(stdout, stderr, opts) msg := &logMessage{}

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.