* Client: prevent double slashes at the end of URLs
* orchard context create: let the user know which association flow is used
* Client: rename parsePath() to formatPath()
* Client: grab the ServerName from the trusted certificate
* 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
* Always Close() the Worker instance
* orchard list vms: show assigned worker for each of the VMs
* Stop the failed VMs before we schedule new VMs
To avoid violating resource constraints.
* syncOnDiskVMs: don't ignore running VMs
* Worker: show correct remote and local VM counts
* Switch from golang.org/x/net/websocket to nhooyr.io/websocket
* Do not attach errors that we can handle to the Gin's context
* Add missing newline to "no credentials specified or found, ..." message
* Fix potential NPE in ChooseUsernameAndPassword()
* Fix type in PortForward() error message in "orchard ssh vm"
* Fix potential NPE in Connections()
* Use header.Set() for consistency's sake for Authorization header
* Fix typo when passing arguments to tls.LoadX509KeyPair()
* Support TLS 1.2 too
* Do not require a controller to only present a single certificate
* No need to set ServerName since we use InsecureSkipVerify
* Use host's root CA set by default and support normal SNI scenarios
* 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
* Implement restart policy for VMs
* Do not update VM.Resource, we only use it as a read-only specification
* Err()/setErr(): use atomic.Pointer instead of sync.Mutex
* Controller API: introduce controller's information endpoint
* Prevent generation of empty events after channel closure
* Allow events to be buffered in the events channel
* Controller API: introduce controller's information endpoint[1]
* IntegrationGuide.md: a couple of Python and Golang examples
* Rephrase a sentence
Co-authored-by: Fedor Korotkov <fedor.korotkov@gmail.com>
---------
Co-authored-by: Fedor Korotkov <fedor.korotkov@gmail.com>
* Fail VMs if the worker had crashed/is unhealthy
* OnDiskName: properly handle cases when VM's name contains hyphens
* Worker: introduce Offline() method and check it before scheduling
* tart.List(): use Tart's JSON output
* OnDiskName: remove empty parts check
* Scheduler: move health-checking logic to a separate function
* Only fail "running" VMs
* Only fail orphaned VMs if they're in terminal state
* Integration tests
* Run healthCheckingLoopIteration() before schedulingLoopIteration()
* Worker: sync on-disk VMs only once at start
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
* Resources support
* Ability to provide VM and worker resources via the CLI
* orchard dev: always listen on :6120
* orchard dev: support --resources
* REST API: provide resource defaults when creating VM
* OpenAPI: document "resources" field
* orchard dev: serve Swagger API documentation on /v1/
* Integration guide
Nikolay Edigaryev