* API: introduce ability to watch a VM
* Document ?watch=true for GET /vms/{name} in the OpenAPI specification
* WatchVM: ensure that goroutine is terminated on early return with error
* WatchVM: close channels on goroutine exit
* WatchVM: ensure that we wait for the goroutine after additional barriers
* WatchVM: ignore unexpected keys instead of throwing an error
* WatchVM: perform context-aware writes to a bounded channel
* WatchVM: don't forget to close errCh on goroutine exit too
* WatchVM: don't close readyCh in goroutine to avoid ambiguity
* WatchVM: filter out spurious KVs that signify VM deletion
* Change event prefix to preserve order under load
When there are a lot of events streamed from a worker, it's possible to have two batches coming for the same timestamp (which is a timestamp of the event on the worker). This way the existing logic would mess up the order because `index` and the random number doesn't guarantee the order.
To fix this I've changed the format of the prefix for the event to include tro things:
1. Timestamp in nanoseconds of the injection time on the controller so two sequential batches will have guaranteed order unless they are processed within a nanosecond.
2. Made the `index` being fixed length with trailing zeros, so they are properly lexicographically sorted (`000001`, `000002`, ...).
* No need to disable linting
* Generic Events
We can try to use these generic events for script execution and storing of the output logs in events with `log` kind.
* Lint issues
* Cleanup events upon VM deletion
* Basic integration test
* Run an actual VM in tests
* Apply suggestions from code review
Co-authored-by: Nikolay Edigaryev <edigaryev@gmail.com>
* Use POST
* Make newEventKey private
* Append events in batches
* Lint issues
* Private `scopePrefix`
---------
Co-authored-by: Nikolay Edigaryev <edigaryev@gmail.com>
Nikolay Edigaryev
Fedor Korotkov