Projet

Général

Profil

Tâche #35963

Scénario #35955: Mise à jour de opennebula sur la 22.04 (EOLE 2.9)

Impossible de récupérer la liste des bridges opennebula

Ajouté par Daniel Dehennin il y a presque 2 ans. Mis à jour il y a plus d'un an.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Début:
30/05/2024
Echéance:
% réalisé:

100%

Restant à faire (heures):
0.0

Description

Problème

Après une mise à jour des paquets OpenNebula, le premier reconfigure affiche 2 erreurs:

  1. /usr/share/eole/preservice/00-hapy-bridge reconfigure
    Impossible de récupérer la liste des bridges opennebula :
    
    Status du service OpenNebula :
    ○ opennebula.service - OpenNebula Cloud Controller Daemon
         Loaded: loaded (/lib/systemd/system/opennebula.service; enabled; vendor preset: enabled)
        Drop-In: /etc/systemd/system/opennebula.service.d
                 └─libvirtd.conf, multi-user.conf
         Active: inactive (dead) since Thu 2024-05-30 16:08:28 CEST; 1min 24s ago
       Main PID: 2167 (code=exited, status=0/SUCCESS)
            CPU: 11.518s
    
  2. Redémarrage du réseau
    Purge de toutes les interfaces…
    Désactivation de l’interface 'virbr0'…OK
    Purge des adresses IP de l’interface 'virbr0'…OK
    Désactivation de l’interface 'enp2s0'…OK
    Purge des adresses IP de l’interface 'enp2s0'…OK
    Suppression de l’interface 'virbr0'…OK
    Suppression de l’interface 'vswitch'…Erreur : RTNETLINK answers: Operation not supported
    

Analyse

Lorsque les paquets OpenNebula sont mis à jour, les services sont arrêtés par le script /var/lib/dpkg/info/opennebula.prerm :

#!/bin/sh

set -e

service opennebula stop 2>/dev/null || :
service opennebula-scheduler stop 2>/dev/null || :
service opennebula-hem stop 2>/dev/null || :
service opennebula-ssh-agent stop 2>/dev/null || :
  • Cela empêche le script preservice de lister les bridges OpenNebula
  • Ce qui conduit à la seconde erreur car on ne peut pas faire un ip link delete sur un bridge Open vSwitch

Révisions associées

Révision d2eca38d (diff)
Ajouté par Benjamin Bohard il y a plus d'un an

Utiliser les commandes ovs-vsctl ne dépendant pas de l’API ONE.

Ref #35963

Historique

#1 Mis à jour par Benjamin Bohard il y a plus d'un an

  • Description mis à jour (diff)
  • Assigné à mis à Benjamin Bohard

#2 Mis à jour par Benjamin Bohard il y a plus d'un an

  • Statut changé de Nouveau à En cours

#3 Mis à jour par Benjamin Bohard il y a plus d'un an

  • Description mis à jour (diff)

En preservice, la liste des réseaux est récupérée via un appel à l’API d’OpenNebula (pas accessible à ce moment si le reconfigure suit directement la mise à jour, sans redémarrage préalable des service opennebula).

Juste après mise à jour, la commande onevnet list ne renvoie rien. Par contre, la commande ovs-vsctl list-br renvoie bien vswitch. Toutefois, cette alternative n’est sans doute valide que lorsque openvswitch est activé (activer_openvswitch à oui).

#4 Mis à jour par Benjamin Bohard il y a plus d'un an

Le fichier créé par la commande onevnet list --csv, en preservice, est utilisé par le script /usr/sbin/eole-purge-interfaces lancé lors de la gestion du réseau, un peu plus tard lors du reconfigure.

#5 Mis à jour par Benjamin Bohard il y a plus d'un an

L’utilisation d’openvswitch est virtuellement optionnelle mais pratiquement obligatoire :
- conditionnée par la valeur de la variable vnet_pilote
- la variable vnet_pilote est cachée
- la variable vnet_pilote accepte seulement la valeur openvswitch

Dans ces conditions, peut-on envisager d’utiliser la commande d’openvswitch plutôt que la commande de opennebula pour récupérer la liste des bridges ?

#6 Mis à jour par Benjamin Bohard il y a plus d'un an

  • Statut changé de En cours à À valider

#7 Mis à jour par Laurent Gourvenec il y a plus d'un an

  • Statut changé de À valider à Résolu
  • % réalisé changé de 0 à 100

#8 Mis à jour par Joël Cuissinat il y a plus d'un an

  • Statut changé de Résolu à Fermé
  • Restant à faire (heures) mis à 0.0
eole-one-master$ git branch -r --contains d2eca38d 
  origin/2.9.0/master
  origin/HEAD -> origin/master
  origin/dist/eole/2.10.0/master
  origin/dist/eole/2.9.0/master
  origin/master

Formats disponibles : Atom PDF