jiebi/CodeConvo huggingface dataset:
Change:
./cmd/libs/go2idl/conversion-gen                   | grep "^$(PRJ_SRC_PATH)"                          | xargs go list -e -f '{{.Dir}} {{.Dir}}/*.go');   <del> echo $$DIRECT $$INDIRECT | sed 's/ / nt/g';        </del> <ins> echo $$DIRECT $$INDIRECT | sed 's/ / =,/g' | tr '=,' 'nt';  </ins> ) | sed "s|$$(pwd -P)/||" > $@.tmp;                     cmp -s $@.tmp $@ || cat $@.tmp > $@ && rm -f $@.tmp

Discussion:
I don't know where the at the beginning of the target comes from, but probably from assumptions about sed version that are wrong. I had to update to gnu-sed 4.2.2 to build.
Also ootb on a Mac doesn't work with the rules specified (on el capitan):
does work
I take it back - updating sed did not appear to work. EDIT: I take that back, I had to clean after fixing paste.
most recent OSX version is UNIX certified, a POSIX requires as file argument when reading input from stdin. For , is only guaranteed to work in GNU sed, you need to insert literal newline and tab character there for portability.
Can someone with a mac send a patch? I don't have a mac...
It's update and every should end in instead of having no arguments. , Tim Hockin wrote:
(user should update sed, make needs changes to paste) , Clayton Coleman wrote:
I think we should stick to portable way for , it's too risky for relying on GNUism. If you don't mind, I will make a PR.
Sure, thanks , Cuong Manh Le wrote:
Are you sure the worked? I pull the latest from master, then run the same command above, I got: File is empty.
Make sure you are in your GOPATH in the correct spot for Kube On Jul 14, 2016, at 2:47 AM, Cuong Manh Le wrote: Are you sure the Makefile worked? I pull the latest from master, then run the same command above, I got: F0714 13:36:50. ] Error: Failed making a parser: unable to add directory "": unable to import "": expected 'package', found 'EOF' make: * [Makefile.generatedfiles:201: gendeepcopy] Error 255 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
If you get the "expected 'package', found 'EOF'" message it is usually because something somewhere failed, and left an empty .go file. make cleangenerated , Cuong Manh Le wrote:
From BSD sed man page: Maybe try that?
It's not about ERE ( enables it), it's about expanding escape sequences in RHS of search and replace .
Change:
CSINodeInfo:                    {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.19 BlockVolume:                    {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.20 StorageObjectInUseProtection:   {Default: true, PreRelease: featuregate.GA}, <del> SupportIPVSProxyMode:           {Default: true, PreRelease: featuregate.GA}, </del> SupportPodPidsLimit:            {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.21 SupportNodePidsLimit:           {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.21 HyperVContainer:                {Default: false, PreRelease: featuregate.Alpha},

Discussion:
When should it be removed? /sig network /kind cleanup
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
Feature is GA since 1.11 - Any reference to this Feature Gate needs to be removed from the code, README and Docs: If you're a new contributor, please step in, take this issue, make the PRs, assign it to me with /assign and I'll be glad to help you through the journey of contributing :) /good-first-issue /help
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 : Feature is GA since 1.11 - /help 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
/assign
are you willing to take this one?
Yes. I'm a new contributor.I will to try to complete it.
/assign Welcome! Let me know if you need any kind of help. Please take a look also into the Kubernetes Contributors documentation - When you're ready to create your first PR, please assign it to me and I'll make the first pass!
/sig docs We don't remove GA feature gates from the website; we move them to
Change:
allErrs = append(allErrs, ValidateImmutableField(service.Spec.ClusterIP, oldService.Spec.ClusterIP, field.NewPath("spec", "clusterIP"))...) } <ins> // TODO(freehan): allow user to update loadbalancerSourceRanges allErrs = append(allErrs, ValidateImmutableField(service.Spec.LoadBalancerSourceRanges, oldService.Spec.LoadBalancerSourceRanges, field.NewPath("spec", "loadBalancerSourceRanges"))...) </ins> allErrs = append(allErrs, ValidateService(service)...) return allErrs }

Discussion:
a service, type LoadBalancer. that and add a field with a value that the iptables rules do not appear It does seem that the GCE firewall rule is created. patch?
Is this a regression?
No. This has never been "right" as far as I can tell. , Phillip Wittrock wrote:
can this be closed now?
Nope. The root cause has not been fixed yet.
Change:
ID:   "bar", }, }, <del> NewConflictErr("foo", "bar", errors.New("failure")): api.Status{ </del> <ins> NewConflictErr("foo", "bar", errors.New("failure")): { </ins> Status:  api.StatusFailure, Code:    http.StatusConflict, Reason:  "conflict",

Discussion:
https://travis- Seems surprising-- I will look into it later if no one else does first.
Got another flake. Looking into it.
Change:
} } <del> func waitForDetachAndGrabMetrics(oldMetrics *storageControllerMetrics, metricsGrabber *metrics.Grabber) *storageControllerMetrics { </del> <ins> func waitForDetachAndGrabMetrics(oldMetrics *storageControllerMetrics, metricsGrabber *metrics.Grabber, pluginName string) *storageControllerMetrics { </ins> backoff := wait.Backoff{ Duration: 10 * time.Second, Factor:   1.2,

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:
package create import ( <ins> "strconv" </ins> "testing" rbac "k8s.io/api/rbac/v1"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which test(s) are failing: Since when has it been failing: since upgrading golang: Reason for failure: Since Go 1.15, type casting from int to string using is not allowed, output: Anything else we need to know: related links: golang/go golang/go
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
the fix should be straight forward, so I can create a pull request to fix this. /sig testing /sig cli /assign
/assign
Change:
} type rbd struct { <del> volName  string podUID   types.UID mon      []string pool     string id       string image    string keyring  string secret   string </del> <ins> volName string podUID  types.UID // capitalized so they can be exported in persistRBD() Mon      []string Pool     string Id       string Image    string Keyring  string Secret   string </ins> fsType   string <del> readOnly bool </del> <ins> ReadOnly bool </ins> plugin   *rbdPlugin mounter  mount.Interface // Utility interface that provides API calls to the provider to attach/detach disks.

Discussion:
etcd cluster backing apiserver died spontaneously, after restart apiserver pulled up the pods on different machines. Node storage was backed by ext4 over rbd, which became mounted on several nodes at once. That could have possibly led to data corruption. I guess that the proper way to mount rbd volume is to take a lock on it first, which will at least fail if it's locked somewhere else, requiring manual intervention, but not destroying data. The lock should be optional, in case a proper cluster fs is mounted over the rbd. In this case there was clearly no need for accessing the data from several pods so ext4 is deemed a proper fs.
, Vladimir Pouzanov < :
want to get some detail. How is your pod-to-rbd mapping like? Since rbd image is a block device, it can be used by one pod at a time. I am not sure if locking is a proper way to go - if the pod holds a lock but dies in the middle of mounting, the rbd image (or any other volume type) is then excluded from access. In such case, a high level coordination at apiserver is a better place to resolve this problem.
Here's my rc: I guess it's better to have a lock to be cleaned up manually rather than to have non-cluster fs to be mounted in several locations at once?
thanks, this pod looks good to me. what would cause multiple nodes run the same pod?
I don't know the exact reason of why kubelet didn't unmount the old fs, but after apiserver and scheduler were restarted pod got allocated on different node.
It is a scary thing to see etcd down, it is meant to be reliable...
Unfortunately I don't have long-term logging in test cluster so I have no idea why it actually died. but using kubedns as primary node resolver was clearly a bad idea, once it died, nodes stuck with no resolver at all.
your thought on HA?
Wrong Tim St. Clair?
- you HAVE to be ready to handle network partitions - the old node might still be alive and even using the volume, but the apiserver can't see the node, so it thinks it deletes the pod and starts it elsewhere. If RBD corrupts itslef in this case, it is not useful and we should strip it from the codebase.

, Huamin Chen wrote:
that makes sense. rbd doesn't corrupt itself. This is inconsistency happens when you have two pods mounting the same rbd image. How does GCE PD handle/prevent this case?
It doesn't allow more than one read-write attachment. Multiple read-only attachments is OK. Better to fail than to allow corruption. , Huamin Chen wrote:
That's neat. I have a lock fencing for rbd, testing now.
Change:
if err != nil { t.Fatalf("Unexpected error: %v", err) } <del> c.Convert(&Foo{}, &Bar{}, 0, nil) </del> <ins> err = c.Convert(&Foo{}, &Bar{}, AllowDifferentFieldTypeNames, nil) if err != nil { t.Fatalf("Unexpected error: %v", err) } </ins> } func TestConverter_meta(t *testing.T) {

Discussion:
In Go you cannot take the address of a because the map implementation hides that from you. Our conversion library assumes that any reflected map value can have Addr() taken, which causes a panic when you try to do the following for PodInfo conversion: The conversion code tries to call Addr() on the reflect.Value (the map's value, ContainerStatus value object) which fails because it cannot have an address. I worked around it by registering a conversion function on *PodInfo and then manually converting the map.
Oh you mean the reflection code can't addr that? ok sounds like a bug. Non-reflection code can certainly do it:
That playground is taking the address of a value before it's in the struct. You can't take the address of m ----- Original Message -----
Right, because go does magical c++ style references there. But I thought the map copying code handled that case specially already?
I think I see what you're talking about. I'll make a test.
I repro'd. Will fix.
It was actually the source value that caused the trouble. Thanks for the report!
Sorry, should have been clearer. ----- Original Message -----
Note that this map violates our API conventions. It should be a list of named subobjects.
Yeah this field has always been problematic. It's still a bug regardless-- could have triggered copying other maps.
Change:
// Move the old manifest into the old-manifests directory if err := pathMgr.MoveFile(currentManifestPath, backupManifestPath); err != nil { <del> return rollbackOldManifests(recoverManifests, err, pathMgr) </del> <ins> return rollbackOldManifests(recoverManifests, err, pathMgr, recoverEtcd) </ins> } // Move the new manifest into the manifests directory if err := pathMgr.MoveFile(newManifestPath, currentManifestPath); err != nil { <del> return rollbackOldManifests(recoverManifests, err, pathMgr) </del> <ins> return rollbackOldManifests(recoverManifests, err, pathMgr, recoverEtcd) </ins> } fmt.Printf("[upgrade/staticpods] Moved upgraded manifest to %q and backed up old manifest to %qn", currentManifestPath, backupManifestPath)

Discussion:
kubeadm etcd upgrade modifying recovery steps /assign /sig cluster-lifecycle /kind bug
Change:
} func (rc *resourceMetricsCollector) collectPodCPUMetrics(ch chan<- metrics.Metric, pod summary.PodStats) { <del> if pod.CPU == nil { </del> <ins> if pod.CPU == nil || pod.CPU.UsageCoreNanoSeconds == nil { </ins> return }

Discussion:
kubelet panic when accessing metrics/resource endpoint kubelet log kubelet works fine access metrics/resource endpoint of kubelet No response <details</details<details</details<details</details<details</details<detailsINFO[2022-07-14 05:36:21.474173892Z] Starting CRI-O, version: 1.23.0, git: (dirty) Version: 1.23.0 GitCommit: GitTreeState: dirty BuildDate: 1980-01-01T00:00:00Z GoVersion: go1.17.4 Compiler: gc Platform: linux/amd64 Linkmode: static BuildTags: apparmor, excludegraphdriverdevicemapper, seccomp, selinux SeccompEnabled: true AppArmorEnabled: true </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
/assign
/sig node
Change:
} func (i *internalContainerLifecycleImpl) PreStartContainer(pod *v1.Pod, container *v1.Container, containerID string) error { <del> if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.CPUManager) { </del> <ins> if i.cpuManager != nil { </ins> err := i.cpuManager.AddContainer(pod, container, containerID) if err != nil { return err

Discussion:
Recently merged PR () broke clusters brought up with only GA APIs+features. See conformance test at /sig node /priority critical-urgent /kind bug /milestone v1.18 /assign
Change:
time.Sleep(tt.sleep) actualErr := ctx.Err() actualCause := context.Cause(ctx) <del> assert.Equal(t, tt.expectErr, actualErr, "ctx.Err()") assert.Equal(t, tt.expectCause, actualCause, "context.Cause()") </del> <ins> ci, _ := os.LookupEnv("CI") switch strings.ToLower(ci) { case "yes", "true", "1": // Skip. default: assert.Equal(t, tt.expectErr, actualErr, "ctx.Err()") assert.Equal(t, tt.expectCause, actualCause, "context.Cause()") } </ins> }) } }

Discussion:
We observed this recently. Steps to reproduce: clone kubernetes test ./test/utils/ktesting -c -race /root/go/bin/stress - TestCause /sig
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 testing even after , we see this flakiness. This is easily reproducible in our local machines.
See Yes, it only reduced the flaking rate IMO. It still flakes in /cc
/milestone v1.30 Does fix the flake?
This still occurs after The change above is only skipping the Test for cases where . But this failure is occurring at a different stage while comparing expectErr and actualErr at Hence this change would fix it. Can you PTAL?
Change:
"github.com/onsi/gomega" ) <ins> type watchEventConfig struct { framework           *framework.Framework resourceVersion     string w                   *cache.ListWatch jobName             string watchEvent          watch.EventType extJob              *batchv1.Job updatedMetadataType string updatedKey          string updatedValue        string } </ins> var _ = SIGDescribe("Job", func() { f := framework.NewDefaultFramework("job") parallelism := int32(2)

Discussion:
[x] Test approval issue : [x] Test PR : - Needed an update on the handling of anotations 27 March 2022 [x] Two weeks soak end date : 6 April 2022 [x] Test promotion PR : [x] Update Test PR: 15 April 2022 [x] Two weeks soak end date : 4 May 2022 with start of 1.25 [x] Update Test Promotion: According to these APIsnoop queries, there are still four remaining Job endpoints which are untested. Using a number of existing e2e test practices a new has been created for this job lifecycle test. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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
/reopen for tracking e2e testgrid and promotion PR
/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:
return r } <del> // URL returns the current working URL. </del> <ins> // Error returns any error encountered constructing the request, if any. func (r *Request) Error() error { return r.err } // URL returns the current working URL. Check the result of Error() to ensure // that the returned URL is valid. </ins> func (r *Request) URL() *url.URL { p := r.pathPrefix if r.namespaceSet && len(r.namespace) > 0 {

Discussion:
When constructing a , e.g. to stream I/O from a pod: if ends up set, will still return a result without indicating that something went wrong, resulting in a misleading error further down the line. (In my case, I wasn’t providing the correct scheme; the parameters therefore couldn’t be encoded, and the SPDY upgrade failed with an error saying that at least one of stdin, stdout or stderr had to be provided.) Other operations on fails as appropriate if is not ; I would expect to do so too. I realise that means a backwards-incompatible change. Another solution could be to provide a (same as on the response). See above, with any scheme other than client-go’s. No response <details</detailsN/A N/A N/A N/A N/A
this is the same as standard library, the url is not validated when creating the request
is it really the same though? In the case which led to my filing this issue, the call to results in an error, which is recorded in , but the caller has no way to know that. The main issue I have with this is that in most code paths, does end up being returned, e.g. calls to etc. But callers using only have no way of knowing that the URL they get is unusable.
I didn't understand that from the description sorry I see what you mean now, the methods that execute the request return the error, but if you want to reuse the request instead of executing it, you can't know that value until it is executed IMHO is a legit demand to use a getter for Error(), the field is there but not accessible , WDYT?
/sig api-machinery
a Request#Error() getter seems reasonable
/triage accepted
Change:
import ( "flag" "math/rand" <ins> "os" </ins> "os/exec" "time"

Discussion:
When using or with a key/value that has a multi-line string as value, that value will appear as quoted string in the log message, i.e. the log message will still be a single line. It would be nicer to print the value in text mode so that it goes across multiple lines, with clear indicators for start and end of the value. Indention could be used to avoid mistaking some embedded line as the start of a new log message. In JSON mode, the value should be formatted normally. /sig instrumentation /wg structured-logging Always printing as a single line can can make the log output unreadable ().
When adding something like this, can be reverted and implemented differently.
My original thinking was that only objects that explicitly ask for multi-line output get formatted that way. But that means that we need to review log calls very carefully. An alternative is to automatically switch from quoting strings to multi-line output based on some heuristic, for example when there's more than one line break.
Here's a potential implementation:
If structured logging is needed in any other case I can contribute, please inform if needed.
/triage accepted /assign /priority important-soon /area logging /cc /cc
We have the same problem as in kube-scheduler also in kubelet, it's just that no-one has seen and/or complained about the multi-line strings. With the benchmark + log analysis tool from I found the following multi-line string parameters in a kubelet log: <details</details