* Add pagination support for listing VM events
Introduced a paginated event listing API, added support for pagination parameters in the request, and included cursor-based navigation using headers. Relevant tests and Badger store implementations were updated to support the new logic.
* Remove support for ordering VM events
Dropped `ListOrder` type, `order` query parameter, and related logic for ordering VM events. Updated tests, API schema, and Badger store to reflect the removal.
* Remove invalid VM events ordering test
Deleted a test case for invalid VM events ordering since the `order` query parameter and related functionality have been removed.
* Add support for ordering VM events
Implemented `order` query parameter for specifying sort order (ascending/descending) of VM events. Updated API schema, Badger store, and added related tests.
* Add support for limiting and ordering VM logs
Introduced `--limit` and `--order` flags for controlling the number of log lines and their sort order (ascending/descending). Updated API client to handle new options.
* Update internal/controller/store/badger/badger_events.go
Co-authored-by: Nikolay Edigaryev <edigaryev@gmail.com>
* fix: address PR review feedback
- switch logs CLI to --tail with desc ordering
- reuse ParseLogsOrder in controller with helpful errors
- always use ListEventsPage and scope event cursors
- move events pagination coverage to integration test
🤖 Generated with [Codex](https://chatgpt.com/codex)
Co-Authored-By: Codex <codex@openai.com>
* refactor: simplify prefix trimming and improve error formatting
- Replaced manual prefix check with `bytes.TrimPrefix` in Badger store.
- Enhanced error message formatting in VM logs controller.
* fix: address PR review feedback
- use suggested reverse seek in badger events pagination
- add events pagination client helper and use it in integration test
🤖 Generated with [Codex](https://chatgpt.com/codex)
Co-Authored-By: Codex <codex@openai.com>
---------
Co-authored-by: Nikolay Edigaryev <edigaryev@gmail.com>
Co-authored-by: Codex <codex@openai.com>
* Small timout for worker notification
It seems at the moment if a worker re-establishes notify stream (for example, if network flips or proxy breaks the connection) then we can see "no worker registered with this name" errors.
This change makes Notifier to wait for 30 seconds before failing, at the time of calling `Notifier#Notify` we know such worker exists.
PS not sure if we need to make the timeout configurable.
* Wait via context
* Make sure all `context`s for `Notify` is time bounded
* Lint issues
* Support URLs in hostDir policies
We can't just blindly allow remote URLs since they might contain symlinks leading to outside the archive. Instead, let's support specifying URLs where the remote archive can come from.
Fixes#145
* Ignore Lint issue
* Reverted old validation logic
* 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
Before we had two main loops: controller loop to assign VMs and worker loop to start VMs. Each of the loops was performed upon an interval every N seconds.
This change introduces a mechanism for reactively requesting loop execution:
1. Controller loop will be executed upon VM creation to try to immediately schedule.
2. A worker will be notified upon a VM assigment and worker loop will be requested to sync immediately.
Fixes#31
* Simplified bootstrapping of a cluster
Introduced a new convention about a pre-defined `bootstrap-admin` account for `orchard controller run`. Providing `ORCHARD_BOOTSTRAP_ADMIN_TOKEN` will auto-create such user for easier configuration. `bootstrap-admin` can be used for creating other service accounts on the first run and after that can be disposed.
Also change `orchard worker run` to expect controller URL as the only parameter and a bootstrap token passed via an argument instead of using a context that might not be created.
* Missing error check
* 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>
Fedor Korotkov