This requires dropping otel down to v0.20 because the apiserver package
is importing it and some packages moved around with otel v1.
Even k8s v0.25 still uses this old version of otel, so we are stuck for
a bit (v0.26 will, as of now, use a newer otel version).
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Changes in klog and logr have made automatic bumps from dependabot
problematic.
We also shouldn't need klogv1 so removed that.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Auth is not automatically enabled because this requires some
bootstrapping to work.
I'll leave this for some future work.
In the meantime people can use the current code similar to how they used
the node-cli code to inject their own auth.
These are mostly helper code for setting up env vars. There is a single
file copied verbatim, although much of this downward api stuff is a
copy. We may want to pull this out and do a direct copy of the the code
so it is easier to update and work with upstream to have a shared
package that lives outside of k8s.io/kubernetes for downward api.
This is a fundamentally different API than that of the K8s workqueue
which is better suited for our needs. Specifically, we need a simple
queue which doesn't have complex features like delayed adds that
sit on "external" goroutines.
In addition, we need deep introspection into the operations of the
workqueue. Although you can get this on top of the K8s workqueue
by implementing a custom rate limiter, the problem is that
the underlying rate limiter's behaviour is still somewhat
opaque.
This basically has 100% code coverage.
This refactor is a preparation for another commit. I want to add instrumentation
around our queues. The code of how queues were handled was spread throughout
the code base, and that made adding such instrumentation nice and complicated.
This centralizes the queue management logic in queue.go, and only requires
the user to provide a (custom) rate limiter, if they want to, a name,
and a handler.
The lease code is moved into its own package to simplify testing, because
the goroutine leak tester was triggering incorrectly if other tests
were running, and it was measuring leaks from those tests.
This also identified buggy behaviour:
wq := workqueue.NewNamedRateLimitingQueue(workqueue.DefaultItemBasedRateLimiter(), "test")
wq.AddRateLimited("hi")
fmt.Printf("Added hi, len: %d\n", wq.Len())
wq.Forget("hi")
fmt.Printf("Forgot hi, len: %d\n", wq.Len())
wq.Done("hi")
fmt.Printf("Done hi, len: %d\n", wq.Len())
---
Prints all 0s because event non-delayed items are delayed. If you call Add
directly, then the last line prints a len of 2.
// Workqueue docs:
// Forget indicates that an item is finished being retried. Doesn't matter whether it's for perm failing
// or for success, we'll stop the rate limiter from tracking it. This only clears the `rateLimiter`, you
// still have to call `Done` on the queue.
^----- Even this seems untrue
I know it's not an impressive test. It just brings up a node, and
makes sure it registers. Let's do more in the future.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
* Rename VK to chewong for development purpose
* Rename basic_test.go to basic.go
* Add e2e.go and suite.go
* Disable tests in node.go
* End to end tests are now importable as a testing suite
* Remove 'test' from test files
* Add documentations
* Rename chewong back to virtual-kubelet
* Change 'Testing Suite' to 'Test Suite'
* Add the ability to skip certain testss
* Add unit tests for suite.go
* Add README.md for importable e2e test suite
* VK implementation has to be based on VK v1.0.0
* Stricter checks on validating test functions
* Move certain files back to internal folder
* Add WatchTimeout as a config field
* Add slight modifications
This moves to a model where any time that pods are given to a
provider, it uses a DeepCopy, as opposed to a reference. If the
provider mutates the pod, it prevents it from causing issues
with the informer cache.
It has to use reflect instead of comparing the hashes because
spew prints DeepCopy'd data structures ever so slightly differently.
* Upgrade k8s.io/api
go get k8s.io/api@kubernetes-1.15.2
* Upgrade k8s.io/apimachinery
go get k8s.io/apimachinery@kubernetes-1.15.2
* Upgrade kubernetes-1.15.2
go get k8s.io/client-go@kubernetes-1.15.2
* Upgrade kk8s.io/kubernetes to v1.15.2
go get k8s.io/kubernetes@v1.15.2
This also locks the the dependency for
github.com/prometheus/client_golang/prometheus due to a golang bug, and to
please the validation scripts.
The replaces were generated by:
go get k8s.io/kubernetes@v1.15.2 2> fail
for i in $(cat fail|grep unknown|cut -f1 -d@|cut -f2 -d" ")
do echo "replace ${i} => ${i} kubernetes-1.15.2"
done
Vendoring seems to be problematic with go modules.
In addition to causing issues with transitive dependencies and being
problematic when trying to pull in the node-cli code, it also seems to
be pulling different versions than what is computed in go.mod.
This can be seen by comparing commits from the computed version in
go.mod with very small diffs (like a single Godep change in k8s) but massive
vendoring changes.
Basically I have very little confidence that this is even working.
This should be better in go1.13, but this is not released yet.
This includes updates to CI config, vendor files, etc.
I've hard-coded the k8s depedency at 1.13.4 to keep it inline with what
we currently have and to make sure a another run of `go mod tidy`
doesn't accidentally update it to an unexpected version.
Thanks to hectorj2f for carrying this along.
