Liste des actions possibles¶

• action d'activation/désactivation : enable/disable/configure (configure reprenant la configuration Creole)
• action de stop/(re)démarrage : start/stop/restart/reload/apply (apply démarrant/stoppant suivant la configuration Creole)
• action de status : status

Fonctionnement interne¶

Aujourd'hui, après le refactoring en s'inspirant de ce qu'il y avait nous avons :

• check avant l'action (quelque soit l'action) qui vérifie :
  • si l'action est activé (au sens ubuntu et non Creole) ;
  • si l'action n'est pas configuré correctement (toujours au sens ubuntu).

Sauf cas particulier il n'est pas possible de lancer une action si le check ne passe pas.
Par contre, il y a un "raise" que si l'action est 'start' ou 'restart' (sauf si on redémarre tous les services).

• si le check passe (sauf cas particulier) lancement de l'action.

Problèmes :¶

Voici une liste non exhaustive des problèmes actuels :

• peu de distinction des actions globales (application d'une configuration) et action sur un service particulier

• c'est ubuntu qui a raison (et non Creole) :
  • il est possible de (dés)activer une action alors qu'elle est active dans Creole
  • si on désactive une action il n'est plus possible de faire un status/stop/... sur ce service
  • si un service est activer dans Creole, il n'est pas possible de le démarrer si pas configuration dans ubuntu
  • ....

• gestion des erreurs a définir :
  • pourquoi fait un raise si un service ne doit pas être démarré, mais juste un log.debug pour status ?

Problèmes connexes¶

• l'ordre de démarrage des services au démarrage de la machine n'est pas contrôlable ;
• on ne peut pas démarrer les conteneurs sans démarrer les services (donc il n'est pas possible d'avoir accès au conteneur en posttemplate ou les services sont démarrés avant posttemplate et non postservice).