BusDK Update

Providerit ja integraatiot saavat tarkemmat rajapintaviitteet

Bus API -providerien ja integraatiotyöntekijöiden READMEt näyttävät nyt sopimuksensa samalla tavalla: providerit listaavat endpointit yksittäin, integraatiot listaavat kuunnellut ja lähetetyt Bus Events -tapahtumat.

Tämä auttaa operaattoria näkemään nopeasti, mikä moduuli omistaa HTTP-pinnan, mikä moduuli omistaa event-työn ja milloin endpoint todella julkaisee Bus Eventsin.

26.4.2026READMEProvidersEvents

Tiiviisti

TL;DR

  • bus-api-provider-*-READMEt käyttävät API Endpoints -osiota, jossa jokainen HTTP-reitti saa oman lyhyen kuvauksensa.
  • Jokainen provider-endpoint kertoo, mitä Bus Events -tapahtumia se käynnistää, tai sanoo suoraan ettei se käynnistä eventtejä.
  • bus-integration-*-READMEt käyttävät Event Contract -osiota, jossa request- ja response-eventit näkyvät omilla alaotsikoillaan.

Providerin README ei enää tyydy pelkkään endpoint-listaan. Esimerkiksi container-providerin run-endpoint kertoo sekä HTTP-roolin että event-polun:

### `POST /api/v1/containers/runs`

Starts one foreground user-owned container run. This endpoint triggers
`bus.containers.run.request` and waits for `bus.containers.run.response`
when `--backend events` is selected. When `--usage-backend events` is
selected, a successful run also triggers `bus.usage.record.request`
and waits for `bus.usage.record.response`.

Sama rakenne näkyy VM-, LLM-, usage- ja Events API -providereissa. VM-providerin status-endpoint sanoo, milloin se julkaisee bus.vm.status.request -eventin. Usage-providerin listaus- ja poistoendpointit taas sanovat suoraan, että standalone-provider lukee omaa usage-storeaan eikä käynnistä Bus Eventsejä. Books-, data- ja session-providerien READMEissä näkyy myös nykyinen rajaus: standalone-binaari on discovery/help-pinta, sillä ei ole runtime HTTP endpointtejä eikä se laukaise Bus Eventsejä.

Integraatiomoduuleissa painopiste on päinvastainen: README alkaa event-sopimuksesta, koska moduuli on eventtejä kuunteleva työntekijä. UpCloud-integraatio näyttää VM-, container- ja SSH-skriptien request/response-parit omissa osioissaan:

### `bus.containers.run.request`

The worker listens for foreground container run requests. It owns UpCloud
runner discovery/creation, bootstrap script construction, and Podman command
construction.

### `bus.ssh.script.run.request`

For runner bootstrap and foreground container execution, the UpCloud worker
sends SSH script requests to `bus-integration-ssh-runner`.

SSH-runner ja usage-integraatio noudattavat samaa muotoa. SSH-runnerin README kertoo, että bus.ssh.script.run.request sisältää targetin, käyttäjäehdokkaat, skriptin, timeoutin ja output-rajan. Usage-workerin README näyttää bus.usage.record-, bus.usage.list- ja bus.usage.delete -eventtiparit.

Tarkempi moduulikohtainen jatkopolku löytyy container-providerin dokumentaatiosta, VM-providerin dokumentaatiosta, UpCloud-integraation dokumentaatiosta ja usage-integraation dokumentaatiosta.