Gestire la sospensione e la ripresa

Le macchine virtuali (VM) possono essere sospese, ripristinate, riavviate e arrestate. Quando si verifica uno di questi eventi, i publisher, gli abbonati, i client RPC e i server RPC vengono interessati. La figura 1 mostra il ciclo di vita di un bundle di servizi:

Ciclo di vita di un bundle di servizi

Figura 1. Ciclo di vita di un bundle di servizi.

Il ciclo di vita del bundle di servizi segue questa sequenza:

  1. Viene chiamato il metodo new per creare il bundle di servizi.
  2. Il gestore del ciclo di vita avvia il bundle di servizi e, a seconda delle impostazioni nella configurazione di orchestrazione, chiama on_start.
  3. Quando la VM si arresta o viene sospesa e, a seconda delle impostazioni nella configurazione di orchestrazione, il gestore del ciclo di vita chiama on_stop. La funzione on_stop deve arrestare i thread per publisher, abbonati, client RPC e server RPC.
  4. Quando la VM viene ripristinata, on_start può ricreare i thread se il bundle di servizi è configurato per essere riavviato dalla configurazione di orchestrazione.

Creare una configurazione per gestire la sospensione e il ripristino

L'esempio seguente mostra una configurazione per gestire la sospensione e il ripristino:

# Start `auto_start` service bundles when system is started.
state {
    condition {
        or {
            power_state: "ON"
            power_state: "POWER_OFF_EXIT"
            power_state: "SUSPEND_TO_RAM_EXIT"
        }
    }
    groups_states { started: "auto_start" }
}

# Stop `auto_start` service bundles when system is suspending to RAM.
state {
    condition {
        or {
            power_state: "SUSPEND_TO_RAM_ENTER"
            power_state: "WAIT_FOR_FINISH"
            power_state: "SUSPEND_TO_RAM_POST_FINISH"
        }
    }
    groups_states { created: "auto_start" }
}

Dove:

  • WAIT_FOR_FINISH è l'ultimo stato di alimentazione in cui il bundle di servizi deve prevedere che gli agenti del veicolo software-defined (SDV) siano reattivi.
  • SUSPEND_TO_RAM_POST_FINISH indica che gli agenti SDV potrebbero chiudere o sospendere la connessione per poterli ripristinare in modo affidabile al ripristino. È importante non fare affidamento su SUSPEND_TO_RAM_POST_FINISH o POWER_OFF_POST_FINISH per chiamare onStop nell'implementazione del bundle di servizi e, invece, fare affidamento su SUSPEND_TO_RAM_ENTER, POWER_OFF_ENTER e WAIT_FOR_FINISH.

Determinare la disponibilità del servizio

L'esempio seguente mostra come utilizzare l'API middleware nel bundle di servizi per determinare se un'unità di servizio è disponibile:

let mut registration_event_stream =  sdv::mw::clientlib::create_server_registration_event_stream(
        sdv_comms,
        // Descriptor of type sdv::mw::clientlib::rpc_descriptor::client::Descriptor
        // that binds a specific RPC client type to a communication channel.
        client_descriptor,
    )
    .await
    .expect("unable to generate a registration event");

match registration_event_stream.next().await {
            Some(sdv::mw::Availability::Available) => {
                info!("{unit_name} became Available.");
                // Create client/subscriber
            }
            Some(sdv::mw::Availability::Unavailable) => {
                info!("{unit_name} became Unavailable.");
                // Destroy client/subscriber
            }
            None => {
                warn!("Registration event stream for {unit_name} terminated.
                Stopping monitoring for this variant.");
            }
        }

create_server_registration_event_stream è un'API middleware utilizzata per creare un evento denominato unit_name. Questo stream di eventi di registrazione viene notificato quando un'unità di servizio diventa disponibile.