v0.107.0

Added

• vk-hub manages node settings from the CLI and web UI. Use vk-hub settings set and
  unset, or the web UI's Settings page, to set capacity, VM sizing and a hub-managed registry
  fleet-wide or per node, with per-node settings
  winning over the fleet's; a value of the wrong type or out of bounds is refused at once.
• vk-hub shows what each node's settings come to. A node's page lists each setting's value
  and whether it comes from the node's config file, the hub, the host's size or a default, the
  hub's settings it refused, the release keys it trusts (flagged when it has keys but does not
  require signed updates), its automatic update and its vCPUs in use; vk-hub nodes shows the vCPUs
  too.
• A registry's CA reaches the nodes it is named to. vk-hub registries set-url --ca
  takes the CA a registry's certificate chains to, and nodes the hub names the registry to
  trust it with no config of their own.
• vk-hub keeps its nodes on a target release. vk-hub release target sets the vk the
  fleet should run: setting it rolls it out to the nodes running an older version, and from then
  on a node that falls behind, such as one that just joined, is updated on its own once it is
  ready. Nodes on a newer version, with their own gitlab-runner, or whose keys would refuse the
  release are left alone, a node running a pre-release or development build is shown as not
  updated automatically, and a node whose update failed waits for an operator's --retry. The
  target must be signed by one of [nodes] release_keys when the hub sets any, and cannot be
  deleted while it is the target. The web UI's Updates page shows the target and each node's
  status, and lets operators set or clear the target and resume its updates.
• A fleet node's jobs have a network with no config of its own. Unless its config file
  sets [net] mode, a node enrolled with a hub gives its jobs the per-job switch, held to its
  own [egress] and the hub's egress rules, so they can reach the registry proxy and run
  services. The hub cannot change this; a node that wants its jobs offline sets mode = "none".
• A fleet node checks update signatures with no config of its own. The release keys in the
  hub's [nodes] release_keys are pinned on each node when it joins, and from then on it
  requires updates signed by one of them, as it would with the keys in its own config, which
  still win; [node] require_signed = false in its config makes a signature optional, as it
  does for those keys. Nothing the hub says later changes them. The node reports which keys it
  trusts, where they come from and whether it requires a signature.
• A fleet node can use the registry its hub names. With no [registry] in its config, the
  node takes the hub's, CA included, and holds no registry credential of its own: its jobs'
  guests reach the registry with the token the hub gives each job, and so do the node's own
  pulls of the job's images.
• CI jobs can wait for vCPUs as they wait for memory. With [executor.schedule] cpu_overcommit set, a job waits while the vCPUs of the jobs' guests and their services would
  pass that many per CPU of the host, and vk tune asks the runner for no more jobs than that
  leaves room for, though always at least one. A fleet node does this at 2 unless its config or
  hub says otherwise, and vk-hub stops placing jobs on it past that.
• A fleet node takes settings from its hub. Capacity and VM sizing settings and the
  registry may come from the hub; anything the node's own config file sets still wins, and
  every vk on the node uses the result. The node refuses anything else the hub sends and
  reports each setting's value and where it comes from. vk node run restarts itself in
  place when they change.
• vk-hub namespaces can keep chosen branches' and tags' caches apart. A namespace path may
  hold the new {scope}, which is all for most jobs, so the namespace stays per project
  and protection; vk-hub namespaces add … --isolate <glob> gives the refs it matches a scope
  each, which no other ref's job reaches. The path's leading fixed part is reserved: no other
  namespace may reach it, so grants cannot add up across scopes.
• vk-hub adds a ci-build namespace for build caches, one per project, protection and
  isolated ref, kept 14 days, to every registry taking tokens, existing ones included unless a
  namespace already uses that name or root.
• [jobs] require_job_build_cache in hub.toml places jobs only on nodes that cache their
  builds by project, protection and scope; vk-hub nodes says why another takes none.

Changed

• pipeline/build/ images are pulled with the job's token, as they are published, even
  when the node has its own registry credential. That credential needs no read access to
  the pipeline namespace; pulls use it when the job's token expires.
• Nodes that lend guests the job's registry token and have no registry credential
  now use that token to pull placed jobs' images, replacing anonymous pulls; once the token
  has expired, they pull anonymously again.
• vk-hub places jobs only where a node's memory is free now as well as within its budget,
  keeping 15 % of the node's RAM spare, as vk tune does.
• A fleet node needs no memory budget or vCPU ceiling in its config. Unless its config or
  hub sets them, its jobs' memory is budgeted at the host's RAM less the smaller of 4 GiB and
  10 %, and a job may ask for up to all of the host's CPUs; the default job VM keeps 4 vCPUs
  and 4 GiB, less on a smaller host. vk tune works on such a node with no config.
• A node keeps each placed job's builds to its project, protection and scope. Built
  images, layers, build locks and Windows builds are cached under the job's ci-build prefix
  with its token, or not at all, no longer in [build] cache_registry, and what the node
  built for one scope is not found by another. A node whose guests' registry proxy lends its
  own credential (proxy_guests without guest_credential = "job") keeps the old behaviour.
  A placed job's Windows build takes install media from outside its build context only when
  [executor] windows_media lists them. Placed jobs build with the cache off, and say why,
  when the hub is older (upgrade it first), mints no tokens for the node's [registry], or
  has no ci-build namespace there because another namespace held that name or root, or
  when the node's [registry] is missing or local.
• vk-hub validates namespace paths for every job. Paths that could exceed the registry's
  limits with a job's identifiers are rejected when stored, instead of leaving that job
  without access.
• vk-hub rejects unusable registry paths. Namespace paths and operator token grants
  are rejected when stored or minted if they exceed 16 components or contain tags,
  manifests or blobs as a component. GitLab instances cannot use those names either.
  These paths were already refused by the registry.
• While a fleet is upgraded, hosts of this release and earlier ones may each build the same
  cached layer once instead of waiting for each other's build.

Fixed

• GitLab jobs without MICROVM_CPUS or MICROVM_MEM respect
  [executor.vm] max_cpus and max_mem. Previously, they used cpus and mem even
  when those exceeded the ceilings.
• vk-hub counts accepted jobs until a later heartbeat reports them. Previously, they
  stopped counting against memory and vCPUs before the node reported them, allowing offers
  the node would refuse.
• A vk-hub rollout no longer sends an older release to a node updated by hand meanwhile.
  A node that has reached the release's version or a newer one since the rollout started is
  skipped when its wave comes, instead of refusing the update and pausing or aborting the
  rollout, or being downgraded.
• A vk-gitlab relay whose session vk-hub ends is told why. A relay superseded by a newer
  session, removed or refused could previously see its connection fail instead of reading the
  hub's reason.

Full Changelog: v0.106.1...v0.107.0