Currently type references for non-local names are output as relative
types which is subject to the resolution rules as defined at
https://protobuf.com/docs/language-spec#reference-resolution
This works fine within the k8s.io namespace where no subpackages are
named k8s, but other users of go-to-protobuf likely have k8s in their
package name. This causes conflicts in the search resolution when
executing `go-to-protobuf`:
```
company.example.com/k8s/custom/pkg/apis/custom.k8s.example.com/v1/generated.proto:64:12: "k8s.io.apimachinery.pkg.apis.meta.v1.ListMeta" is resolved to "company.example.com.k8s.custom.pkg.apis.custom.k8s.io.apimachinery.pkg.apis.meta.v1.ListMeta", which is not defined. The innermost scope is searched first in name resolution. Consider using a leading '.'(i.e., ".k8s.io.apimachinery.pkg.apis.meta.v1.ListMeta") to start from the outermost scope.
```
To avoid this we can output fully qualified type references using a
preceding dot (.)
This results in a change for k8s generated.proto files, but the
effect is a noop.
Fixeskubernetes/code-generator#147
Signed-off-by: Andrew DeMaria <ademaria@cloudflare.com>
In contrast to the original HandleError and HandleCrash, the new
HandleErrorWithContext and HandleCrashWithContext functions properly do contextual
logging, so if a problem occurs while e.g. dealing with a certain request and
WithValues was used for that request, then the error log entry will also
contain information about it.
The output changes from unstructured to structured, which might be a breaking
change for users who grep for panics. Care was taken to format panics
as similar as possible to the original output.
For errors, a message string gets added. There was none before, which made it
impossible to find all error output coming from HandleError.
Keeping HandleError and HandleCrash around without deprecating while changing
the signature of callbacks is a compromise between not breaking existing code
and not adding too many special cases that need to be supported. There is some
code which uses PanicHandlers or ErrorHandlers, but less than code that uses
the Handle* calls.
In Kubernetes, we want to replace the calls. logcheck warns about them in code
which is supposed to be contextual. The steps towards that are:
- add TODO remarks as reminder (this commit)
- locally remove " TODO(pohly): " to enable the check with `//logcheck:context`,
merge fixes for linter warnings
- once there are none, remove the TODO to enable the check permanently
Currently, there are some unit tests that are failing on
Windows due to various reasons:
- time.Now() is not as precise on Windows, which means that
2 consecutive calls may return the same timestamp.
- Different "File not found" error messages on Windows.
- The default Container Runtime URL scheme on Windows is npipe, not unix.
The default queue implementation is mostly FIFO and it is not
exchangeable unless we implement the whole `workqueue.Interface` which
is less desirable as we have to duplicate a lot of code. There was one
attempt done in [kubernetes/kubernetes#109349][1] which tried to
implement a priority queue. That is really useful and [knative/pkg][2]
implemented something called two-lane-queue. While two lane queue is
great, but isn't perfect since a full slow queue can still slow down
items in fast queue.
This change proposes a swappable queue implementation while not adding
extra maintenance effort in kubernetes community. We are happy to
maintain our own queue implementation (similar to two-lane-queue) in
downstream.
[1]: https://github.com/kubernetes/kubernetes/pull/109349
[2]: https://github.com/knative/pkg/blob/main/controller/two_lane_queue.go
Fixed `The phase of Pod e2e-test-pod is Succeeded which is unexpected`
error. `e2epod.NewPodClient(f).CreateSync` is unable to catch 'Running'
status of the pod as pod finishes too fast.
Using `Create` API should solve the issue as it doesn't query pod
status.
