BusDK

BusDK Update

VM- ja container-API:t saavat omat providerinsa

bus-api-provider-vm ja bus-api-provider-containers tuovat AI Platformin VM/runtime- ja container-runner-pinnat omiin Bus API -provider-moduuleihinsa.

REST-pinta pysyy cloud-neutralina. Pilvikohtainen työ, kuten UpCloudiin kohdistuva operointi, kuuluu event-pohjaiselle integraatiotyöntekijälle eikä HTTP-controlleriin.

26.4.2026bus-api-provider-vmbus-api-provider-containersAI Platform

Tiiviisti

TL;DR

  • bus-api-provider-vm omistaa /api/v1/vm/status, /api/v1/vm/start ja /api/v1/vm/stop.
  • bus-api-provider-containers omistaa container runner -tilan, ajon luonnin ja käyttäjän oman ajon poiston.
  • Molemmat providerit voivat käyttää determinististä static-taustaa tai Bus Events -request/reply-tilaa.
  • BUS_EVENTS_LISTENER_REQUIRED=1 tekee /readyz-vastauksesta riippuvaisen vaadittujen Events-response-listenerien yhteydestä.
  • Container-provider suodattaa status-vastaukset kirjautuneen accountin mukaan ja hylkää run/delete-vastaukset, joissa backend väittää eri omistajan.
  • Onnistunut container run voi kirjautua container.run-usage-tapahtumaksi suoraan muistitaustaan tai Bus Events -pohjaiseen usage-storeen.

VM-providerin HTTP-pinta on suora ja scopeilla rajattu:

GET  /api/v1/vm/status   # vm:read
POST /api/v1/vm/start    # vm:write
POST /api/v1/vm/stop     # vm:write
GET  /readyz

Staattisella taustalla status ja lifecycle-vastaus ovat tunnistettavia ilman pilviyhteyttä. GET /api/v1/vm/status palauttaa esimerkiksi tämän olennaisen tilafragmentin:

{
  "state": "ready"
}

POST /api/v1/vm/start kuittaa lifecycle-pyynnön hyväksytyksi:

{
  "accepted": true
}

Container-provider erottaa lukemisen, ajon luonnin ja poiston omiin scopeihin:

GET    /api/v1/containers/status         # container:read
POST   /api/v1/containers/runs           # container:run
DELETE /api/v1/containers/runs/{run_id}  # container:delete
GET    /readyz

GET /api/v1/containers/status palauttaa ajolistan, ja staattinen testitausta tekee run-tunnisteesta vakaan:

{
  "items": [
    {
      "run_id": "static-run"
    }
  ]
}

Provider lähettää JWT:n sub-accountin integraatiolle account_id-kenttänä. Status-listalta poistetaan toisen accountin rivit, vanhat ownerittomat vastaukset leimataan callerin accountilla, ja yksittäinen run/delete-vastaus palautuu 403 forbidden, jos backend kertoo eri owner_account_id-arvon.

Kun provider käynnistetään event-tilassa, HTTP-pyyntö muuttuu Bus Events -request/reply-virraksi. Provider-prosessi omistaa response-listenerin ja korreloi vastauksen takaisin alkuperäiseen HTTP-pyyntöön:

$ bus-api-provider-vm \
  --backend events \
  --events-url http://127.0.0.1:8080 \
  --api-token "$BUS_API_TOKEN"

Kun BUS_EVENTS_LISTENER_REQUIRED=1 on käytössä, /readyz pysyy epäterveenä, kunnes vaadittu response-listener on saanut Events API -streamin auki. Container-provider raportoi tässä tilassa container- ja usage-listenerien nimet, ja diagnostisista virheistä redaktoidaan bearer-tokenit sekä muut credential-arvot.

Container-providerilla on erillinen usage-tausta. Kun --usage-backend events on valittu, onnistunut POST /api/v1/containers/runs kirjaa container.run-usage-tapahtuman bus.usage.record.request -pyyntönä. Tapahtuman dataan kuuluu run-tunniste, profiili, image, exit code, kesto ja runnerin nimi, ja event_id sidotaan run-tunnisteeseen muodossa container.run.<run_id>.

bus-integration-upcloud on tämän työn pilvikohtainen puoli: se kuuntelee cloud-neutral VM/container request -tapahtumia ja julkaisee korreloidut result/status-vastaukset. Nykyinen pinta on kuvattu bus-api-provider-vm-, bus-api-provider-containers-, bus-integration-upcloud- ja bus-integration-usage-dokumentaatiossa.