* Support Tart Guest Agent transport for VM startup scripts
* TestTartGuestAgentStartupScript: make ScriptContent more readable
* Align Tart Guest Agent's startup script execution with SSH
* Use mvdan.cc/sh/v3/syntax to validate "export" shell commands
* Use Bash instead of Zsh on Linux
* Invert logic when validating vm.StartupScript.Transport for simplicity
* Document startup_script's transport field in OpenAPI specification
* Prevent unbounded buffering of startup script output
* grpc.WaitForReady(true) → retry.DoWithData()
Expose noClipboard in VM creation, CLI inspection, and the API schema.
Pass --no-clipboard to Tart when requested. Clipboard sharing remains
enabled by default for existing VM specifications.
tart run supports --no-audio to disable host audio pass-through, but
there was no way to request it through a VM's spec - Headless, Nested,
and Suspendable all have a flag/field but audio didn't. Useful on
headless hosts with no audio hardware, where audio pass-through can
make guest CoreAudio depend on host audio services that don't exist.
* Simplify state reconciliation and support changing Softnet settings
* Remove unused "updateFunc" parameter from syncOnDiskVMs()
* Don't take an address of a loop variable
* ensure → ensures
* updateVMState(): don't forget to update VMState
* Introduce TestSpecUpdateSoftnet integration test
* Update OpenAPI specification to include generation/observedGeneration
* proxy.Connections(): require io.ReadWriteCloser instead of net.Conn
* Orchard Controller: implement an SSH server that acts as a jump host
* Issue a warning if the name used will be invalid in the future
* Further restrict uppercase characters in names in the future
The rationale is similar to https://github.com/kubernetes/kubernetes/issues/71140.
We won't want to munge the user's input and introduce subtle bugs doing
lowercase comparisons.
* 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
* 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
* Make sure we list names/VM names as required argument in the --help
* Introduce "orchard logs vm" command
* Make sure each command has a Short field
* Future-proof port-forward, ssh and vnc commands
To support not only the VM resource.
Yibo Zhuang