Juju coincé dans l'état "en attente" lors de l'utilisation de LXC [fermé]


8

J'essaie donc de démarrer avec Juju, et j'ai essayé de le faire localement en utilisant LXC.

J'ai suivi les instructions ici: Comment configurer juju pour une utilisation locale?

Malheureusement, cela ne semble pas fonctionner pour moi.

l'état affiche les éléments suivants:

$ juju status
machines:
  0:
    agent-state: running
    dns-name: localhost
    instance-id: local
    instance-state: running
services:
  mysql:
    charm: cs:precise/mysql-1
    relations:
      db:
      - wordpress
    units:
      mysql/0:
        agent-state: pending
        machine: 0
        public-address: null
  wordpress:
    charm: cs:precise/wordpress-0
    exposed: true
    relations:
      db:
      - mysql
    units:
      wordpress/0:
        agent-state: pending
        machine: 0
        open-ports: []
        public-address: null
2012-05-10 14:09:38,155 INFO 'status' command finished successfully

Comme vous pouvez le voir, l'état de l'agent est «en attente» et il n'y a pas d'adresse publique où je peux accéder au site nouvellement créé. Est-ce que j'ai râté quelque chose?

MISE À JOUR: J'ai essayé de détruire l'environnement et de tout recommencer (plusieurs fois). Voici la sortie de debug-log:

~$ juju debug-log 
2012-05-11 08:50:23,790 INFO Enabling distributed debug log.
2012-05-11 08:50:23,806 INFO Tailing logs - Ctrl-C to stop.
2012-05-11 08:50:42,338 Machine:0: juju.agents.machine DEBUG: Units changed old:set([]) new:set(['mysql/0'])
2012-05-11 08:50:42,339 Machine:0: juju.agents.machine DEBUG: Starting service unit: mysql/0 ...
2012-05-11 08:50:42,459 Machine:0: unit.deploy DEBUG: Downloading charm cs:precise/mysql-1 to /home/andre/.juju/data/andre-local/charms
2012-05-11 08:50:42,620 Machine:0: unit.deploy DEBUG: Using <juju.machine.unit.UnitContainerDeployment object at 0x9c54b6c> for mysql/0 in /home/andre/.juju/data/andre-local
2012-05-11 08:50:42,648 Machine:0: unit.deploy DEBUG: Starting service unit mysql/0...
2012-05-11 08:50:42,649 Machine:0: unit.deploy DEBUG: Creating master container...
2012-05-11 08:54:33,992 Machine:0: unit.deploy DEBUG: Created master container andre-local-0-template
2012-05-11 08:54:33,993 Machine:0: unit.deploy INFO: Creating container mysql-0...
2012-05-11 08:56:18,760 Machine:0: unit.deploy INFO: Container created for mysql/0
2012-05-11 08:56:19,466 Machine:0: unit.deploy DEBUG: Charm extracted into container
2012-05-11 08:56:19,569 Machine:0: unit.deploy DEBUG: Starting container...
2012-05-11 08:56:22,707 Machine:0: unit.deploy INFO: Started container for mysql/0
2012-05-11 08:56:22,707 Machine:0: unit.deploy INFO: Started service unit mysql/0
2012-05-11 08:56:23,012 Machine:0: juju.agents.machine DEBUG: Units changed old:set(['mysql/0']) new:set(['wordpress/0', 'mysql/0'])
2012-05-11 08:56:23,039 Machine:0: juju.agents.machine DEBUG: Starting service unit: wordpress/0 ...
2012-05-11 08:56:23,154 Machine:0: unit.deploy DEBUG: Downloading charm cs:precise/wordpress-0 to /home/andre/.juju/data/andre-local/charms
2012-05-11 08:56:23,396 Machine:0: unit.deploy DEBUG: Using <juju.machine.unit.UnitContainerDeployment object at 0x9c519cc> for wordpress/0 in /home/andre/.juju/data/andre-local
2012-05-11 08:56:23,620 Machine:0: unit.deploy DEBUG: Starting service unit wordpress/0...
2012-05-11 08:56:23,621 Machine:0: unit.deploy INFO: Creating container wordpress-0...
2012-05-11 08:58:24,739 Machine:0: unit.deploy INFO: Container created for wordpress/0
2012-05-11 08:58:25,163 Machine:0: unit.deploy DEBUG: Charm extracted into container
2012-05-11 08:58:25,397 Machine:0: unit.deploy DEBUG: Starting container...
2012-05-11 08:58:27,982 Machine:0: unit.deploy INFO: Started container for wordpress/0
2012-05-11 08:58:27,983 Machine:0: unit.deploy INFO: Started service unit wordpress/0

Voici le résultat de la commande d'état (avec indicateur détaillé):

~$ juju -v status
2012-05-11 08:51:53,464 DEBUG Initializing juju status runtime
2012-05-11 08:51:53,625:4030(0xb7345b00):ZOO_INFO@log_env@658: Client environment:zookeeper.version=zookeeper C client 3.3.5
2012-05-11 08:51:53,625:4030(0xb7345b00):ZOO_INFO@log_env@662: Client environment:host.name=andre-ufo
2012-05-11 08:51:53,625:4030(0xb7345b00):ZOO_INFO@log_env@669: Client environment:os.name=Linux
2012-05-11 08:51:53,625:4030(0xb7345b00):ZOO_INFO@log_env@670: Client environment:os.arch=3.2.0-24-generic-pae
2012-05-11 08:51:53,625:4030(0xb7345b00):ZOO_INFO@log_env@671: Client environment:os.version=#37-Ubuntu SMP Wed Apr 25 10:47:59 UTC 2012
2012-05-11 08:51:53,626:4030(0xb7345b00):ZOO_INFO@log_env@679: Client environment:user.name=andre
2012-05-11 08:51:53,626:4030(0xb7345b00):ZOO_INFO@log_env@687: Client environment:user.home=/home/andre
2012-05-11 08:51:53,626:4030(0xb7345b00):ZOO_INFO@log_env@699: Client environment:user.dir=/home/andre
2012-05-11 08:51:53,626:4030(0xb7345b00):ZOO_INFO@zookeeper_init@727: Initiating client connection, host=192.168.122.1:41779 sessionTimeout=10000 watcher=0xb7780620 sessionId=0 sessionPasswd=<null> context=0x9242ee8 flags=0
2012-05-11 08:51:53,627:4030(0xb6b90b40):ZOO_INFO@check_events@1585: initiated connection to server [192.168.122.1:41779]
2012-05-11 08:51:53,649:4030(0xb6b90b40):ZOO_INFO@check_events@1632: session establishment complete on server [192.168.122.1:41779], sessionId=0x1373ae057d90007, negotiated timeout=10000
2012-05-11 08:51:53,651 DEBUG Environment is initialized.
machines:
  0:
    agent-state: running
    dns-name: localhost
    instance-id: local
    instance-state: running
services:
  mysql:
    charm: cs:precise/mysql-1
    relations:
      db:
      - wordpress
    units:
      mysql/0:
        agent-state: pending
        machine: 0
        public-address: null
  wordpress:
    charm: cs:precise/wordpress-0
    relations:
      db:
      - mysql
    units:
      wordpress/0:
        agent-state: pending
        machine: 0
        public-address: null

Pouvez-vous modifier votre question et lier les exemples que vous suivez?
Jorge Castro

Pouvez-vous également ajouter la sortie de 'ps auxf'? Cela devrait montrer que le nœud wordpress est toujours en attente car il installe toujours certains de ses composants. Sur une connexion lente avec un disque dur lent et une faible RAM, cela peut prendre plus de 10 minutes pour installer ces nœuds.
SpamapS

Il existe un outil utile dans la branche juju bzr qui nous fournira des informations en retour. Pouvez-vous le saisir en utilisant bzr branch lp:jujupuis sudo misc/devel-tools/juju-inspect-local-provider, puis également exécuter sudo lxc-lset exécuter l'outil ci-dessus pour chacune des images répertoriées, afin que nous puissions voir la sortie de tous les journaux à l'intérieur des conteneurs.
SpamapS

Réponses:


10

Je rencontrais la même erreur, et avec l'aide des bonnes personnes de #juju, j'ai pu déterminer que le fait d'avoir mon pare-feu activé sur la machine hôte empêchait zookeeper de se reconnecter à l'hôte.

Essayez de courir:

sudo ufw disable

et alors:

sudo juju destroy-environment

et ensuite faire reculer les choses. De plus, si c'est la première fois que vous amorcez un environnement sur votre machine, notez qu'il faut un certain temps pour que le téléchargement de charme initial se termine, alors donnez-lui 15-20 minutes après le déploiement d'une unité.

C'est aussi maintenant un bogue ouvert , car juju devrait gérer cette situation automatiquement.


2
Désactivé le pare-feu, et cela a fonctionné immédiatement. J'espère qu'ils ont résolu ce bug, cela me rend nerveux de désactiver mon ufw, mais au moins je peux maintenant expérimenter et jouer avec juju jusqu'à ce que j'aie un serveur pour jouer :)
Andre

3

Si c'est la première fois que vous amorcez votre environnement local, il faudra plusieurs (selon le temps nécessaire pour télécharger environ 400 Mo de données d'image de serveur) pour créer la première image principale. Dans votre chemin "data-dir" (défini dans votre fichier environment.yaml) il y en a un machine-agent.logqui décrit ce processus:

2012-05-09 10:04:03,848: juju.agents.machine@INFO: Machine agent started id:0
2012-05-09 10:05:08,175: juju.agents.machine@DEBUG: Units changed old:set([]) new:set(['mysql/0'])
2012-05-09 10:05:08,176: juju.agents.machine@DEBUG: Starting service unit: mysql/0 ...
2012-05-09 10:05:08,222: unit.deploy@DEBUG: Downloading charm cs:precise/mysql-1 to /home/marco/.juju/local/marco-local/charms
2012-05-09 10:05:08,314: unit.deploy@DEBUG: Using <juju.machine.unit.UnitContainerDeployment object at 0x9cccbec> for mysql/0 in /home/marco/.juju/local/marco-local
2012-05-09 10:05:08,375: unit.deploy@DEBUG: Starting service unit mysql/0...
2012-05-09 10:05:08,376: unit.deploy@DEBUG: Creating master container...

Quelques instants plus tard, vous verrez ce qui suit:

2012-05-09 10:09:40,699: unit.deploy@DEBUG: Created master container marco-local-0-template
2012-05-09 10:09:40,699: unit.deploy@INFO: Creating container mysql-0...
2012-05-09 10:10:31,429: unit.deploy@INFO: Container created for mysql/0
2012-05-09 10:10:31,483: unit.deploy@DEBUG: Charm extracted into container

Qui détaille que quelques minutes plus tard le conteneur maître a été créé.

Enfin, tous les boostrap "locaux" ne fonctionnent pas, essayez de juju destroy-environmentlancer puis de relancerjuju bootstrap


Merci pour la réponse. Je redémarre le processus et je garde un œil sur les journaux pour voir ce qui se passe.
Andre

Après juju destroy-environment, dois-je redéployer les charmes? Ou sont-ils essentiellement déjà «installés»?
Andre

@Andre Vous devrez redéployer. Faire un destroy-environnement supprimera essentiellement l'environnement et tout ce qui s'exécutait dessus.
Marco Ceppi

Malheureusement toujours pas de chance. J'ai essayé cela plusieurs fois et j'ai attendu pour m'assurer que tout était terminé. J'ai mis à jour mon message d'origine avec le statut détaillé et le journal de débogage.
Andre

1

J'ai eu ce même problème. J'ai trouvé des master-customize.logéchecs apt-get en raison de paquets corrompus dans apt-cacher-ng (je ne suis pas sûr que je pense que cela s'est produit parce que mon ordinateur portable a été suspendu pendant le téléchargement). J'ai pu corriger le problème en visitant http://localhost:3142/acng-report.html, en vérifiant:

  • Valider par nom de fichier ET répertoire de fichiers (non recommandé),
  • puis valider le contenu des fichiers via la somme de contrôle (SLOW), détectant également les fichiers corrompus,
  • puis tronquez immédiatement les fichiers endommagés.

et en cliquant sur Démarrer l'analyse et / ou l'expiration. Ensuite, j'ai pu détruire l'environnement juju et le redéployer avec succès.


0

Au lieu de désactiver ufw, on peut essayer d'autoriser le réseau de juju (libvirt) avec:

sudo ufw allow from `ip addr show virbr0|tail -n 1 |cut -d' ' -f 6` to any

Fonctionne dans mon cas sur Ubuntu 12.04

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.