Gérer la suspension et la reprise

Les machines virtuelles (VM) peuvent être suspendues, réactivées, redémarrées et éteintes. Lorsque l'un de ces événements se produit, les éditeurs, les abonnés, les clients RPC et les serveurs RPC sont affectés. La figure 1 montre le cycle de vie d'un bundle de services :

Figure 1. Cycle de vie d'un bundle de services.

Le cycle de vie du bundle de services suit la séquence suivante :

1. La méthode new est appelée pour créer le bundle de services.
2. Le gestionnaire de cycle de vie démarre le bundle de services et, en fonction des paramètres de la configuration d'orchestration, appelle on_start.
3. Lorsque la VM s'arrête ou se met en veille, et en fonction des paramètres de la configuration d'orchestration, le gestionnaire de cycle de vie appelle on_stop. La fonction on_stop doit arrêter les threads pour les éditeurs, les abonnés, les clients RPC et les serveurs RPC.
4. Lorsque la VM est réactivée, on_start peut recréer les threads si le bundle de services est configuré pour être redémarré par la configuration d'orchestration.

Créer une configuration pour gérer la suspension et la réactivation

L'exemple suivant montre une configuration permettant de gérer la suspension et la réactivation :

# 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" }
}

Où :

• WAIT_FOR_FINISH est le dernier état d'alimentation dans lequel le bundle de services doit s'attendre à ce que les agents de véhicule défini par logiciel (SDV) soient réactifs.
• SUSPEND_TO_RAM_POST_FINISH indique que les agents SDV peuvent fermer ou suspendre la connexion pour pouvoir la restaurer de manière fiable lors de la réactivation. Il est important de ne pas s'appuyer sur SUSPEND_TO_RAM_POST_FINISH ou POWER_OFF_POST_FINISH pour appeler onStop dans l'implémentation du bundle de services, mais plutôt sur SUSPEND_TO_RAM_ENTER, POWER_OFF_ENTER et WAIT_FOR_FINISH.

Déterminer la disponibilité du service

L'exemple suivant montre comment utiliser l'API middleware dans votre bundle de services pour déterminer si une unité de service est disponible :

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 est une API middleware utilisée pour créer un événement appelé unit_name. Ce flux d'événements d'enregistrement est notifié lorsqu'une unité de service devient disponible.